Перетворіть ваш ПК на самовідновну машину: планові офлайн SFC/DISM

Що насправді означає «офлайн SFC/DISM» (і чому це працює)

SFC (System File Checker) перевіряє захищені системні файли й замінює невідповідні версії на відомі добрі копії. DISM (Deployment Image Servicing and Management) ремонтує компонентне сховище (WinSxS), від якого залежить SFC. Коли компонентне сховище пошкоджене, SFC не завжди може відновити файли, бо не знаходить чистих компонентів для підстановки.

Онлайн-ремонти виконуються під час завантаженої Windows. Це зручно, але це ніби операція на живому організмі, який постійно встає за кавою. Файли зайняті. Компоненти обслуговування активні. Драйвери завантажені. Фільтр-драйвер від вашого набору безпеки може «допомагати». Онлайн-ремонти іноді вдаються, але коли ні — ви застрягаєте в циклі часткових виправлень і повторної корупції.

Офлайн-ремонт означає, що ви завантажуєтеся в середовище відновлення Windows (WinRE) або окрему ОС для обслуговування, а потім вказуєте SFC і DISM на інсталяцію Windows на диску (так званий «офлайн-образ»). Цільова ОС не працює, тому файли не заблоковані, і стек обслуговування не заважає сам собі.

Це та сама операційна ідея, яку ми використовуємо в інженерії сховищ: ремонтуйте дані, коли вони в стані спокою. Скрубіть ZFS, коли система може це витримати. Перебудовуйте RAID, коли ви не одночасно навантажуєте систему. Windows нічим не відрізняється; просто прикидається інакше.

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

Жарт #1: Ремонти Windows схожі на чищення зубів ниткою: усі погоджуються, що це добре, і майже ніхто не робить цього, поки щось не заболить.

Факти та невелика історія: як ми дійшли до цього

• SFC існує з ери Windows 98/2000, еволюціонувавши від System File Protection до Windows Resource Protection (WRP) у сучасних версіях.
• DISM замінив старі інструменти образів (наприклад ImageX та частини старіших утиліт обслуговування) у міру переходу Windows до компонентного обслуговування.
• WinSxS — це не кеш, який «можна просто видалити»; це компонентне сховище, яке підтримує функції Windows, оновлення та ремонти.
• Журнали CBS (Component-Based Servicing) стали авторитетним записом багатьох операцій обслуговування; SFC записує в CBS.log.
• WinRE став загальноприйнятим завдяки OEM-розділам відновлення та автоматичним процедурам ремонту в Windows 8+.
• Оновлення стеку обслуговування (SSU) з’явилися, бо механізм, що встановлює оновлення, теж потребує оновлення — бутстрепінг складний.
• Офлайн-обслуговування — це як працює корпоративне створення образів: ІТ застосовує пакети до WIM-образів задовго до їх завантаження на кінцеві системи.
• Помилки Windows Update часто вказують на проблеми з компонентним сховищем; іноді «полагодити оновлення» можна, полагодивши сховище, а не сам апдейтер.
• Функції скидання/освіження по суті означають, що іноді «ремонт» занадто дорогий, тому перевстановлення на місці перемагає.

Ваша ментальна модель: WRP, WinSxS і чому ремонти не вдаються онлайн

WRP: швейцар у нічному клубі системних файлів

Windows Resource Protection контролює певні файли, папки та ключі реєстру. Суть у тому, що критичні компоненти ОС не повинні тихо замінюватися випадковими інсталяторами. Коли SFC знаходить невідповідність захищеного файлу, він намагається замінити його джерелом із відомих хороших копій.

WinSxS: компонентне сховище (не скриня для мотлоху)

WinSxS містить side-by-side збірки: кілька версій компонентів, маніфести та метадані, що дозволяють Windows обслуговувати себе. Оновлення не просто «перезаписують файли»; вони встановлюють компоненти й готують зміни. Саме тому папка велика й чому «прибирання» має правила.

Онлайн режими відмов, на які ви наступаєте знову і знову

• Заблоковані файли: DLL використовується; заміна відкладається; відкладена заміна не вдається; ви крутитеся вічно.
• Фільтр-драйвери: AV/EDR, агенти резервного копіювання, шари шифрування та файлові фільтри можуть заважати транзакціям обслуговування.
• Пошкодження компонентного сховища: SFC не може відновити, бо джерело пошкоджене; спочатку потрібно DISM.
• Невідповідність стека обслуговування: механізм, що встановлює/ремонтує пакети, застарів або частково пошкоджений.
• Проблеми з диском: «корупція» насправді I/O помилки, погані сектора або контролер, які дають збій.

Є перефразована ідея від Gene Kim, автора з надійності/операцій: надійність походить від малих, повторюваних практик, а не від героїчних нічних виправлень. Саме так: маленькі планові ремонти кращі за паніку час від часу.

Швидкий план діагностики: знайдіть вузьке місце швидко

У вас немає часу «пробувати щось». Потрібен швидкий шлях до ймовірної причини. Ось порядок, який я використовую, коли Windows пахне корупцією.

Спочатку: чи це насправді диск/ОЗП, що вдає з себе софт?

1. Перевірте журнали подій на наявність помилок диска і NTFS (Disk, StorAHCI, stornvme, Ntfs). Якщо бачите I/O помилки — припиніть рулетку SFC і спочатку займайтеся сховищем.
2. Перевірте SMART / стан NVMe. Якщо диск перерозподіляє сектори, троттлить або повідомляє про помилки медіа — ви не «лататимете Windows», а мінятимете диск і відновлюватимете.
3. Підтвердіть вільне місце. Обслуговуванню потрібен вільний простір. Мало місця призводить до дивних помилок DISM.

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

1. Запустіть DISM ScanHealth (онлайн, якщо можете завантажитись, офлайн — якщо ні). Це покаже, чи помічено пошкодження сховища.
2. Запустіть DISM RestoreHealth з контрольованим джерелом, якщо Windows Update ненадійний або заблокований.

По-третє: запустіть SFC проти офлайн-образу

1. Використовуйте офлайн SFC, вказуючи правильний каталог Windows. Якщо ви помилитеся з літерою диска, «полагодите» не те й відчуєте себе продуктивним.
2. Інтерпретуйте результат: «виправлено», «не вдалося виправити» або «порушень цілісності не виявлено». Кожен результат веде до іншого рішення.

По-четверте: якщо повторюється — зупиніться лікувати симптоми

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

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

Усі наведенi нижче команди передбачають, що ви в командному рядку WinRE або в адмінському шеллі Windows. Блоки коду показують реалістичний вивід; у вас він може відрізнятись. Головне — знати, що означає вивід і яке рішення приймати далі.

Завдання 1: Визначте літеру диска з офлайн Windows (WinRE чемно бреше)

cr0x@server:~$ wmic logicaldisk get deviceid, volumename, description
DeviceID  Description       VolumeName
C:        Local Fixed Disk
D:        Local Fixed Disk  Windows
E:        CD-ROM Disk       UDFS

Що це означає: У WinRE том Windows часто не C:. Тут це D:, бо WinRE змонтував диски інакше.

Рішення: Використовуйте D:\Windows для офлайн SFC/DISM. Не вгадуйте.

Завдання 2: Підтвердіть наявність каталогу Windows там, де ви думаєте

cr0x@server:~$ dir D:\Windows
 Volume in drive D has no label.
 Directory of D:\Windows

02/04/2026  10:02 AM    <DIR>          .
02/04/2026  10:02 AM    <DIR>          ..
02/04/2026  10:02 AM    <DIR>          System32
02/04/2026  10:02 AM    <DIR>          WinSxS
               0 File(s)              0 bytes

Що це означає: Ви маєте правильний том; WinSxS існує; можна рухатись далі.

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

Завдання 3: Швидка перевірка диска (метадані NTFS) за допомогою CHKDSK у режимі лише читання

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

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

Що це означає: У читальному скануванні NTFS явних структурних проблем не виявлено.

Рішення: Продовжуйте. Якщо виявлено помилки — спочатку виправте диск (/f офлайн), потім ремонтуйте Windows.

Завдання 4: Шукайте I/O помилки диска в журналах (сценарій онлайн-завантаження)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=7 or EventID=51 or EventID=55)]]" /c:5 /f:text
Event[0]:
  Log Name: System
  Source: Disk
  Event ID: 7
  Level: Error
  Description:
  The device, \Device\Harddisk0\DR0, has a bad block.

Що це означає: Це не «корупція Windows». Це відмова апаратного забезпечення сховища.

Рішення: Зупиніться. Резервне копіювання зараз. Замініть диск. Виконуйте ремонти Windows лише після стабілізації апаратної частини.

Завдання 5: Перевірте прапорці корупції компонентного сховища (онлайн)

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.

Що це означає: DISM не вважає сховище пошкодженим. Це швидка перевірка, не вичерпна.

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

Завдання 6: Глибоке сканування компонентного сховища (офлайн)

cr0x@server:~$ DISM /Image:D:\ /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.

Що це означає: DISM знайшов проблеми і вважає, що їх можна виправити.

Рішення: Запустіть /RestoreHealth. Краще використовувати відомий хороший джерело замість довіри Windows Update.

Завдання 7: Відновіть офлайн-компонентне сховище, використовуючи змонтований ISO як джерело

cr0x@server:~$ DISM /Image:D:\ /Cleanup-Image /RestoreHealth /Source:WIM:F:\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.

Що це означає: DISM відновив сховище за допомогою індексу 6 у WIM. Індекс має відповідати вашому виданню (Pro/Home/Enterprise) або бути сумісним.

Рішення: Тепер запустіть офлайн SFC. Якщо DISM видає «source files could not be found», виправте шлях/індекс джерела.

Завдання 8: Визначте правильний індекс WIM (не вгадуйте)

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

Index : 1
Name : Windows 11 Home
Index : 6
Name : Windows 11 Pro
The operation completed successfully.

Що це означає: Тепер ви знаєте, який індекс використовувати.

Рішення: Використовуйте індекс, що відповідає встановленому випуску. Якщо не впевнені — перевірте видання з офлайн-реєстру (наступне завдання).

Завдання 9: Визначте встановлене видання з офлайн-реєстру (точно і надійно)

cr0x@server:~$ reg load HKLM\OFFLINE D:\Windows\System32\Config\SOFTWARE
The operation completed successfully.

cr0x@server:~$ reg query "HKLM\OFFLINE\Microsoft\Windows NT\CurrentVersion" /v EditionID
HKEY_LOCAL_MACHINE\OFFLINE\Microsoft\Windows NT\CurrentVersion
    EditionID    REG_SZ    Professional

cr0x@server:~$ reg unload HKLM\OFFLINE
The operation completed successfully.

Що це означає: Офлайн-інсталяція — Professional, тож індекс WIM «Windows 11 Pro» підходить.

Рішення: Оберіть відповідний індекс WIM для DISM /Source.

Завдання 10: Запустіть SFC проти офлайн Windows (основна операція)

cr0x@server:~$ sfc /scannow /offbootdir=D:\ /offwindir=D:\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.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log

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

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

Завдання 11: Коли SFC не може виправити файли — витягніть дієві рядки з CBS.log

cr0x@server:~$ findstr /c:"[SR]" D:\Windows\Logs\CBS\CBS.log | more
2026-02-04 10:41:12, Info                  CSI    000000f1 [SR] Cannot repair member file [l:24{12}]"somefile.dll" of somecomponent, Version = 10.0.22631.1
2026-02-04 10:41:12, Info                  CSI    000000f2 [SR] Repairing corrupted file \??\D:\Windows\System32\otherfile.dll from store

Що це означає: Рядки «Cannot repair» вказують, що все ще зламано. Часто сховище все ще хворе або джерело невірне.

Рішення: Повторно запустіть DISM RestoreHealth з правильним джерелом. Якщо й далі не вдається — розгляньте in-place upgrade repair.

Завдання 12: Перевірте журнали DISM на помилки джерела та обслуговування

cr0x@server:~$ type D:\Windows\Logs\DISM\dism.log | findstr /i "error 0x800f081f 0x800f0906 source"
DISM   DISM Package Manager: PID=1124 TID=1420 Failed to resolve package source. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
DISM   DISM Package Manager: PID=1124 TID=1420 The source files could not be found; use the "Source" option to specify the location of the files. - GetCbsErrorMsg

Що це означає: Класична «відсутнє джерело». Windows Update не може його надати (або ви його заблокували), і ви не вказали відповідний WIM/ESD.

Рішення: Надайте правильне ISO/WIM джерело і знову запустіть RestoreHealth. Не продовжуйте безперервно повторювати одну й ту ж невдалу команду.

Завдання 13: Перевірте стан WinRE (щоб ви могли взагалі завантажитись у режим обслуговування)

cr0x@server:~$ reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Enabled
    Windows RE location:       \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 12345678-1234-1234-1234-123456789abc
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

Що це означає: WinRE увімкнено. Це добре; воно — ваш плацдарм для офлайн-ремонтів.

Рішення: Якщо вимкнено — увімкніть його перед тим, як покладатися на планові офлайн-ремонти.

Завдання 14: Увімкніть WinRE, якщо воно вимкнено

cr0x@server:~$ reagentc /enable
REAGENTC.EXE: Operation successful.

Що це означає: WinRE тепер увімкнено.

Рішення: Підтвердіть за допомогою reagentc /info. Без WinRE ваш «офлайн графік» перетворюється на «хай хтось буде за клавіатурою».

Завдання 15: Перевірте, чи безпечне очищення компонентного сховища (уникайте надмірного очищення)

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

Image Version: 10.0.22631.3007

Component Store (WinSxS) information:

Windows Explorer Reported Size of Component Store : 9.12 GB
Actual Size of Component Store : 8.95 GB
Shared with Windows : 6.40 GB
Backups and Disabled Features : 1.55 GB
Cache and Temporary Data : 1.00 GB

Component Store Cleanup Recommended : Yes

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

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

Завдання 16: Налаштуйте одноразовий завантаження у WinRE (ручний тригер)

cr0x@server:~$ reagentc /boottore
REAGENTC.EXE: Operation successful.

Що це означає: Наступне перезавантаження піде в WinRE автоматично.

Рішення: Використовуйте це, коли хочете виконати офлайн-сесію ремонту без випадкового натискання клавіш при завантаженні.

Планування офлайн-ремонтів: робочі підходи (і мій улюблений)

Звернімося до незручної частини: Планувальник Windows запускається всередині Windows. Офлайн-обслуговування виконується, коли Windows не працює. Це невідповідність. Тож «заплановані офлайн SFC/DISM» насправді означає запланований вхід у офлайн-середовище плюс автоматизовані дії з ремонту після того, як ви там.

Підхід A: Заплановані онлайн-ремонти (простішe, менш надійне)

Це базова опція: заплануйте sfc /scannow та dism /online /cleanup-image /restorehealth у вікні обслуговування. Це не офлайн, але все ще корисно — особливо на стабільному обладнанні з мінімальною кількістю сторонніх фільтр-драйверів.

Коли використовувати: Управління флотом, ноутбуки, які не можна вивести з роботи, або якщо доступ до WinRE обмежений.

Чого уникати: Запускати онлайн-ремонти під час інтенсивного I/O, встановлення патчів або коли йде шифрування/резервне копіювання.

Підхід B: «Запланувати» шляхом примусового наступного завантаження в WinRE, а потім запустити скрипт офлайн-ремонту (практично, мій вибір)

Ви можете запланувати завдання, яке викликає reagentc /boottore і потім перезавантажується у визначений час. Наступне завантаження відправить у WinRE. Далі потрібна автоматизація.

WinRE сам по собі не створено як повноцінна платформа для автоматизації, але його можна зробити робочим двома способами:

• Автоматизація за участю техніка: WinRE завантажився, ви запускаєте заздалегідь написаний скрипт з USB-накопичувача або з локального розділу. Це підходить для просунутих користувачів і малих середовищ.
• Налаштування OEM/ІТ: Деякі середовища налаштовують WinRE або використовують передзавантажувальну ОС (WinPE), яка автоматично запускає скрипти. Це поширено в корпоративних процесах образування, рідше — на споживчих ПК.

Якщо ви звичайна людина з типовим ПК, «напів-автоматична» версія зазвичай — оптимальний варіант: заплануйте перезавантаження в WinRE і тримайте під рукою скрипт. Це скорочує час ремонту від «читання гайдів о 2-й ночі» до «запустити скрипт, прочитати підсумок, повернутися в ліжко».

Підхід C: Двовстановлення з обслуговувальним розділом Windows/WinPE (найнадійніше, найскладніше)

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

Витрати: Місце на диску, складність і дисципліна. Якщо ви не тестуєте це щоквартально — воно згниє.

Як думати про розклад

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

• Щотижня: легкі перевірки (журнали подій, вільне місце, можливо SFC, якщо історія показує, що це допомагає).
• Щомісяця або після циклу патчів: DISM ScanHealth, і RestoreHealth тільки якщо помічено проблеми.
• Після інцидентів: офлайн DISM+SFC плюс перевірки апаратної частини.

Жарт #2: Планування ремонтів — це доросла версія «завтра розберусь», тільки цього разу «завтра» справді настає.

Три корпоративні міні-історії з практики

1) Інцидент через хибне припущення: «C: завжди Windows»

Середня компанія мала набір робочих станцій інженерів, які іноді не проходили Windows Update. Хтось написав «швидкий SOP»: завантажитись у recovery media, запустити sfc /scannow і dism /image:c:\, перезавантажитись і готово.

На першій машині це спрацювало. Навіть спрацювало двічі. Команда звикла і почала застосовувати це ширше, в тому числі на системах з BitLocker, кількома дисками і різними OEM-розмітками. На деяких WinRE призначало літери по-іншому. На декількох ОС була на D:, а C: був малим розділом відновлення або даних.

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

Виправлення було нудним: вони додали крок в SOP, який ідентифікує том Windows, перевіряючи наявність \Windows, опитуючи офлайн-реєстр про EditionID і логуючи обрану літеру диска. Вони також припинили писати SOP, що ставляться до літер дисків як до фізичних законів.

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

Інша організація мала тонкі SSD на польових ноутбуках. Тиск місця був постійним, тож хтось вирішив бути наперед: після кожного Patch Tuesday запускати очищення компонентного сховища з агресивними опціями. Здавалося розумно. Ноутбуки трималися нижче порогу «мало місця».

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

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

Вони відкоригували політику: забезпечили достатній обсяг диска через розмірування й контроль додатків, запускали /AnalyzeComponentStore спочатку і очищали тільки коли рекомендовано — і не на машинах, що покладаються на офлайн-джерела обслуговування.

3) Нудна, але правильна практика, яка врятувала ситуацію: відомі хороші джерела ремонту і логи

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

Коли хвиля збоїв оновлень сталася після зміни стека обслуговування, вони не панікували. Їхній план був простим: DISM ScanHealth, потім RestoreHealth з контрольованим /Source:WIM, потім офлайн SFC для найтяжчих випадків. Кожен прогін збирав журнали DISM і CBS у централізовану папку справи.

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

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

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

1) «SFC відремонтував файли, але корупція повертається через тиждень»

Симптом: Повторювані порушення цілісності; оновлення періодично не вдаються; випадкові крахи додатків.

Причина: Підкладна апаратна нестабільність (помилки медіа диска, погана ОЗП, нестабільний розгін) або сторонній фільтр-драйвер, що пошкоджує записи.

Виправлення: Перевірте події диска і SMART/NVMe; запустіть діагностику пам’яті; видаліть або оновіть підозрілі драйвери; припиніть розгін. Потім повторно виконайте офлайн DISM+SFC після стабілізації платформи.

2) «DISM каже, що файли джерела не знайдено (0x800f081f)»

Симптом: RestoreHealth не вдається; ScanHealth каже repairable; SFC не може відновити.

Причина: Неправильна збірка ISO, невірний індекс WIM, відсутні Features on Demand або Windows Update заблоковано без альтернативного джерела.

Виправлення: Використовуйте DISM /Get-WimInfo для знаходження правильного індексу; підтвердьте видання через офлайн-реєстр; надайте правильний /Source:WIM і використовуйте /LimitAccess, якщо потрібно.

3) «SFC не може відновити файли навіть після DISM»

Симптом: SFC завершується зі статусом «could not repair some files».

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

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

4) «Офлайн SFC каже, що порушень немає, але Windows все одно зламано»

Симптом: Додатки вилітають, проблеми з Пуском, збій оновлень, але SFC чистий.

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

Виправлення: Зосередьтесь на логах оновлень і стані AppX/пакетів; розгляньте скидання компонентів Windows Update; перевірте служби; перевірте цілісність профілів користувачів.

5) «Я запустив офлайн SFC, але воно таргетнуло не той розділ»

Симптом: Команди «успішні», але нічого не покращується; у CBS логах бракує очікуваних записів.

Причина: Невірна літера диска у WinRE або неправильні offbootdir/offwindir.

Виправлення: Явно визначте том Windows за допомогою wmic logicaldisk і dir X:\Windows; потім повторіть з правильими шляхами.

6) «DISM працює онлайн, але офлайн не вдається (або навпаки)»

Симптом: Непослідовні результати залежно від середовища.

Причина: BitLocker блокує том офлайн, у WinRE бракує драйверів, або відрізняються мережеві/джерельні налаштування.

Виправлення: Розблокуйте BitLocker у WinRE; забезпечте наявність драйверів сховища; використовуйте локальні ISO-джерела замість мережевих залежностей.

Контрольні списки / покроковий план

План A: Ви можете завантажити Windows (але вона поводиться дивно)

1. Зберіть докази спочатку: перевірте журнали подій на помилки диска/NTFS; підтвердіть вільне місце.
2. Запустіть DISM CheckHealth, потім ScanHealth: вирішіть, чи потрібен ремонт.
3. Якщо придатно — запустіть DISM RestoreHealth: віддавайте перевагу відомому хорошому ISO-джерелу, якщо ваше середовище блокує Windows Update.
4. Запустіть SFC онлайн: якщо він виправив файли — перезавантажтеся і протестуйте оновлення/додатки.
5. Якщо симптоми лишаються: заплануйте офлайн-сесію (План B) замість постійного повторення онлайн-ремонтів.

План B: Ви не можете надійно завантажити Windows (або хочете найбільш достовірний ремонт)

1. Завантажтесь у WinRE: вручну або через reagentc /boottore перед перезавантаженням.
2. Визначте том Windows: не припускайте літери дисків.
3. Запустіть chkdsk /scan: якщо виявлені помилки — виправте файлову систему спочатку.
4. Запустіть офлайн DISM ScanHealth: якщо repairable — переходьте до RestoreHealth.
5. Запустіть офлайн DISM RestoreHealth з ISO-джерелом: використовуйте правильний індекс WIM.
6. Запустіть офлайн SFC: перевірте цілісність і відновіть захищені файли.
7. Перезавантажтесь у нормальному режимі: перевірте встановлення оновлень і ключові додатки.
8. Витягніть і заархівуйте логи: CBS.log та dism.log — ваші чеки виконаних дій.

План C: Зробіть це «запланованим», не перетворюючи життя на наукову виставку

1. Визначте, що саме плануєте: щотижневі перевірки vs щомісячні ремонти vs офлайн-ремонт лише за інцидентом.
2. Заплануйте контрольоване вікно перезавантаження: поза робочим часом, з підключеним живленням для ноутбуків.
3. Триггер одноразового завантаження в WinRE: reagentc /boottore, потім перезавантаження.
4. Запустіть ваш скрипт офлайн-ремонту або дотримуйтесь чекліста: не імпровізуйте о 3-й ночі.
5. Після перезавантаження — валідуйте: встановлення оновлень, журнали подій і чи повертається корупція.

Операційні правила (що роблять дорослі)

• Тримайте відповідний ISO для вашої встановленої збірки/великої версії. «Достатньо близько» — це шлях до 0x800f081f.
• Не вважайте повторювану корупцію лише проблемою софту. Сховище й ОЗП мають слово голосу.
• Збирайте логи щоразу. Якщо ви не можете пояснити, чому сталося — ви не виправили проблему, вам пощастило.
• Міняйте одну змінну за раз. Ремонт плюс оновлення драйверів плюс правки реєстру — це не діагностика, це азартна гра.

Поширені питання

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

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

2) Що означає «The component store is repairable»?

DISM виявив корупцію і вважає, що може виправити її, якщо ви надасте дійсне джерело (Windows Update або локальний WIM/ESD). Це зелений сигнал для запуску RestoreHealth.

3) Чому офлайн SFC іноді вдається, коли онлайн SFC не вдається?

Офлайн уникaє блокувань файлів, запущених сервісів і впливу фільтр-драйверів на файлові операції. Це та сама операція ремонту з меншим числом рухомих частин.

4) Чи можна повністю автоматизувати офлайн SFC/DISM через Планувальник завдань?

Не безпосередньо, бо Планувальник працює всередині Windows. Ви можете запланувати перезавантаження в WinRE (reagentc /boottore) і запускати ремонти за допомогою передзавантажувального скрипта (WinPE/налаштування WinRE) або з участю техніка. Повністю без-ручного рішення зазвичай вимагає корпоративного передзавантажувального середовища.

5) Що робити, якщо DISM RestoreHealth не вдається навіть з джерелом?

Перевірте, чи збірка і індекс джерела співпадають, підтвердьте доступність шляху у вашому середовищі і прочитайте dism.log для точної помилки. Якщо і далі невдача — може знадобитися in-place repair upgrade або спочатку виправити проблеми з диском.

6) Чи безпечно запускати ці ремонти регулярно?

Час від часу перевірки — нормально. Постійні RestoreHealth — надмірність. Безпечний графік: спочатку перевірка, ремонтуйте лише коли помічено. Якщо ви ремонтуєте щотижня — скоріш за все маєте повторювану корінну причину.

7) Чи виправлять SFC/DISM помилки Windows Update?

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

8) Де знайти важливі логи?

Деталі SFC зберігаються в C:\Windows\Logs\CBS\CBS.log (або в офлайн-еквіваленті). Деталі DISM — в C:\Windows\Logs\DISM\dism.log. У WinRE підлаштуйте літеру диска відповідно.

9) У чому різниця між install.wim і install.esd?

Обидва можуть містити образи Windows; ESD зазвичай більш стиснений. DISM може використовувати будь-який з них як джерело, але синтаксис різниться (/Source:WIM: vs /Source:ESD:) і у вашому ISO може бути один із форматів.

10) Коли слід зупинитися і робити in-place repair upgrade?

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

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

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

1. Сформуйте базовий набір інструментів: майте під рукою відповідний ISO Windows; знайте, як знайти індекс WIM; підтвердіть, що WinRE увімкнено.
2. Впровадьте порядок операцій: перевірка диска → DISM (сховище) → SFC (файли) → логи → тільки тоді більш радикальні кроки.
3. Зробіть офлайн-ремонт простим для запуску: використовуйте reagentc /boottore для планового обслуговування і тримайте невеликий скрипт або чекліст для WinRE.
4. Слідкуйте за повтореннями: якщо корупція повертається — розглядайте це як проблему платформи, а не «настрій» Windows.
5. Записуйте, що сталося: зберігайте CBS.log і dism.log для кожного інциденту. Наступна відмова виглядатиме «новою», поки ви її не порівняєте з попередньою.

Робіть це, і ви витрачати менше часу на ремонт Windows і більше — на його використання. Саме в цьому суть володіння комп’ютером, а не утримування норовливої тваринки.