Windows не завантажується після оновлення: відновлення за 15 хвилин без перевстановлення

Ви відповідано запустили Windows Update. Потім машина перезавантажилася і… більше не повернулася. На екрані чорна пустка, крутиться круг, що міг би претендувати на сучасне мистецтво, або відтворюється втішне повідомлення «Підготовка автоматичного відновлення» до кінця всесвіту.

Є гарна новина: більшість помилок завантаження після оновлення можна відновити через Windows Recovery Environment (WinRE) менше ніж за 15 хвилин — без перевстановлення, без знищення даних і без жертвування вихідними. Погана новина: треба бути дисциплінованим. Випадкові кліки в «Startup Repair» — це не стратегія; це механізм подолання стресу.

Що фактично зламалося: типові підозрювані

Коли Windows не завантажується після оновлення, це рідко «Windows пошкодився» в абстрактному сенсі. Зазвичай це одна з кількох конкретних моделей відмов:

• Зсув конфігурації завантаження: неправильні записи BCD, відсутні EFI-файли завантаження, неправильний розділ позначено як завантажувальний або змінено порядок завантаження у прошивці.
• Стан сервісування / очікувані дії оновлення: напівзастосоване оновлення залишає компонентний магазин у «стані очікування», і ОС не може завершити завантаження.
• Регрес драйвера: оновлення драйвера зберігання або відео спричиняє збій на ранньому етапі завантаження або чорний екран.
• Пошкодження файлової системи: оновлення не «спричинило» проблему; воно просто вимагало достатньо записів, щоб виявити помираючий SSD, ненадійний кабель або нестабільний NVMe.
• Сюрприз BitLocker / TPM: зміни прошивки, зміни PCR або зміни шляху завантаження тригерять вимогу ключа відновлення; користувачі вгадують і зрештою заблоковують доступ.
• Несумісність UEFI і Legacy: хтось перемкнув CSM/Legacy, Secure Boot або перетворив диски, і прошивка не може знайти потрібний завантажувач.

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

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

Швидкість походить із відсутності здогадок. Найшвидші відновлення — це, по суті, дерево рішень.

Перший: чи бачить WinRE том ОС і чи він розблокований?

Якщо WinRE не бачить ваш розділ Windows (або він зашифрований BitLocker), нічого іншого не має значення. Ваше перше завдання — ідентифікувати букву тома Windows і розблокувати її за потреби.

Другий: це проблема завантажувача/BCD чи проблема сервісування ОС?

Збої завантажувача зазвичай показують помилки типу «0xc000000f», «Boot configuration data is missing», миттєві цикли перезавантаження або «No boot device». Проблеми сервісування зазвичай показують «Working on updates», «Undoing changes», повторювані Automatic Repair або зависання після логотипа Windows.

Третій: якщо це сервісування — відкотіть оновлення; якщо завантаження — відновіть файли завантаження

Відкат часто швидший за глибоке відновлення. Відновлення завантажувача швидке, якщо зробити це правильно для UEFI і не розкидатися bootrec /fixboot по проблемі, поки вона не відповість вам «Access is denied».

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

Ваш набір інструментів для відновлення (WinRE, режими завантаження, BitLocker)

WinRE — це невелика ОС відновлення, в яку ви завантажуєтесь, коли Windows не може стартувати. До нього можна дістатися:

• переключаючись живленням при появі логотипа Windows кілька разів (Windows зазвичай запропонує «Automatic Repair»).
• завантажившись з інсталяційного USB Windows і вибравши Repair your computer (бажано; менше несподіванок).

З WinRE вам потрібен шлях: Troubleshoot → Advanced options → Command Prompt. Саме там живуть реальні інструменти.

Про BitLocker: якщо том ОС зашифрований, WinRE може не отримати до нього доступу, поки ви не розблокуєте його ключем відновлення. Не застосовуйте грубу силу. «Безпека» у повнодисковому шифруванні — це не настрій; це математика.

Цитата, що тримає в тонусі: «Hope is not a strategy.» — Vince Lombardi. (Операційні люди зазвичай позичають цю фразу, бо вона тримає системи — і людей — від заперечення.)

Відновлення за 15 хвилин: практичні завдання з командами, виводом і рішеннями

Нижче наведені реальні завдання, які ви можете виконати в WinRE Command Prompt. Кожне завдання містить:

• команду(и)
• що означає типовий вивід
• яке рішення виконати далі

Припущення: ви у WinRE Command Prompt. Багато середовищ WinRE все ще надають класичні інструменти. Деякі команди знаходяться в X:\Windows\System32, бо WinRE працює з RAM-диска. Букви дисків можуть відрізнятися від звичного Windows.

Завдання 1: ідентифікуйте диски та томи (знайдіть Windows)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   Windows      NTFS   Partition    476 GB  Healthy
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     C   WinRE        NTFS   Partition    900 MB  Healthy    Hidden

DISKPART> exit

Що це означає: ваш том Windows, ймовірно, D: тут, а не C:. EFI System Partition — це FAT32 і позначений як «System».

Рішення: Запишіть букву диска Windows (тут D:) і EFI-розділ (тут Volume 1). Кожна наступна команда потребує правильних літер.

Завдання 2: підтвердіть наявність каталогу Windows (не гадати)

cr0x@server:~$ dir D:\Windows
 Volume in drive D is Windows
 Volume Serial Number is 1A2B-3C4D

 Directory of D:\Windows

08/01/2025  10:12 AM    <DIR>          System32
08/01/2025  10:12 AM    <DIR>          WinSxS
...
               0 File(s)              0 bytes
              22 Dir(s)  120,345,001,984 bytes free

Що це означає: це том ОС.

Рішення: Продовжуйте. Якщо D:\Windows не існує, ви вибрали неправильний том або файлову систему пошкоджено.

Завдання 3: якщо є BitLocker — перевірте статус

cr0x@server:~$ manage-bde -status D:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume D: [Windows]
    [OS Volume]

    Size:                 476.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection On
    Lock Status:          Locked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password

Що це означає: том ОС заблоковано; офлайн-сервісинг і перевірки файлів не спрацюють або покажуть неправильні результати.

Рішення: Розблокуйте його перед виконанням будь-яких інших дій.

Завдання 4: розблокуйте BitLocker-том (якщо заблоковано)

cr0x@server:~$ manage-bde -unlock D: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456
The password successfully unlocked volume D:.

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

Рішення: Повторно виконайте manage-bde -status D:, щоб підтвердити Lock Status: Unlocked. Потім продовжуйте.

Завдання 5: перевірка здоров’я файлової системи (швидке сканування спочатку)

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 ...
  610000 index entries processed.
Index verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

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

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

Завдання 6: якщо CHKDSK виявляє помилки — виправте їх (займе більше часу)

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

Stage 1: Examining basic file system structure ...
...
Windows has made corrections to the file system.
No further action is required.

Що це означає: метадані файлової системи були неконсистентні. Оновлення навантажують метадані. Так само роблять і відмовні диски. Обидва варіанти можливі.

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

Завдання 7: швидко подивіться журнали подій для останньої помилки завантаження

WinRE не дає вам акуратної панелі, але часто можна витягти підказки з лог-файлів. Один швидкий підхід — перевірити, чи Windows записала журнал налаштування/відкату сервісування.

cr0x@server:~$ dir D:\Windows\Logs\CBS
 Volume in drive D is Windows
 Directory of D:\Windows\Logs\CBS

08/01/2025  10:40 AM         2,134,220 CBS.log
08/01/2025  10:40 AM           129,554 CbsPersist_20250801_104000.cab

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

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

Завдання 8: спробуйте найшвидший відкат — видалення останнього якісного оновлення (офлайн)

У графічному інтерфейсі WinRE можна вибрати «Uninstall Updates». Але з командного рядка DISM робить це з більшим контролем.

cr0x@server:~$ dism /image:D:\ /get-packages /format:table
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Package Identity                             State      Release Type
-------------------------------------------  ---------  ------------
Package_for_RollupFix~31bf3856ad364e35~...   Installed  Update
Package_for_ServicingStack~31bf3856ad364e35~ Installed  Security Update
Package_for_KB503xxxx~31bf3856ad364e35~...   Installed  Update

Що це означає: ви бачите нещодавно встановлені пакети. Rollup fix зазвичай — це щомісячне кумулятивне оновлення.

Рішення: Видаліть найновіший кумулятивний пакет спочатку. Уникайте видалення Servicing Stack Updates, якщо немає вагомої причини; SSU — це механізм, який підтримує здатність Windows оновлюватися.

Завдання 9: видалити конкретний пакет оновлення (офлайн)

cr0x@server:~$ dism /image:D:\ /remove-package /packagename:Package_for_KB503xxxx~31bf3856ad364e35~amd64~~10.0.1.2
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

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

Що це означає: пакет видалено з офлайн-образу.

Рішення: Перезавантажте і перевірте. Якщо Windows завантажується, призупиніть оновлення і виправте базову проблему з драйвером/прошивкою перед повторним застосуванням.

Завдання 10: очистити «очікувані дії», якщо Windows застрягла в undo/redo оновленнях

Це класична проблема «напівзастосованого оновлення». Компонентний магазин чекає завершення роботи, якої не може виконати, бо завантаження ніколи не відбувається.

cr0x@server:~$ dism /image:D:\ /cleanup-image /revertpendingactions
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Reverting pending actions from the image...
[==========================100.0%==========================]
The operation completed successfully.
A reboot is required to complete the operation.

Що це означає: DISM очистив стан очікуваної транзакції.

Рішення: Перезавантажте негайно. Якщо завантажиться, ймовірно, у вас було частково застосоване оновлення.

Завдання 11: офлайн-перевірка системних файлів (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.

Що це означає: системні файли були пошкоджені та відновлені.

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

Завдання 12: офлайн-відновлення здоров’я DISM з локального компонентного сховища

cr0x@server:~$ dism /image:D:\ /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

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

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

Рішення: Перезавантажте. Якщо все одно не завантажується — переходьте до ремонту завантажувача/EFI.

Завдання 13: перевірте EFI System Partition (призначте букву)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System

DISKPART> select vol 1

Volume 1 is the selected volume.

DISKPART> assign letter=S

DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit

Що це означає: ваш EFI-розділ тепер має букву S:.

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

Завдання 14: правильно відновіть файли завантаження на UEFI за допомогою BCDBOOT

cr0x@server:~$ bcdboot D:\Windows /s S: /f UEFI
Boot files successfully created.

Що це означає: файли boot manager було (пере)скопійовано на EFI-розділ і створено записи BCD.

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

Завдання 15: обережно використовуйте BOOTREC (і знайте його обмеження)

bootrec — це старі навички м’язової пам’яті. На сучасних системах UEFI bcdboot часто є чистішим вирішенням. Проте ось як використовувати bootrec, коли це доречно.

cr0x@server:~$ bootrec /scanos
Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows

cr0x@server:~$ bootrec /rebuildbcd
Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows
Add installation to boot list? Yes(Y)/No(N)/All(A): y
The operation completed successfully.

Що це означає: інсталяція Windows знайдена і додана до BCD.

Рішення: Перезавантажте. Якщо /fixboot дає «Access is denied», не панікуйте; це звично для UEFI. Використайте bcdboot замість боротьби з правами.

Завдання 16: якщо підозрюєте пошкодження реєстру — відновіть із RegBack (тільки якщо існує)

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

cr0x@server:~$ dir D:\Windows\System32\Config\RegBack
 Directory of D:\Windows\System32\Config\RegBack

07/30/2025  03:12 AM        32,768,000 SYSTEM
07/30/2025  03:12 AM         6,291,456 SOFTWARE
07/30/2025  03:12 AM           262,144 SAM
07/30/2025  03:12 AM           262,144 SECURITY
07/30/2025  03:12 AM        12,582,912 DEFAULT

Що це означає: резервні копії існують і не нульового розміру.

Рішення: Спочатку зробіть резервні копії поточних вуликів, потім скопіюйте RegBack у Config.

cr0x@server:~$ mkdir D:\Windows\System32\Config\HiveBackup
cr0x@server:~$ copy D:\Windows\System32\Config\SYSTEM D:\Windows\System32\Config\HiveBackup\
        1 file(s) copied.
cr0x@server:~$ copy D:\Windows\System32\Config\SOFTWARE D:\Windows\System32\Config\HiveBackup\
        1 file(s) copied.
cr0x@server:~$ copy D:\Windows\System32\Config\RegBack\* D:\Windows\System32\Config\
        5 file(s) copied.

Що це означає: вулики реєстру відкотились до дати резервної копії.

Рішення: Перезавантажте. Якщо завантажиться, очікуйте, що деякі налаштування/драйвери теж відкотяться. Це плата за успіх.

Завдання 17: якщо підозрюєте, що завантажується неправильний розділ — перевірте розташування BCD

cr0x@server:~$ bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=S:
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Windows Boot Loader
-------------------
identifier              {default}
device                  partition=D:
path                    \Windows\system32\winload.efi
description             Windows 10

Що це означає: boot manager знаходиться на EFI-розділі S: і вказує на Windows на D:. Це узгоджено.

Рішення: Якщо device вказує на неправильний розділ, виправте, перезапустивши bcdboot з правильними буквами.

Завдання 18: якщо потрібно відключити проблемний драйвер (цілеспрямовано, не випадково)

Іноді оновлення підсовує фільтруючий драйвер зберігання або GPU-драйвер, який викликає паніку на ранньому етапі. Якщо ви можете ідентифікувати підозріного драйвера, ви можете відключити його тип запуску офлайн. Це — інструмент для досвідчених.

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

cr0x@server:~$ reg query HKLM\OFFLINE_SYSTEM\ControlSet001\Services /v Start
ERROR: The system was unable to find the specified registry key or value.

Що це означає: ви звернулися не за тією гілкою (Services — це ключ з багатьма підключами; він не має прямого значення Start).

Рішення: Запитуйте конкретний сервіс драйвера (ви повинні знати ім’я сервісу). Приклад нижче використовує умовну назву сервісу.

cr0x@server:~$ reg query HKLM\OFFLINE_SYSTEM\ControlSet001\Services\storflt /v Start
HKEY_LOCAL_MACHINE\OFFLINE_SYSTEM\ControlSet001\Services\storflt
    Start    REG_DWORD    0x0

cr0x@server:~$ reg add HKLM\OFFLINE_SYSTEM\ControlSet001\Services\storflt /v Start /t REG_DWORD /d 4 /f
The operation completed successfully.

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

Що це означає: тип запуску сервісу змінено на Disabled (4). 0 — автозавантаження на етапі boot — небезпечно, якщо це не те, що треба.

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

Жарт #1: «Automatic Repair» — це як нарада, яка могла бути листом — тільки вона потребує трьох перезавантажень і все одно нічого не пояснює.

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

Міні-історія 1: інцидент, спричинений неправильною припущенням

Середня компанія працювала на інженерних робочих станціях з зашифрованими NVMe дисками. Після Patch Tuesday кілька машин не завантажувалися. Служба підтримки припустила, що це «звична справа: оновлення Windows зламало щось», і почала конвеєр перевстановлення.

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

Вони спробували кілька «швидких фіксів»: перемикання Secure Boot, переключення з UEFI в Legacy, скидання TPM. Кожна зміна змінювала виміри завантаження й гарантувала, що запит BitLocker повертатиметься. Зрештою машина опинилася в стані, коли том ОС був цілий, але організація втратила чистий ланцюг завантаження, який був раніше.

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

Урок: сприймайте запити BitLocker як сигнал, а не як перешкоду. Якщо у вас немає налаштованого процесу ескроу ключів — зупиніться. Ескалюйте. Не «виправляйте» шифрування на око.

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

Команда IT прагнула швидших циклів патчів. Розумне бажання. Вони стандартизували налаштування BIOS і ввімкнули «fast boot» на парку ноутбуків, а також налаштування прошивки, яке агресивно пропускало ініціалізацію периферії. Оновлення запускалися вночі; машини перезавантажувалися, встановлювали оновлення і мали повернутися готовими вранці.

Після одного кумулятивного оновлення частина парку почала відмовляти при завантаженні. У WinRE можна було потрапити, але букви EFI-розділів були непослідовні, а іноді EFI-розділ взагалі не визначався, поки не зробили повторного перезавантаження. Скрипти автоматизації команди покладалися на стабільну нумерацію та фіксований порядок дисків/розділів.

Корінь проблеми був у штормі: поведінка прошивки fast-boot у поєднанні з деякими різними ревізіями контролерів SSD. Оновлення змінило таймінги раннього етапу завантаження настільки, що іноді EFI-розділ не встигав ініціалізуватись для менеджера завантаження. Тимчасовим вирішенням стало вимкнення агресивного fast-boot і виконання bcdboot на уражених машинах.

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

Урок: оптимізації, що змінюють таймінги завантаження, — це продакшн-зміни. Тестуйте їх на дивному обладнанні, а не лише на ідеальному.

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

Одна медична організація мала невелику, але зрілу команду endpoint-інженерії. Нічого гламурного: стандартні образи, кільця оновлень і — ось нудне, але важливе — послідовне ескроу ключів BitLocker і письмовий WinRE runbook. Ніхто не вихвалявся цим. Ніхто не отримав за це підвищення. Але воно було.

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

Перший крок: підтвердити букву тому ОС, розблокувати BitLocker за допомогою ескроу-ключів, виконати dism /revertpendingactions. Другий: у найгірших випадках офлайн видалити останній кумулятивний пакет оновлення. Третій: для машин, де тригером був драйвер, відключити конкретний сервіс фільтра зберігання офлайн через reg load та встановити Start=4. Потім перезавантажити і виправити драйвери вже зсередини Windows, коли система стабільна.

Більшість машин швидко повернулися в роботу. Аутлаєри були передані для апаратної діагностики, бо playbook чітко показав, коли проблема програмна. «Нудна практика» — це як резервні копії: всі її забувають, поки вона не стає єдиним «дорослим» в кімнаті.

Урок: Runbook-и — це як резервні копії: їх всі забувають, поки вони не стають єдиною опорою.

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

Тут більшість часу йде марно. Симптом реальний; інтерпретація зазвичай хибна.

1) Симптом: «Automatic Repair не зміг відновити ваш ПК»

• Корінна причина: Startup Repair у WinRE обмежений; він не прибирає очікувані оновлення, не виправить корупцію компонентного магазину і не відновлює UEFI-записи завантаження надійно.
• Виправлення: Використайте Command Prompt. Запустіть diskpart, щоб ідентифікувати Windows, потім dism /revertpendingactions і/або bcdboot залежно від сервісування або помилки завантаження.

2) Симптом: цикл «Undoing changes made to your computer»

• Корінна причина: очікувана транзакція оновлення не може завершитись, часто через корупцію, нестачу місця або перерваний перезавантаженням процес.
• Виправлення: dism /image:D:\ /cleanup-image /revertpendingactions. Якщо застрягає — видаліть останній кумулятивний пакет офлайн.

3) Симптом: чорний екран після логотипа, немає екрану входу

• Корінна причина: регрес GPU-драйвера, пошкоджені системні файли або проблема з оболонкою/Winlogon. Іноді це несумісний режим відображення після оновлення.
• Виправлення: Спробуйте Безпечний режим (якщо доступний). Якщо ні — офлайн sfc + dism /restorehealth. Якщо ідентифіковано оновлення драйвера — відключіть його сервіс офлайн або видаліть пакет оновлення.

4) Симптом: «No boot device found» або прямий перехід у прошивку

• Корінна причина: змінено порядок завантаження у прошивці, відсутній запис EFI, пошкоджений EFI-розділ або диск не визначається.
• Виправлення: Перевірте видимість диска в прошивці. У WinRE призначте букву EFI і виконайте bcdboot D:\Windows /s S: /f UEFI. Якщо диск нестабільно визначається — зупиніться і перевірте апаратне забезпечення.

5) Симптом: помилка 0xc000000f / відсутній BCD

• Корінна причина: BCD пошкоджено або відсутній, або вказує на неправильний розділ після змін.
• Виправлення: Віддавайте перевагу bcdboot для UEFI. Використайте bcdedit для перевірки, чи device вказує правильно.

6) Симптом: bootrec /fixboot повертає «Access is denied»

• Корінна причина: поведінка/права розділу UEFI; bootrec не є сучасним шляхом виправлення тут.
• Виправлення: Використайте bcdboot для відтворення файлів завантаження на EFI-розділі. Не повторюйте /fixboot, чекаючи дружності.

7) Симптом: DISM завершується з «The system cannot find the file specified»

• Корінна причина: неправильна буква диска Windows у WinRE або том зашифровано BitLocker.
• Виправлення: Повторно ідентифікуйте з diskpart, перевірте D:\Windows, розблокуйте BitLocker за потреби.

8) Симптом: CHKDSK знаходить багато помилок після оновлення

• Корінна причина: підлегла проблема диска або втрата живлення під час оновлення, а не лише «пошкодження оновлення Windows».
• Виправлення: Запустіть chkdsk /f, потім стежте за повторюваними помилками. Якщо з’являються погані сектори — першочергово робіть резервні копії даних і заміну апаратного забезпечення.

Жарт #2: Якщо ви «виправили» цикл завантаження, вимкнувши Secure Boot і переключившись на Legacy — вітаємо, ви винайшли нову проблему, яка також не завантажиться.

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

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

Чекліст A: план на 15 хвилин, щоби запустити систему

1. Потрапити в WinRE Command Prompt. Краще завантажуватися з інсталяційного USB Windows → Repair your computer.
2. Визначити букву тому Windows. Використайте diskpart → list vol, потім підтвердіть dir X:\Windows.
3. Спочатку розв’яжіть BitLocker. Якщо заблоковано — розблокуйте за допомогою manage-bde -unlock.
4. Швидка перевірка файлової системи. Запустіть chkdsk /scan на томі Windows.
5. Якщо бачили «Undoing changes» або цикл оновлень: виконайте dism /revertpendingactions.
6. Якщо бачите помилки boot/BCD: призначте букву EFI (DiskPart) і виконайте bcdboot D:\Windows /s S: /f UEFI.
7. Перезавантажте і перевірте. Якщо завантажується — увійдіть і не запускайте Windows Update одразу. Стабілізуйте систему спочатку.

Чекліст B: план «зробити, щоб залишалося фіксовано» (після першого успішного завантаження)

1. Тимчасово призупиніть оновлення. Дайте час перевірити стабільність і заблокувати проблемний драйвер/оновлення.
2. Перевірте історію оновлень і зміни драйверів. Ідентифікуйте, що встановилось перед збоєм.
3. Оновіть прошивку обережно. BIOS/UEFI і прошивка накопичувача можуть запобігти повторенню, але зміни мають контроль версій.
4. Підтвердіть ескроу BitLocker. Переконайтеся, що ключі відновлення збережені де очікує ваша організація.
5. Перевірте здоров’я диска. Якщо CHKDSK знайшов проблеми — виконайте подальші перевірки вендора і S.M.A.R.T. всередині Windows.
6. Перезавантажте двічі. Так, двічі. Багато «виправлених» машин падають на другому перезавантаженні, коли з’являються очікувані задачі.

Цікаві факти й історія (бо контекст допомагає)

Трохи історії робить моделі відмов менш випадковими і більш … інженерними.

1. Конфігурація завантаження змінила мету. У епоху Windows XP використовувався boot.ini; сучасний Windows використовує BCD (Boot Configuration Data), створений для гнучкості між типами прошивки.
2. UEFI змінив правила гри. З UEFI завантажувачі — це файли на FAT32 EFI System Partition, а не старий MBR-сценарій завантаження.
3. WinRE раніше був опціональним. Він став більш стандартизованим із розвитком розгортань Windows і очікуванням «відновлення без перевстановлення».
4. «Сервісування» — це окрема підсистема. DISM і журнали CBS існують, бо оновлення Windows — це транзакційна система управління пакетами, прилаштована до загальної ОС.
5. Щомісячні кумулятивні оновлення навмисно великі. Вони зменшують фрагментацію версій між машинами, але коли вони ламаються — ламаються голосно.
6. Servicing Stack Updates існують, бо оновити механізм оновлення складно. Windows має оновлювати засоби, що застосовують оновлення — інакше ви не зможете надійно правити логіку оновлень.
7. Запити BitLocker часто відображають зміни шляху завантаження. Ремонт завантажувача або перемикання прошивки може тригернути PCR-виміри і викликати recovery, навіть якщо дані на диску в порядку.
8. Букви дисків у WinRE нестабільні. WinRE призначає букви динамічно; припущення, що Windows завжди на C:, — причина помилок у скриптах і серед людей.
9. RegBack вже не такий, як раніше. Windows зменшила автоматичні резервні копії реєстру на багатьох системах; покладатися на RegBack як на універсальне рішення — застарілий підхід.

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

1) Чи справді потрібно використовувати Command Prompt? Хіба не можна просто запустити Startup Repair?

Можна спробувати Startup Repair один раз. Після цього — зупиніться. Коли він не вдається, зазвичай він повторює невдачу, бо не розглядає стан сервісування, офлайн-ремонт файлів або реконструкцію UEFI-записів так, як це потрібно.

2) Як зрозуміти, чи це проблема завантажувача, чи сервісування оновлень?

Проблеми завантажувача зазвичай дають явні помилки завантаження (BCD відсутній, no boot device, 0xc000000f) і відбуваються рано. Проблеми сервісування часто показують повідомлення про оновлення («Working on updates», «Undoing changes»), цикли Automatic Repair або зависання на/після логотипа.

3) У мене змінилася буква диска Windows у WinRE. Це нормально?

Так. WinRE — це окреме середовище і призначає букви на основі виявлених томів при завантаженні. Завжди підтверджуйте наявність каталогу \Windows.

4) Чи bcdboot кращий за bootrec?

На UEFI-системах — так, здебільшого. bcdboot копіює середовище завантаження з відомого каталогу Windows на EFI-розділ і створює записи. Це пряміше і зазвичай менш ризиковано.

5) Що робити, якщо dism /revertpendingactions спрацював, але оновлення знову намагаються встановитись і знову падають?

Тоді ви виправили симптоми, а не причину. Ідентифікуйте конкретне оновлення/драйвер, що спричинив помилку. Призупиніть оновлення, заблокуйте проблемне оновлення драйвера за потреби та оновіть прошивку/драйвери свідомо.

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

Тимчасово — так, ви відкочуєте патчі. Але незавантажувана машина не «безпечна»; це метал із документами з відповідності. Спочатку запустіть систему, потім оновіть правильно.

7) Якщо BitLocker запитує ключ, чи варто відключити BitLocker, щоб виправити завантаження?

Ні. Вимкнення BitLocker без плану може створити більше простоїв і ризиків. Розблокуйте за допомогою ключа відновлення, відремонтуйте стан завантаження/оновлення, а потім переконайтеся, що TPM і налаштування завантаження стабільні.

8) Чи можна все це зробити без втрати даних?

У більшості випадків — так. Підхід тут — ремонт на місці: відкат оновлень, виправлення файлів завантаження, ремонт системних файлів. Ризикові операції — ті, що виконуються сліпо: неправильний розділ, неправильна буква диска, випадкові перемикання прошивки.

9) Що робити, якщо DISM і SFC обидва успішні, але система все одно не завантажується?

Тоді ймовірно справа в драйверах/прошивці/апараті: контролер зберігання, особливості прошивки NVMe, відмова SSD або питання вибору запису/прошивки. Перевірте виявлення апаратури в прошивці і розгляньте діагностику від вендора.

10) Яка найпоширеніша причина, чому ці відновлення займають години?

Неправильні букви дисків і заблоковані томи BitLocker. Люди годину «ремонтують Windows» на розділі WinRE або заблокованому томі ОС — це як підмітати підлогу в кімнаті, де ви не стоїте.

Висновок: що робити наступного разу (щоб це залишалося проблемою на 15 хвилин)

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

• Підтвердіть ескроу ключів BitLocker. Протестуйте це на одній машині до того, як знадобиться о 2:00 ночі.
• Впровадьте кільця оновлень. Нехай невелика група приймає оновлення першою, особливо драйверні оновлення.
• Документуйте WinRE playbook. Відкриття букв дисків, розблокування BitLocker, DISM rollback, BCDBOOT ремонт. Тримайте коротким і виконувальним.
• Слідкуйте за станом накопичувачів. Оновлення не «вбивають» добрі диски; вони виявляють погані. Якщо CHKDSK знаходить помилки — заплануйте заміну.
• Перезавантажте двічі після ремонту. Одне перезавантаження доводить, що система стартує. Два — що вона продовжує стартувати.

Іноді перевстановлення Windows необхідне. Але рідко — першим кроком. Коли ви підходите до проблеми після оновлення як SRE — ідентифікуйте, підтвердіть, зробіть зворотну зміну, повторно протестуйте — ви зазвичай повертаєте собі ранок.