Відновлення Windows за допомогою PowerShell: правильний запуск SFC/DISM

SFC vs DISM: що насправді виправляє кожен

SFC (System File Checker) перевіряє й відновлює захищені системні файли Windows від компонентного сховища. Думайте про це так: «Чи збігається C:\Windows\System32\something.dll з тим, що Windows вважає правильним?» Якщо ні, SFC намагається замінити його.

DISM (Deployment Image Servicing and Management) ремонтує саме компонентне сховище (WinSxS) і також обслуговує офлайн-образи. Якщо сховище пошкоджене або бракує частин, SFC не зможе взяти чисті заміни — тому він скаржиться, зациклюється або «ремонтує» в напівзламаному стані.

У виробничому мисленні: вважаємо DISM тим, що ремонтує склад пакетів; SFC — файли на полицях. Якщо інвентар на складі неправильний, полиці ніколи не залишаться вірними.

Правило великого пальця, що витримує тиск:

• Якщо Windows запущена і ви підозрюєте корупцію: спочатку DISM, потім SFC.
• Якщо ви вже запускали SFC і він не може відновити: перестаньте його перезапускати і переходьте до DISM.
• Якщо DISM не може знайти джерела: потрібне відповідне інсталяційне джерело (WIM/ESD) або робочий шлях WSUS/Windows Update.

Одна цитата, яку варто «татуїрувати» в каналі інцидентів:

«Надія — це не стратегія.» — Gen. Gordon R. Sullivan

І невеликий жарт на початок: SFC — це стажер, що перевіряє кожний файл; DISM — навантажувач, що ремонтує склад. Не просіть стажера перебудувати склад.

Швидкий план діагностики (перевірте це перш ніж)

Це «я маю 10 хвилин до закінчення вікна змін» триаж. Ви намагаєтесь знайти вузьке місце: диск, стек обслуговування, відсутні джерела або просто оманливий симптом.

1) Переконайтеся, що ви з правами адміністратора і на правильній машині

Якщо ви в віддаленій сесії або маєте проблеми з UAC, половина ваших команд може брешучи мовчати.

2) Перевірте вільне місце на диску та явні проблеми I/O

Обслуговування потребує місця. На переповнених системах DISM повертає помилки, що виглядають як корупція, але насправді означають «немає місця для відновлених файлів». Також перевірте, що диск не в стані поступового відмирання.

3) Запитайте DISM, чи компонентне сховище взагалі підлягає відновленню

Використовуйте перевірки здоров’я DISM, щоб вирішити, чи робитимете швидкий ремонт, ремонт із джерелом чи офлайн-відновлення.

4) Якщо DISM потребує джерел, оберіть шлях джерел негайно

Windows Update через інтернет, WSUS чи локальний ISO? Не гадати. Виберіть одне і дотримуйтеся його.

5) Тільки потім запускайте SFC

SFC — останній крок для онлайн-ремонту. Якщо він не вдасться після чистого запуску DISM, ймовірно у вас або офлайн-пошкодження файлів, сторонні фільтри драйверів, або глибша проблема зі стеком обслуговування.

Цікаві факти та історія (щоб логи мали сенс)

• SFC походить із концепцій захисту файлів ери Windows 98/2000: ідея — системні файли не повинні випадково перезаписуватися — живе вже десятиліттями, еволюціонувавши від Windows File Protection до Windows Resource Protection.
• WinSxS — це не кеш дублікатів «без причини»: це бок-о-бок компонентне сховище, що підтримує обслуговування, відкат і кілька версій компонентів. Воно здається марнотратним, поки ви не спробуєте патчити мільйони машин надійно.
• DISM замінив старі інструменти обслуговування (наприклад PEIMG і Package Manager) у міру переходу Windows до уніфікованої моделі обслуговування онлайн та офлайн-образів.
• «Не знайдено файлів джерела» часто означає «версія не відповідає», а не що джерела немає. Машина Windows 11 23H2 не задовольнить випадковий ISO 22H2.
• Оновлення стека обслуговування (SSU) — особливі: вони оновлюють механіку встановлення оновлень. Якщо ця механіка зламана, оновлення й ремонти стають болісно циклічними.
• CBS.log — це місце події: SFC пише деталі через Component-Based Servicing engine. Вивід у консоль навмисно стиснений; реальна історія в логах.
• Перевірки здоров’я DISM дешевші, ніж ремонти: /CheckHealth швидкий; /ScanHealth докладний і повільніший; /RestoreHealth — це фактична спроба виправлення.
• Сторонні фільтрувальні драйвери можуть саботувати ремонти: антивірус, DLP, шифрування та «endpoint» інструменти часто підключаються до файлових операцій так, що SFC/DISM виглядають ненадійними.

Підготовка: умови, що забезпечують успішний ремонт

Перш ніж кидати команди в систему, витратьте 2 хвилини на підготовку. Саме тут народжуються більшість «DISM failed» звернень.

Запускайте в правильному середовищі, з правами адміністратора

Використовуйте Windows Terminal або PowerShell, запущений «Від імені адміністратора». Якщо ви в обмеженому середовищі (віддалені інструменти, Just Enough Administration, захищені сервери), підтвердіть, що маєте права на обслуговування образу.

Майте достатньо вільного місця

Як правило: тримайте щонайменше 10–15 ГБ вільних на системному томі для комфортного обслуговування. Нестача місця приводить до часткових операцій і оманливих помилок.

Зробіть шлях Windows Update / WSUS явним

DISM може завантажувати контент для ремонту з Windows Update, якщо політика це не блокує. У корпоративних середовищах політики часто блокують це і WSUS не хостить payload’и «features on demand». Так з’являються коди помилок, що виглядають як корупція, але насправді — «джерело недоступне».

Очікуйте перезавантажень

Обслуговування може створювати відкладені дії. Якщо є відкладений перезапуск, вирішіть його одразу. Не накладайте п’ять спроб ремонту поверх відкладеного перезавантаження і потім дивуйтеся, чому логи виглядають як спагетті.

Практичні завдання з ремонту (команди, виходи, рішення)

Нижче реальні завдання, які можна виконати з піднятими правами PowerShell. Кожне містить (1) команду, (2) що означає типовий вивід, та (3) яке рішення виконати далі.

Завдання 1: Підтвердіть підвищені права та контекст

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() | % { $_.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) }"
True

Значення: True означає, що ви з правами адміністратора. False означає зупинитися: SFC/DISM будуть частковими, зазнають помилок або брешуть.

Рішення: Якщо False, перезапустіть PowerShell «Запуск від імені адміністратора» (або виправте політику віддалення/ JEA).

Завдання 2: Швидка перевірка вільного місця на диску

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Name,Used,Free | Format-List"
Name : C
Used : 178.42 GB
Free : 24.88 GB

Значення: Якщо вільного місця мало (однозначні ГБ), ремонти можуть пройти нестабільно.

Рішення: Якщо мало місця — звільніть його спочатку (видаліть тимчасові файли, перенесіть дані або розширте диск). Не «пробуйте все одно» і не створюйте нового пошкодження.

Завдання 3: Перевірка наявності відкладеного перезавантаження (обслуговування часто його потребує)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"
True

Значення: True вказує на те, що потрібне перезавантаження.

Рішення: Перезавантажте зараз, якщо можете. Якщо не можете — очікуйте, що DISM/SFC поводитимуться дивно і логуватимуть «відкладені операції».

Завдання 4: Швидка перевірка DISM (чи вже відмічена корупція?)

cr0x@server:~$ dism /online /cleanup-image /checkhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

Значення: «No corruption detected» — це добрий знак. Це не доводить, що система здорова; це означає, що DISM не вважає сховище компонентів пошкодженим.

Рішення: Якщо ви переслідуєте дивну поведінку системних файлів, продовжуйте з SFC. Якщо падають оновлення, розгляньте запуск /ScanHealth все одно.

Завдання 5: Глибша перевірка DISM (більш авторитетна)

cr0x@server:~$ dism /online /cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The component store is repairable.
The operation completed successfully.

Значення: «Repairable» означає, що DISM виявив корупцію і вважає, що може її виправити.

Рішення: Запустіть /RestoreHealth. Якщо воно скаже «not repairable», зупиніться і плануйте офлайн-ремонт або in-place upgrade.

Завдання 6: Ремонт DISM з використанням Windows Update (стандартний онлайн-шлях)

cr0x@server:~$ dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Значення: Це сигнал «склад відремонтовано».

Рішення: Тепер запустіть SFC. Якщо SFC все ще не може відновити, ймовірно проблеми з файловою системою, сторонніми фільтрами або сценарієм, що вимагає офлайн-режиму.

Завдання 7: Запуск SFC для ремонту (після DISM)

cr0x@server:~$ sfc /scannow
Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log

Значення: SFC знайшов невідповідності й виправив їх. Ви ще не завершили, доки система не почне поводитися коректно і оновлення не встановлюються, але можна видихнути.

Рішення: Перезавантажте, якщо можливо. Потім запустіть SFC ще раз; «no integrity violations» — ваш чистий вердикт.

Завдання 8: Перевірочний запуск SFC (підтвердити чистий стан)

cr0x@server:~$ sfc /scannow
Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

Значення: Це бажаний результат після ремонтів.

Рішення: Якщо симптоми залишаються, припиніть звинувачувати «корупцію» і досліджуйте драйвери, профілі, політики або конкретний компонент, що ламається.

Завдання 9: Коли DISM повертає «source files could not be found»

cr0x@server:~$ dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Error: 0x800f081f

The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature.

Значення: DISM не зміг отримати потрібний payload. Поширені причини: WSUS не надає їх; доступ до Windows Update заблоковано; система офлайн; або потрібен відповідний ISO.

Рішення: Переключіться на відоме робоче джерело (підключений ISO з відповідною збіркою) і повторіть спробу з /Source та /LimitAccess.

Завдання 10: Підключіть ISO і визначте правильний індекс

cr0x@server:~$ powershell -NoProfile -Command "Mount-DiskImage -ImagePath 'C:\ISO\Win11_23H2_English_x64.iso'; (Get-Volume -DiskImage (Get-DiskImage -ImagePath 'C:\ISO\Win11_23H2_English_x64.iso')).DriveLetter"
E

cr0x@server:~$ dism /get-wiminfo /wimfile:E:\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : E:\sources\install.wim

Index : 1
Name : Windows 11 Home
Description : Windows 11 Home

Index : 6
Name : Windows 11 Pro
Description : Windows 11 Pro

The operation completed successfully.

Значення: Вам потрібен індекс, що відповідає встановленому виданню (Home/Pro/Enterprise). Використання неправильного індексу може спричинити помилку або «успіх», який насправді не надає потрібних компонентів.

Рішення: Визначте своє видання (наступне завдання), потім оберіть правильний індекс.

Завдання 11: Підтвердіть встановлене видання/збірку (щоб співставити джерело)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber"
WindowsProductName : Windows 11 Pro
WindowsVersion     : 23H2
OsBuildNumber      : 22631

Значення: Ваш ISO має відповідати основній версії/родині збірки. Невідповідність — класична причина 0x800f081f.

Рішення: Використайте індекс «Pro» (з попереднього виводу: індекс 6) і переконайтеся, що ISO належить до того ж каналу випуску.

Завдання 12: Ремонт DISM з локальним WIM-джерелом (надійно в закритих мережах)

cr0x@server:~$ dism /online /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Значення: Ви відновили, використовуючи локальний носій, а не Windows Update.

Рішення: Запустіть SFC наступним кроком. Якщо SFC все ще не справляється, ймовірно проблеми з файловою системою або агресивними endpoint-інструментами.

Завдання 13: Якщо ISO містить install.esd, використайте його як джерело

cr0x@server:~$ dism /get-wiminfo /wimfile:E:\sources\install.esd
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : E:\sources\install.esd

Index : 6
Name : Windows 11 Pro
Description : Windows 11 Pro

The operation completed successfully.

cr0x@server:~$ dism /online /cleanup-image /restorehealth /source:esd:E:\sources\install.esd:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Значення: ESD працює; він просто більше стиснутий. DISM підтримує його з правильним префіксом.

Рішення: Те ж саме: запустіть SFC, перезавантажтеся, перевірте.

Завдання 14: Витягніть історію SFC з CBS.log (не читайте всю повість)

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir'\Logs\CBS\CBS.log' -Pattern '\[SR\]' | Select-Object -Last 20"
2026-02-05 09:12:41, Info                  CSI    0000032f [SR] Repairing corrupted file \??\C:\Windows\System32\example.dll from store
2026-02-05 09:12:42, Info                  CSI    00000330 [SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction have been successfully repaired

Значення: Рядки з [SR] стосуються SFC. Ви бачите точно, що було відремонтовано (або що не вдалося відремонтувати).

Рішення: Якщо бачите повторювані «cannot repair member file», повертайтеся до якості джерела DISM або розгляньте офлайн-ремонт.

Завдання 15: Читайте логи DISM, коли код помилки нечіткий

cr0x@server:~$ powershell -NoProfile -Command "Get-Content $env:windir'\Logs\DISM\dism.log' -Tail 30"
2026-02-05 09:04:17, Error                 DISM   DISM Package Manager: PID=1220 TID=2480 Failed finalizing changes. - CDISMPackageManager::Finalize(hr:0x800f081f)
2026-02-05 09:04:17, Error                 DISM   DISM Package Manager: PID=1220 TID=2480 The source files could not be found; using /Source is required.

Значення: Логи DISM часто вказують, що саме він намагався (Windows Update? WSUS? локально?) і де він зазнав невдачі.

Рішення: Якщо політика ніколи не дозволяла звертатися до Windows Update, виправте політику або використайте /Source. Якщо воно спробувало джерело і відхилило його — ваше джерело не відповідає.

Завдання 16: Очищення компонентного сховища (корисно, але не як панацея)

cr0x@server:~$ dism /online /cleanup-image /startcomponentcleanup
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The operation completed successfully.

Значення: Це зменшує кількість застарілих компонентів; може звільнити місце на диску і знизити складність обслуговування з часом.

Рішення: Запускайте це після того, як система стала здоровою, а не як перший крок для лікування корупції.

Завдання 17: Виявлення ознак пошкодження файлової системи (бо SFC не виправить «брехливий» диск)

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

Значення: Якщо CHKDSK повідомляє про помилки, ваша корупція може бути на рівні зберігання. DISM/SFC не переважають погані сектори або пошкоджену метадані.

Рішення: Якщо є помилки: заплануйте офлайн-ремонт (chkdsk /f потребує простою), перевірте SMART і підозрівайте проблеми з обладнанням чи віртуальним диском.

Другий короткий жарт (і останній): індикатори прогресу DISM схожі на табло прибуття в аеропорту — оптимістичні, нечіткі і час від часу не мають відношення до реальності.

Офлайн та «без інтернету» стратегії відновлення

Іноді не вдається виправити онлайн-образ: він не завантажується стабільно, Windows Update заблоковано, компонентне сховище занадто пошкоджене, або машина в обмеженій мережі. Це не кінець; просто змінює план.

Офлайн-обслуговування: вкажіть DISM на папку Windows, що не запущена

Якщо ви завантажилися в WinRE/WinPE або підключили диск ОС до іншої системи, ви можете ремонтувати образ офлайн. Ключ — знати, який буквенний позначення диска відповідає чому в середовищі відновлення.

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.22621.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy
  Volume 1     C   OS           NTFS   Partition    237 GB  Healthy

Рішення: Визначте офлайн-папку Windows, наприклад C:\Windows у WinRE (вона може бути D: на деяких системах). Потім:

cr0x@server:~$ dism /image:C:\ /cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The component store is repairable.
The operation completed successfully.

Якщо у вас локальний інсталяційний носій змонтований як E::

cr0x@server:~$ dism /image:C:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Офлайн SFC (корисно після DISM на офлайн-образі)

SFC може націлюватися на офлайн-папку Windows із явними шляхами.

cr0x@server:~$ sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
Beginning system scan.  This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.

Рішення: Якщо офлайн DISM+SFC вдались, а система все одно не завантажується, ймовірно ти маєш справу з завантажувачем/BCD, проблемним драйвером або невдалим оновленням, що потребує відкату — а не з універсальною корупцією.

Коли джерела — це проблема: відповідність важливіша за «найновіше»

Якщо зробити одну річ правильно: підбирайте інсталяційний носій, що відповідає встановленій збірці і виданню. Люди люблять брати «найновіший ISO». Ось як ви марнуєте вечір.

Практичний підхід в підприємствах:

• Підтримуйте невелику внутрішню бібліотеку ISO для кожного каналу випуску, який використовує ваш парк.
• Фіксуйте номери збірок у CMDB/інвентарі.
• Коли DISM ламається, не імпровізуйте — діставайте відоме відповідне зображення.

Поширені помилки: симптом → корінь проблеми → виправлення

Цей розділ навмисно різкий. Більшість «таємниць» SFC/DISM — самонаслані.

1) Симптом: «SFC знайшов пошкоджені файли, але не зміг відновити деякі з них.»

Корінь проблеми: Пошкодження компонентного сховища або відсутні payload’и. SFC намагається замінити файли з поламаного сховища.

Виправлення: Запустіть dism /online /cleanup-image /restorehealth. Якщо воно помилиться 0x800f081f, використайте відповідний ISO з /source:wim:... /limitaccess. Потім перезапустіть SFC.

2) Симптом: DISM ламається з 0x800f081f «source files could not be found.»

Корінь проблеми: Нема доступу до payload’ів Windows Update, WSUS не має Features on Demand, або невідповідне джерело медіа.

Виправлення: Використовуйте локальний WIM/ESD з правильним індексом. Якщо політика блокує WU, додайте /LimitAccess, щоб змусити локальний режим і уникнути довгих тайм-аутів.

3) Симптом: DISM зависає на 20% або 62% назавжди.

Корінь проблеми: Не обов’язково застряг — фази DISM нерівномірні. Але це також може бути повільне зберігання, антивірус сканує кожний файл або блокування стека обслуговування.

Виправлення: Перевірте затримки диска (Диспетчер завдань, лічильники perf), тимчасово відключіть інтенсивне сканування endpoint, якщо політика дозволяє, і стежте за dism.log за прогресом. Якщо лог не рухається — перезавантажте і спробуйте ще раз; потім перейдіть до офлайн-обслуговування.

4) Симптом: SFC постійно «ремонтує» одні й ті ж файли після кожного перезавантаження.

Корінь проблеми: Хтось або щось перезаписує системні файли: сторонні «тюнінг»-інструменти, застарілі драйвери, засоби безпеки або погано налаштоване управління конфігурацією.

Виправлення: Перевірте CBS [SR] записи на імена файлів; зіставте з встановленим ПЗ і оновленнями драйверів. Видаліть винуватця. Повторіть DISM+SFC для стабілізації.

5) Симптом: «The component store is not repairable.»

Корінь проблеми: Важке пошкодження компонентного сховища, часто ускладнене невдалими оновленнями або корупцією зберігання.

Виправлення: Спробуйте офлайн DISM з правильним джерелом. Якщо і тоді не ремонтується — прагматичний шлях: in-place upgrade repair або перевстановлення. Не витрачайте дні на марні спроби бути героєм.

6) Симптом: DISM каже «успішно», але Windows Update все одно не працює.

Корінь проблеми: Не всі збої оновлень пов’язані з корупцією компонентного сховища. Це може бути проблема стека обслуговування, відкладені дії або проблеми з WSUS-метаданими.

Виправлення: Перевірте ключі відкладеного перезавантаження, перегляньте події WindowsUpdateClient і підтвердіть застосовність SSU/LCU. Використайте логи DISM та журнали подій для визначення пакета, що ламається.

7) Симптом: SFC миттєво ламається або повідомляє, що не може виконати операцію.

Корінь проблеми: Служба Windows Modules Installer (TrustedInstaller) відключена, Windows Resource Protection пошкоджено, або помилки файлової системи.

Виправлення: Переконайтеся, що служба TrustedInstaller не відключена; перевірте chkdsk; потім запустіть DISM. Якщо сервіси обслуговування пошкоджені — розгляньте офлайн-ремонт.

8) Симптом: Ремонти працюють на ноутбуках, але не на серверах (або навпаки).

Корінь проблеми: Різні канали обслуговування, різні політики (WSUS), різні базові образи або різне endpoint-ПЗ.

Виправлення: Стандартизуйте джерела для кожної родини ОС. Документуйте, чи дозволено DISM звертатися до Windows Update. Не припускайте однорідності по всьому парку.

Три корпоративні міні-історії з реального життя

Інцидент 1: Неправильне припущення (WSUS означає, що DISM знайде джерела)

Фінансова організація мала стабільний парк Windows 10 під керуванням WSUS. Оновлення були «керовані», що в корпоративній мові означає «ніхто не пам’ятає, навіщо це було налаштовано». Частина машин почала давати збій при встановленні накопичувальних оновлень після рутинного циклу. Хелпдеск постійно запускав SFC, отримував звичне «unable to fix some files» і ескалював.

Сисадмін на виклику зробив правильно і спробував DISM. Воно впало з 0x800f081f. Припущення було миттєвим: «Але у нас є WSUS. Він має бінарники.» Це припущення — пастка. WSUS часто хостить оновлення, але не обов’язково повні payload’и і Features on Demand, які очікує DISM для відновлення компонентного сховища.

Вони втратили день на різні послідовності, перезавантаження і багато марних спроб. Виправлення виявилося соромно простим, коли прийшло усвідомлення: змонтувати відповідний інсталяційний носій, запустити DISM з локальним /Source і /LimitAccess, а потім SFC.

Що змінилося після інциденту — не лише рунабук. Вони додали жорстку вимогу: для кожної підтримуваної збірки ОС має бути відповідний ISO на внутрішньому сховищі, а звернення повинні містити номер збірки і видання. Режим відмови зник, бо перестали плутати «керовані оновлення» з «доступними джерелами ремонту».

Інцидент 2: Оптимізація, що зіграла злий жарт (агресивне очищення під час вікон патчів)

Велике підприємство вирішило економити місце після кількох відмов серверів через повні C: томи. Хтось запровадив політику «очищення»: регулярно запускати компонентне очищення і видаляти тимчасові файли під час вікон технічного обслуговування. На папері — розумно. На практиці вони комбінували це з патчингом і відкладенням перезавантажень.

Під час одного вікна патчів набір серверів почав повідомляти аномалії обслуговування. DISM став повільним, іноді завершувався тайм-аутом. SFC почав повторно знаходити корупцію. Команда була переконана в зараженні або проблемах з масивом зберігання.

Насправді вони самі створили конфлікт обслуговування. Очищення запускалося під час стадії підготовки оновлень, а антивірус сканував файл-волокиту, що утворювалася. Компонентне сховище не було «пошкоджене» стільки, скільки постійно «в русі», з відкладеними операціями і великою активністю файлів. Вони оптимізували «менше місця» і випадково оптимізували втрачену «передбачувану підтримку».

Виправлення було нудним: розділити етапи обслуговування. Патчити, перезавантажити, валідувати. Лише після цього запускати очищення компонентів і лише коли є потреба. Продуктивність стабілізувалася, інструменти ремонту перестали тайм-аутитися, інциденти такого класу зникли.

Інцидент 3: Нудна, але правильна практика (логи перш ніж, runbook під контролем версій)

Медична компанія мала суворий контроль змін і команду безпеки, що не любила імпровізації. Команда Windows побудувала рунабук у вигляді SRE-плейбука: перевірки перед стартом, точки прийняття рішень і точні команди. Він був під контролем версій і оновлювався після кожного розбору інциденту.

Одного дня група кіосків почала відмовляти при запуску додатків після оновлення. Перші техніки слідували рунабку: перевірити вільне місце, перевірити відкладене перезавантаження, DISM scan, DISM restore, SFC, потім витягти рядки [SR] з CBS.log. Замість «спробувати щось», вони повернулися з доказами: DISM не зміг отримати джерело через політику, і індекс джерела не відповідав встановленому виданню.

Платформна команда не мусила підключатися і гадати. Вони розмістили відповідний ISO на файловому шарі, відкоригували рунабук, щоб включити перевірку видання, і виправили парк. Ніхто не святкував, бо це було рутинно — а це найвища похвала в операціях.

Урок: нецікава практика — логи перш ніж, повторювані кроки, відоме-робоче джерело — перемагає героїзм. Кожного разу.

Чеклісти / покроковий план

Чекліст A: Стандартний онлайн-ремонт (рекомендований за замовчуванням)

1. Відкрийте PowerShell від імені адміністратора.
2. Підтвердьте вільне місце (ціль — 10–15 ГБ+ на C:).
3. Перевірте відкладене перезавантаження; перезавантажте, якщо можна.
4. Запустіть dism /online /cleanup-image /checkhealth.
5. Якщо щось підозріле або оновлення падають — запустіть /scanhealth.
6. Запустіть dism /online /cleanup-image /restorehealth.
7. Запустіть sfc /scannow.
8. Перезавантажте.
9. Запустіть sfc /scannow ще раз, щоб підтвердити «no integrity violations».
10. Якщо все ще зламано, витягніть релевантні рядки з CBS.log і прочитайте dism.log перед наступними діями.

Чекліст B: Закрита корпоративна мережа (без доступу до Windows Update)

1. Підтвердіть видання та збірку ОС (Get-ComputerInfo).
2. Підключіть відповідний ISO для цього релізу і видання.
3. Отримайте індекси WIM/ESD (dism /get-wiminfo).
4. Запустіть dism /online /cleanup-image /restorehealth /source:wim:...:INDEX /limitaccess (або ESD еквівалент).
5. Запустіть SFC.
6. Якщо помилки залишаються — перегляньте CBS/DISM логи і розгляньте офлайн-ремонт.

Чекліст C: Офлайн-ремонт (система нестабільна або не завантажується)

1. Завантажтеся в WinRE/WinPE.
2. Визначте буквенний позначник тома ОС (diskpart або перевірка dir).
3. Підключіть відповідний інсталяційний носій.
4. Запустіть DISM проти офлайн-образу: dism /image:X:\ /cleanup-image /restorehealth /source:wim:....
5. Запустіть офлайн SFC з /offbootdir і /offwindir.
6. Перезавантажте і перевірте.
7. Якщо все ще не працює: плануйте in-place repair або перевстановлення. Час — теж ресурс.

Операційні запобіжні заходи (чого уникати)

• Не запускайте SFC десять разів в надії, що «врешті-решт» він все виправить. Це не наполегливість; це заперечення.
• Не поєднуйте очищення, патчинг і ремонти в тому самому вікні технічного обслуговування, якщо вам не до душі неоднозначні результати.
• Не припускайте, що ваш ISO «достатньо близький» до збірки. Обслуговування прискіпливе, бо має бути точним.
• Не ігноруйте здоров’я зберігання. Корупція часто має апаратного спільника.

Питання та відповіді

1) Що запускати спочатку: SFC чи DISM?

На працюючій інсталяції Windows: спочатку DISM, потім SFC. DISM ремонтує компонентне сховище, від якого залежить SFC.

2) Що насправді означає «Windows Resource Protection found corrupt files»?

Це означає, що файли на диску не збігалися з очікуваними захищеними версіями. Якщо написано, що їх відновлено, то з диску сховища було скопійовано відомі добрі версії (або проміжні заміни) і про це є деталі в CBS.log.

3) Якщо DISM каже «No component store corruption detected», чи можна зупинитися?

Якщо ваша єдина мета — здоров’я компонентного сховища, так. Якщо є симптоми — збої, падіння додатків — все одно запустіть SFC. DISM може бути чистим, а окремі системні файли — неправильними.

4) Чому DISM ламається з 0x800f081f, хоча у мене є ISO?

Найчастіше тому, що ISO не відповідає встановленій родині збірки або ви використали неправильний індекс (видання). Підтвердіть збірку/видання, потім використайте правильний WIM/ESD індекс у /Source.

5) Чи безпечно запускати DISM і SFC на продуктивних серверах?

Загалом так, але ставте це в планове технічне обслуговування: заплануйте, слідкуйте за відкладеним перезавантаженням і очікуйте впливу на продуктивність. Для навантажень, чутливих до затримок, запускайте в тихий час.

6) Чи треба вимикати антивірус або endpoint-захист?

За замовчуванням — ні. Але якщо DISM/SFC дуже повільні, багаторазово падають на тих самих файлах або логи показують проблеми з доступом, тимчасове пом’якшення сканування (на підставі політики) може допомогти. Задокументуйте і негайно увімкніть назад.

7) У чому різниця між DISM /CheckHealth і /ScanHealth?

/CheckHealth — швидка перевірка, чи вже було позначено корупцію. /ScanHealth — глибше сканування для виявлення корупції і може займати суттєво більше часу.

8) Чи можуть SFC/DISM виправити проблеми Windows Update?

Іноді. Якщо відмови оновлень спричинені корупцією компонентного сховища — так. Якщо корінь проблеми в метаданих WSUS, політиках, ламаному ланцюжку SSU або відкладених діях — потрібна цільова діагностика оновлень.

9) Коли варто перестати і робити reimage або in-place repair?

Якщо DISM повідомляє, що компонентне сховище не підлягає відновленню, або ремонти вдались, але система залишається нестабільною з повторною корупцією — припиняйте витрачати час. Офлайн DISM з правильним джерелом — остання технічна спроба перед in-place repair/переінсталяцією.

10) Куди дивитися, коли вивід у консолі нічого не пояснює?

C:\Windows\Logs\CBS\CBS.log для деталей SFC (фільтруйте за [SR]). C:\Windows\Logs\DISM\dism.log для рішень DISM, вибору джерел і специфіки помилок.

Висновок: практичні наступні кроки

Якщо Windows поводиться дивно і ви підозрюєте корупцію, не починайте з ритуалів. Починайте з контрольованої послідовності.

1. Переконайтеся, що ви з правами адміністратора і маєте місце на диску.
2. Перезавантажте, якщо є відкладений перезапуск.
3. Запустіть перевірки здоров’я DISM, потім /RestoreHealth.
4. Запустіть sfc /scannow, перезавантажте і підтвердіть чистоту.
5. Якщо DISM не знаходить джерела, припиніть імпровізувати: змонтуйте відповідний інсталяційний носій і використайте /Source з правильним індексом.
6. Якщо результати все ще погані, читайте CBS.log та dism.log перед будь-якими подальшими діями.

Правильний спосіб «відновити Windows» — це не магічна команда. Це запуск ланцюжка ремонтів з чистими вхідними даними, перевірка доказів і прийняття наступного рішення на підставі того, що система вам насправді сказала.