DISM проти SFC: порядок відновлення, що заощаджує години

Єдина модель, яка вам потрібна: що саме торкаються DISM і SFC

SFC (System File Checker) перевіряє і ремонтує захищені системні файли у вашій запущеній інсталяції Windows. Воно порівнює те, що на диску, із відомо добрими версіями — але ці відомо добрі версії десь зберігаються. Тим «де» є Сховище компонентів Windows (WinSxS) і метадані сервісингу.

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

Отже, ваша основна модель:

• DISM ремонтує джерело відновлення. Думайте: «залатати склад».
• SFC ремонтує розгорнуті файли. Думайте: «замінити речі, що вже на полицях».

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

І так, DISM також може обслуговувати офлайн-образи (монтувані WIM, офлайн-директорії Windows). SFC теж може частково працювати в офлайні. Це має значення, коли ви рятуєте машину, яка ледь завантажується, або ремонтуєте золоті образи VDI в масштабі.

Одна робоча цитата, яка варта стікера біля вашого KVM-картир:

«Надія — це не стратегія.» — генерал Гордон Р. Салліван

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

Порядок відновлення, що економить години (і чому)

The default order for a running system

1. DISM health check (швидкий індикатор)
2. DISM RestoreHealth (ремонтує сховище компонентів)
3. SFC /scannow (ремонтує захищені системні файли)
4. Перезавантаження, якщо щось було відновлено
5. Повторний запуск SFC, якщо потрібно (так, іноді двічі)

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

Коли варто порушити правило

Рідко, але ось реальні випадки:

• Ви підозрюєте, що пошкоджені лише кілька файлів (наприклад, один DLL) і вам потрібен швидкий індикатор. Запуск SFC спершу може швидко підтвердити корупцію, але не зупиняйтеся там, якщо він не може відновити.
• Ви офлайн без джерела медіа і DISM не може відновити без нього. SFC може досі виправити деякі файли, якщо сховище частково ціле. Це не ідеально; це тріаж.
• Клієнт Windows Update зламаний і DISM залежить від нього як від джерела. У такому випадку ви вказуватимете DISM локальне джерело усе одно (і все одно запускатимете його перед SFC).

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

Короткий жарт №1: повторний запуск sfc /scannow п’ять разів не робить його більш правильним; він просто робить вас більш оптимістичними, ніж ваша комісія змін.

Факти й історія: чому ремонт Windows виглядає саме так

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

1. SFC передує сучасному компонентному сервісингу. Він походить ери захисту файлів Windows (Windows 2000/XP), коли системні файли охоронялися й замінювалися з кешованих копій.
2. DISM замінив старі інструменти для образів. До DISM були інструменти на кшталт ImageX для роботи з WIM; DISM став швейцарським ножем для обслуговування образів і функцій.
3. Сховище компонентів (WinSxS) — це не «просто дублікати». Це боковий магазин, що підтримує сервісинг, відкат і кілька версій компонентів одночасно.
4. «Корупція сховища компонентів» часто означає корупцію метаданих. Це не завжди відсутні бінарні файли; іноді стан маніфесту/каталогу сервісингу невідповідний.
5. Оновлення стека сервісингу важливі. Стек сервісингу — це механізм, що застосовує оновлення. Коли він зламаний, ремонти можуть зазнавати невдач у способи, які здаються несумісними.
6. DISM може використовувати Windows Update як джерело ремонту. Це зручно — і також причина, чому зламані шляхи оновлення, заблоковані кінцеві точки або неправильна конфігурація WSUS можуть зірвати ремонт.
7. WIM і ESD не взаємозамінні без уваги. У інсталяційному носії може бути install.wim або install.esd; індекси відрізняються за редакціями, і неправильний індекс дасть «джерело файлів не знайдено».
8. Деякі помилки — це політика, а не корупція. Якщо групова політика блокує звернення до Windows Update, DISM може зазнати невдачі навіть на здоровій системі, якщо ви очікуєте, що воно витягне payload-и онлайн.
9. Логи SFC навмисно шумні. CBS-лог фіксує операції сервісингу і може читатися як роман, написаний драйвером принтера. Фільтрація — частина роботи.

Швидкий план діагностики: знайдіть вузьке місце перед тим, як «тестувати все»

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

По-перше: підтвердіть, що проблема справді в корупції

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

По-друге: переконайтеся, що шлях до джерела ремонту життєздатний

• Онлайн: чи машина досягає Windows Update або WSUS? Чи блокує це політика?
• Офлайн: чи у вас є правильний ISO, що відповідає збірці/редакції/мові? Чи знаєте ви правильний індекс образу?

По-третє: перевірте стан диска та вільне місце

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

По-четверте: запустіть перевірки здоров’я DISM перед повним ремонтом

• /CheckHealth швидкий і каже, чи є прапор корупції.
• /ScanHealth повільніший, але дає кращий сигнал.

По-п’яте: відремонтуйте сховище компонентів (DISM), потім системні файли (SFC)

• Спершу DISM. Завжди, якщо тільки ви буквально не можете.
• Потім SFC. Перевірте результати. Перезавантажтеся, якщо був ремонт.

По-шосте: лише потім думайте про ескалацію

• Виконати in-place upgrade repair.
• Відновлення з відомого доброго образу (особливо для флоту).
• Заміна апаратного забезпечення, якщо підозрюються диск або пам’ять.

Практичні завдання: 12+ запусків команд, вивід і рішення

Це написано як рукопис для on-call: запустіть команду, прочитайте вивід, прийміть рішення. Команди показані в стандартизованому консольному форматі. Промпт хоста довільний; важливі саме команди.

Завдання 1: Швидка перевірка стану сховища компонентів (DISM CheckHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

No component store corruption detected.
The operation completed successfully.

Що це означає: DISM не бачить прапора корупції в сховищі компонентів. Це не доводить, що система ідеальна, але дає сильний натяк, що ви можете полювати за чимось іншим (політика, диск, драйвери).

Рішення: Якщо симптоми зберігаються — запустіть /ScanHealth і SFC; інакше перемикайтеся на розслідування логів/оновлень.

Завдання 2: Глибше сканування на корупцію (DISM ScanHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /ScanHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

Що це означає: Є корупція, і DISM вважає, що може її відновити.

Рішення: Запустіть /RestoreHealth далі. Ще не витрачайте час на повторні запуски SFC.

Завдання 3: Відновлення сховища компонентів (DISM RestoreHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

Що це означає: Сховище компонентів відновлено.

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

Завдання 4: Відновлення захищених системних файлів (SFC scannow)

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.

Що це означає: SFC замінив/відновив деякі файли, використовуючи тепер уже здорове сховище.

Рішення: Перезавантажте систему. Потім за потреби повторно запустіть SFC, щоб підтвердити «немає порушень цілісності».

Завдання 5: Коли 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 found corrupt files but was unable to fix some of them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log.

Що це означає: SFC підтвердив корупцію, але не зміг виправити усі випадки — зазвичай тому, що сховище компонентів не здорове або відсутні payload-и.

Рішення: Запустіть DISM /RestoreHealth (з джерелом, якщо потрібно). Потім повторно SFC.

Завдання 6: DISM зазнає невдачі через відсутність файлів джерела (шаблон 0x800f081f)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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/WU заблоковано) або вам потрібне локальне ISO-джерело.

Рішення: Забезпечте дійсне інсталяційне медіа (WIM/ESD), що відповідає збірці й редакції, або виправте підключення до джерела оновлень.

Завдання 7: Ідентифікація індексів образу в інсталяційному носії (WIM/ESD) перед використанням /Source

cr0x@server:~$ DISM /Get-WimInfo /WimFile:D:\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

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

Index : 1
Name : Windows 10 Home
Description : Windows 10 Home
Size : 15,123,456,789 bytes

Index : 6
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 15,987,654,321 bytes

The operation completed successfully.

Що це означає: Інсталяційне медіа містить кілька редакцій; кожна має свій індекс.

Рішення: Використовуйте індекс, що відповідає встановленій редакції (наприклад, Pro). Неправильний індекс = неправильні компоненти = DISM все одно зазнає невдачі.

Завдання 8: Відновлення за допомогою локального WIM-джерела (уникнення залежності від Windows Update)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

Що це означає: DISM відновив, використовуючи наданий WIM і не звертався до Windows Update (/LimitAccess).

Рішення: Запустіть SFC далі. Якщо SFC все ще не може виправити — можливо, глибші проблеми сервісингу, диск або невідповідне медіа/збірка.

Завдання 9: Використання ESD як джерела (поширено на новіших ISO)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:D:\sources\install.esd:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

Що це означає: Та сама концепція, як і з WIM, інший формат контейнера.

Рішення: Якщо ESD не працює, а WIM — працює (або навпаки), ваше медіа може бути неповним або індекс неправильний. Перевірте ISO і вибір індексу.

Завдання 10: Підтвердіть редакцію Windows (щоб не вибрати неправильний індекс)

cr0x@server:~$ DISM /Online /Get-CurrentEdition
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Current edition is:

Current Edition : Professional

The operation completed successfully.

Що це означає: Встановлена редакція — Professional.

Рішення: Зіставте це з індексом WIM/ESD (наприклад, Windows 10 Pro). Не вгадуйте. Вгадування — шлях до «джерело файлів не знайдено».

Завдання 11: Очищення сховища компонентів (лише після відновлення здоров’я)

cr0x@server:~$ DISM /Online /Cleanup-Image /StartComponentCleanup
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

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

Рішення: Використовуйте після успішних ремонтів, не до. Якщо сховище пошкоджене, «очищення» може ускладнити відновлення, видаливши матеріали для відкату.

Завдання 12: Офлайн-ремонт DISM (коли Windows не завантажується коректно)

cr0x@server:~$ DISM /Image:E:\ /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

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

Що це означає: Ви відновили офлайн-інсталяцію Windows, що знаходиться на E:\.

Рішення: Далі запустіть офлайн SFC проти тієї самої директорії Windows, потім спробуйте завантаження. Якщо це не допомагає — рухаєтесь до in-place upgrade repair або перевстановлення образу.

Завдання 13: Офлайн SFC-сканування і ремонт (цільові директорії)

cr0x@server:~$ sfc /scannow /offbootdir=E:\ /offwindir=E:\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.

Що це означає: SFC відремонтував офлайн-інсталяцію. Це еквівалент звичайного робочого процесу в режимі порятунку.

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

Завдання 14: Витягнути релевантні рядки SFC з CBS.log (зменшити шум)

cr0x@server:~$ findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfc-details.txt

Що це означає: Фільтрує записи CBS-логу, позначені SFC («[SR]»), у менший файл, який легше читати без втрати бажання жити.

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

Завдання 15: Перевірити вільне місце (сервісингу потрібне простір для дихання)

cr0x@server:~$ fsutil volume diskfree C:
Total # of free bytes        : 10737418240
Total # of bytes             : 255852544000
Total # of avail free bytes  : 10737418240

Що це означає: Близько 10 ГБ вільного. Це гранично, але зазвичай працює. Сервісинг може вимагати кілька ГБ залежно від очікуваних операцій.

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

Завдання 16: Перевірити диск на помилки файлової системи (коли корупція повертається)

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.

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

Рішення: Якщо CHKDSK повідомляє про помилки — виправте їх спочатку (можливо офлайн). Повторний запуск DISM/SFC на пошкодженій файловій системі — як підмітання під час протікання водопроводу.

Короткий жарт №2: прогрес DISM застряг на 20% — це спосіб Windows навчати терпіння без ввічливості програми.

Три корпоративні міні-історії (реалістичні, анонімізовані, болючі)

Міні-історія №1: Інцидент через хибне припущення

Черга helpdesk почала заповнюватися повідомленнями «Outlook падає при запуску» і «Teams не оновлюється». Не одна машина. Дюжини. Спільний зв’язок не був очевидним, бо флот охоплював кілька сайтів і моделей апаратного забезпечення.

Інженер зробив класичне припущення: «це погане оновлення додатку». Вони відкотили Office на декількох машинах. Без змін. Вони перемикали політики антивірусу. Без змін. Потім запустили sfc /scannow на одній машині, побачили «corrupt files repaired» і оголосили перемогу. Наступного дня ті самі машини знову зламались.

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

Фікс не був героїчним. Він був дисциплінований. Спершу стабілізували шлях джерела оновлень, потім запустили DISM /RestoreHealth, використовуючи локальний ISO з /LimitAccess, щоб уникнути зламаного мережевого шляху, і лише потім SFC. Машини перестали рецидивувати. Хибне припущення було не в «SFC не потрібен». Хибне припущення було в тому, що «краш додатку — це завжди проблема додатку». У світі Windows крахи додатків часто — дим, а не вогонь.

Міні-історія №2: Оптимізація, що обернулась проти команди

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

Це працювало — до певного моменту. Хвиля машин почала зазнавати несправностей при установці функцій за вимогою і деяких кумулятивних оновлень. DISM /RestoreHealth почав частіше скаржитися на відсутні файли джерела. Політика очищення зменшила локальну доступність застарілих компонентів, що нормально, коли Windows Update здоровий, але їхнє середовище мало «роздвоєний» сценарій оновлень: деякі сайти використовували WSUS, деякі — прямий доступ, деякі — за суворими правилами виходу в інтернет.

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

Команда відкочувала найагресивніший графік очищення, документувала, коли запускати /StartComponentCleanup, і стандартизувала процес локального ISO для віддалених сайтів. Урок не в «ніколи не очищати». Урок у тому, що «не оптимізуйте свої шляхи відновлення, якщо джерело істини не є по-справжньому надійним».

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Фінансова компанія (анонімізована, але ви уявляєте тип) мала строгий конвеєр золотого образу для VDI. Щомісяця: патчити базовий образ, валідувати, закривати, публікувати. Нудно. Передбачувано. Трохи душогубно. І надзвичайно ефективно.

Одного місяця, після патчів, випадкові VDI-інстанси почали відмовляти при запуску додатків з дивними помилками DLL. Інженери запідозрили новий кумулятивний оновлення. Команда безпеки запідозрила засоби контролю кінцевих точок. Усі звинувачували всіх. Тим часом трейдери хотіли своїх робочих столів вчора.

Нудна практика команди VDI була простою: вони завжди запускали перевірки здоров’я DISM і SFC на золотому образі перед його закриттям, і архівували вивід і фрагменти CBS разом з артефактами збірки. Цього разу DISM /ScanHealth виявив ремонтоздатну корупцію в образі перед його широким розгортанням.

Вони відновили образ за допомогою DISM з контрольованим джерелом, повторно запускали SFC поки не отримали відсутність порушень цілісності, а потім опублікували. Аварія залишилася малою. Постмортем був коротким. Їхній «нудний» рукопис запобіг класичній проблемі флоту: відправці корупції як фічі.

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

1) Симптом: SFC каже, що він відремонтував файли, але проблеми повертаються після оновлень

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

Виправлення: Запустіть DISM /ScanHealth і /RestoreHealth (використайте відомо-добре джерело, якщо шлях оновлень сумнівний), потім знову SFC. Підтвердіть стабільність джерела оновлень.

2) Симптом: «Windows Resource Protection found corrupt files but was unable to fix some of them»

Корінна причина: SFC не може знайти добрі замінники в сховищі компонентів, або файли заблоковані/очікують заміни.

Виправлення: Спершу DISM /RestoreHealth. Перезавантаження. Повторний запуск SFC. Якщо все ще не вдається, запустіть SFC офлайн з WinRE.

3) Симптом: помилка DISM 0x800f081f («source files could not be found»)

Корінна причина: Відсутні payload-и і немає дійсного джерела; неправильний ISO/збірка/редакція; політика блокує Windows Update; WSUS не містить контенту.

Виправлення: Використайте /Source:WIM: або /Source:ESD: з правильним індексом, додайте /LimitAccess, і переконайтеся, що ISO відповідає встановленій збірці/редакції/мові.

4) Симптом: DISM «застряє» на відсотку довгий час

Корінна причина: Працює інтенсивно (хеш-верифікація, аналіз компонентів) на тлі поганої продуктивності диска, сканування антивірусом або великого навантаження.

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

5) Симптом: DISM пройшов, SFC усе ще падає на тих самих файлах

Корінна причина: Неправильне джерело ремонту (несумісність редакції/індексу), драйвери фільтрів від третіх сторін, або корупція в областях, які SFC не виправляє (або файли замінюються під час завантаження).

Виправлення: Підтвердіть редакцію за допомогою DISM /Get-CurrentEdition, підтвердіть індекс WIM, повторіть з правильним джерелом. Спробуйте офлайн SFC. Якщо наполегливо — розгляньте in-place upgrade repair.

6) Симптом: Встановлення функції не вдається (NetFx3, RSAT, мовні пакети) і DISM скаржиться

Корінна причина: Payload-и не присутні локально і Windows Update/WSUS не може їх надати; очищення компонентів видалило локальні копії.

Виправлення: Забезпечте джерело, що відповідає ОС, і використайте /LimitAccess. Стандартизируйте розподіл payload-ів функцій, якщо у вас закрито мережу.

7) Симптом: Ремонти пройшли, але оновлення все одно не вдаються

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

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

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

Чекліст A: Стандартний онлайн-ремонт (більшість випадків)

1. Переконайтеся у вільному місці (ціль — кілька ГБ, чим більше — тим краще).
2. Запустіть DISM /CheckHealth.
3. За потреби запустіть DISM /ScanHealth.
4. Запустіть DISM /RestoreHealth.
5. Запустіть sfc /scannow.
6. Перезавантажтеся, якщо щось було відновлено.
7. Повторно запустіть sfc /scannow, щоб підтвердити «немає порушень цілісності».
8. Якщо оновлення не вдавалися, повторіть спробу встановлення оновлення.

Чекліст B: Онлайн-ремонт з контрольованим джерелом (WSUS/WU ненадійні або заблоковані)

1. Підмонтуйте правильний ISO (який якомога точніше відповідає збірці/редакції).
2. Знайдіть правильний індекс за допомогою DISM /Get-WimInfo.
3. Запустіть DISM /RestoreHealth з /Source і /LimitAccess.
4. Запустіть sfc /scannow.
5. Перезавантажтесь і валідуйте.

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

1. Визначте літеру тома Windows у середовищі відновлення (вона може бути не C:).
2. Запустіть офлайн DISM проти /Image:<drive>:\ з відомо-добрим джерелом.
3. Запустіть офлайн SFC з /offbootdir і /offwindir.
4. Перезавантажтеся і перевірте.
5. Якщо корупція повертається швидко — пріоритет перевірці диска й пам’яті.

Чекліст D: Практика для флоту (як припинити робити це вручну на одній машині)

1. Стандартизируйте ремонтні носії для кожної збірки й редакції ОС, які ви підтримуєте.
2. Документуйте мапінг індексів один раз; не винаходьте його під час інцидентів.
3. Застосуйте порядок DISM-потім-SFC у рукописах та скриптах.
4. Збирайте і централізуйте результати (успіх/помилка + ключові коди помилок), щоб помічати патерни.
5. Якщо ви бачите повторювані 0x800f081f — виправте доставку джерел оновлень або зробіть ISO джерела доступними.

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

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

У більшості випадків спершу DISM: відновіть сховище компонентів, а потім запустіть SFC, щоб відновити захищені системні файли. Залежності побудовані саме так.

2) Якщо DISM каже «No component store corruption detected», чи марний тоді SFC?

Ні. DISM перевіряє сховище; SFC перевіряє розгорнуті системні файли. Ви можете мати проблеми на рівні файлів без корупції сховища. Запустіть SFC, якщо симптоми вказують на пошкодження системних файлів.

3) Чому SFC каже, що виправив файли, але моя проблема лишається?

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

4) Що насправді означає помилка DISM 0x800f081f?

DISM не може знайти потрібні payload-и. Це може бути тому, що Windows Update/WSUS недоступні, політика блокує доступ, або надане ISO/індекс не відповідають тому, що потрібно DISM.

5) Чи потрібен мені ISO щоразу?

Ні. Якщо Windows Update/WSUS працює і дозволений, DISM часто відновлює онлайн без локальних медіа. У закритих мережах наявність правильного ISO робить різницю між 10 хвилинами і нескінченним тикетом.

6) Чи можна запускати DISM і SFC на сервері під час робочого часу?

Зазвичай так, але ставте це як операцію технічного обслуговування. Це інтенсивно навантажує диск і CPU і може конкурувати з робочими навантаженнями. На критичних системах плануйте це або перевіряйте вплив у вікні обслуговування.

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

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

8) Чи слід використовувати /StartComponentCleanup для виправлення корупції?

Ні. Очищення не є механізмом ремонту. Виконуйте його після ремонтів і коли впевнені, що вам не потрібні компоненти для відкату. Надмірне використання очищення може ускладнити офлайн-відновлення.

9) Чому DISM використовує WinSxS і чому ця папка велика?

WinSxS підтримує сервісинг, компоненти side-by-side і відкат оновлень. Це не просто «сміття»; це частина механізму обслуговування Windows. Ви можете безпечно зменшувати її через очищення компонентів, але не видаляйте її як кеш, який можна просто стерти.

10) Коли припиняти ремонти і просто перемальовувати образ?

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

Наступні кроки, які ви справді можете зробити сьогодні

Практична операційна позиція: використовуйте DISM для ремонту сховища компонентів, а потім SFC для ремонту запущеної системи. Читайте вивід так, ніби він підказує вам, що робити далі — тому що саме так воно й є.

1. У вашому наступному тікеті «Windows поводиться дивно» запустіть DISM /CheckHealth і /ScanHealth перед тим, як починати перевстановлення додатків.
2. Якщо корупція ремонтоздатна — запустіть DISM /RestoreHealth. Якщо отримуєте 0x800f081f — зупиніться і надайте правильне джерело.
3. Запустіть sfc /scannow, перезавантажтеся і підтвердіть цілісність.
4. Якщо ті самі машини продовжують рецидивувати — перевірте стан диска і джерело оновлень. Повторювана корупція зазвичай сигналізує про системну причину, а не «поганий випадок».
5. Для команд: стандартизируйте ISO-джерела і мапінг індексів, і закріпіть порядок DISM-потім-SFC у своїх рукописах і скриптах.

Робіть у правильному порядку — і ви ремонтуватимете більше машин з меншими подвигами. Робіть у неправильному порядку — і ви багато дізнаєтеся про CBS-логи — переважно всупереч вашій волі.