Застрягли на «Preparing Automatic Repair»? Відновлення, яке справді працює

Швидка інструкція для діагностики

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

Перше: з’ясуйте, чи це проблема зі станом диска

1. Якщо машина цокає, зависає в BIOS або інструменти WinRE зависають: спочатку підозрюйте відмову диска. Припиніть «ремонтувати». Почніть відновлення даних.
2. У WinRE Command Prompt, запустіть chkdsk на томі ОС (в офлайн-режимі). Якщо це займає вічність, повідомляє про погані сектори або «замінило пошкоджені кластери», — маєте справу з проблемами носія або серйозною корупцією.
3. Якщо SMART каже «Caution/Bad» (з зовнішньої ОС): ставте диск у статус ненадійного, навіть якщо Windows інколи ще запускається.

Друге: підтвердіть режим завантаження та ланцюг завантаження

1. У прошивці (BIOS/UEFI) перевірте, чи система завантажується в UEFI чи в Legacy/CSM режимі.
2. Якщо диск GPT, а прошивка встановлена в Legacy (або навпаки), ви можете отримати цикли «Automatic Repair» і дивні помилки «no boot device».
3. У WinRE перегляньте записи BCD та EFI System Partition (ESP). Якщо в ESP немає вільного місця або відсутні файли завантаження — ось ваш винуватець.

Третє: вирішіть — зберегти стан або відрізати втрати

1. Якщо цілісність диска в нормі: спробуйте відновлення завантаження (BCD/файли завантаження) та відкат (видалення оновлення, System Restore).
2. Якщо цілісність диска викликає сумніви: спочатку скопіюйте дані, потім ремонтуйте або перевстановлюйте систему.
3. Якщо BitLocker увімкнений і у вас немає ключа відновлення: ваші «опції ремонту» суттєво звужуються. Зосередьтеся на отриманні ключа.

Цитата, яку варто пам’ятати: «Надія — це не стратегія.» — перефразована ідея, що часто звучить в операціях і надійності систем.

Що насправді означає «Preparing Automatic Repair»

Windows намагається завантажитися, виявляє відмову й переходить у Windows Recovery Environment (WinRE), щоб спробувати виправити ситуацію. Фраза «Preparing Automatic Repair» — передмова. Цикл виникає, коли:

• WinRE не може виправити корінну причину (бо це не конфігурація, що легко «ремонтується»).
• сама спроба ремонту завершується невдало (наприклад: редагування BCD заблоковано, ESP не записується, помилки диска, том заблокований BitLocker).
• Windows завантажується достатньо, щоб впасти, а потім знову викликає ремонт (проблеми з драйвером, оновленням, файловою системою або реєстром).

Уявіть завантаження Windows як ланцюг із кількома ланками: прошивка → boot manager → BCD → loader → kernel → драйвери/служби. «Preparing Automatic Repair» — це те, що ви бачите, коли ланцюг порвався, але система ще має достатньо підпору, щоб спробувати відновлення. Якщо диск розвалюється, ланцюг ламається в різних місцях щоразу — через це симптоми непостійні. Якщо це чиста проблема конфігурації завантаження — вона відтворювана й виправна.

Жорстка констатація: Automatic Repair — ввічлива порада, а не гарантія.

Цікаві факти та історія, які вам знадобляться

• WinRE походить від Windows PE (Preinstallation Environment), створеного для уніфікованого відновлення та розгортання систем.
• Перехід від BIOS/MBR до UEFI/GPT змінив місце збереження файлів завантаження: з MBR/активного розділу на EFI System Partition (ESP) з FAT32.
• BCD замінив boot.ini починаючи з Windows Vista, давши гнучкішу конфігурацію завантаження — але й нові способи «творчо» зламати завантаження.
• Fast Startup (hiberboot) поєднує вимкнення та гібернацію; коли він дає збій, ви можете побачити «брудні» стани, що ускладнюють відновлення.
• NTFS — стійка, але не чарівна; вона журналює метадані, але може пошкодитися під час вимкнення живлення, проблем контролера або через відмову носія.
• EFI System Partition зазвичай маленька (зазвичай 100–300MB); вона може заповнитися інструментами виробника, кількома завантажувачами ОС або неакуратними оновленнями.
• BitLocker змінив правила гри для відновлення: офлайн-інструменти бачитимуть зашифрований том, поки ви не розблокуєте його ключем відновлення.
• SFC і DISM — це не одне й те саме: SFC ремонтує системні файли, використовуючи компонентне сховище; DISM ремонтує саме це сховище (або використовує вихідний образ).
• Помилки прошивки накопичувача трапляються: проблеми з прошивкою SSD викликали корупцію даних і цикли завантаження в різних поколіннях пристроїв.

Перш ніж щось робити: захистіть дані і зменшіть ризики

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

Вирішіть: що важливіше — дані чи швидкість?

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

Попереджувальні ознаки, що спочатку слід витягти дані

• Повторювані повідомлення «repairing disk», дуже повільні екрани завантаження або довгі паузи у WinRE.
• CHKDSK повідомляє про погані сектори, «replaced bad clusters» або працює годинами з інтенсивним ввід/виводом.
• Незвичні звуки диска (HDD), раптове зникнення диска в BIOS або його переривчасте визначення.
• Нещодавня раптова втрата живлення під час оновлень.

Жарт #1: Automatic Repair як зустріч, яка могла бути листом — багато активності, мало прогресу.

Набір інструментів для відновлення (WinRE, прошивка і зовнішня ОС)

WinRE: вбудований скальпель

WinRE дає вам Command Prompt, Startup Repair, System Restore, Safe Mode (через Startup Settings) і опції видалення оновлень. Для більшості проблем ланцюга завантаження та легких проблем з файловою системою цього достатньо.

Прошивка (UEFI/BIOS): джерело істини щодо режиму завантаження

Половина випадків «Automatic Repair loop», які я бачив, насправді є невідповідністю режиму завантаження після того, як хтось скинув налаштування прошивки або переключив CSM. Прошивка підкаже, чи має система взагалі правдоподібний шлях до завантажувача ОС.

Зовнішня ОС (Linux live USB або WinPE): обладнання для перевірки й витягання

Якщо диск недовірений або WinRE постійно відмовляє, завантажте зовнішню ОС, щоб:

• Перевірити SMART/стан диска без абстракцій Windows.
• Скопіювати дані на зовнішній диск.
• Оглянути розділи (ESP, MSR, OS, recovery) і перевірити, що на них дійсно знаходиться.

Мені подобається Linux live media для швидкої перевірки SMART і копіювання. Але WinPE зручніший для розблокування BitLocker і утиліт Windows. Використовуйте те, з чим можете працювати під стресом.

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

Ось реальні завдання, які можна виконати. Кожне містить: команду, приклад виводу, що це значить і що робити далі. Запускайте їх з WinRE Command Prompt, якщо не вказано інше. У WinRE літери дисків часто змінюються. Нічого не припускайте.

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

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *
  Disk 1    Online          931 GB      0 B

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WINRE        NTFS   Partition    900 MB  Healthy    Hidden
  Volume 1     C   OS           NTFS   Partition    475 GB  Healthy
  Volume 2          SYSTEM      FAT32  Partition    100 MB  Healthy    System
  Volume 3     E   Data         NTFS   Partition    931 GB  Healthy

Що це означає: У вас GPT диск (ймовірно UEFI). ESP — FAT32 і позначений як System. Том ОС тут — C:, але не припускайте, що так буде завжди.

Рішення: Зафіксуйте літеру тома ОС і номер тома ESP. Якщо на GPT-диску немає FAT32 «System» тому, ваші файли завантаження можуть відсутні або схема розділів ненормальна.

Завдання 2: Перевірити, чи том ОС зашифрований BitLocker

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

Volume C: [OS]
[OS Volume]

    Size:                 475.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

Що це означає: WinRE бачить том, але він заблокований. Багато ремонтових операцій (SFC/DISM/редагування реєстру) зазнають невдачі, поки ви не розблокуєте том.

Рішення: Якщо у вас є ключ відновлення — розблокуйте. Якщо ні — зупиніться і знайдіть його (Microsoft account, AD, Azure AD або корпоративний ескроу). Вгадування — не план.

Завдання 3: Розблокувати BitLocker-тому (якщо потрібно)

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

The password successfully unlocked volume C:.

Що це означає: Том ОС тепер доступний для читання/запису. Тепер ваші офлайн-ремонти дійсно працюватимуть з реальною файловою системою.

Рішення: Негайно подумайте про копіювання критичних даних, якщо ви підозрюєте проблеми з диском. Шифрування не захищає від апаратної відмови.

Завдання 4: Прочитати лог Startup Repair, щоб дізнатися, що воно намагалося

cr0x@server:~$ type C:\Windows\System32\LogFiles\Srt\SrtTrail.txt
Startup Repair diagnosis and repair log
---------------------------------------
Number of repair attempts: 1

Session details
---------------------------
System Disk = \Device\Harddisk0
Windows directory = C:\Windows
AutoChk Run = 0
Number of root causes = 1

Test Performed:
---------------------------
Name: Check for updates
Result: Completed successfully. Error code = 0x0

Root cause found:
---------------------------
Boot critical file c:\windows\system32\drivers\disk.sys is corrupt.
Repair action: File repair
Result: Failed. Error code = 0x57
Time taken = 120 ms

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

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

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

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

Stage 1: Examining basic file system structure ...
File verification completed.
Stage 2: Examining file name linkage ...
An unspecified error occurred (696e647863686b2e 12f1).

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

Рішення: Якщо CHKDSK не може завершити роботу — припиніть виконувати більш інтенсивні операції запису. Завантажтеся з зовнішніх носіїв, скопіюйте дані та перевірте стан диска. Якщо мусите йти далі, chkdsk /r має сенс лише якщо ви приймаєте довгий час виконання і додаткове навантаження на, можливо, дефектний диск.

Завдання 6: Якщо CHKDSK виконався, інтерпретуйте рядок про «погані сектора» по-дорослому

cr0x@server:~$ chkdsk C: /f /r
The type of the file system is NTFS.
Stage 4: Looking for bad clusters in user file data ...
Windows replaced bad clusters in file 12345 of name \Windows\System32\config\SYSTEM.
...
Windows has made corrections to the file system.
  4096 KB in bad sectors.

Що це означає: Диск повернув непрочитані сектори, і Windows перемапувала/відновила те, що могла. Навіть якщо система тепер завантажується — диск ненадійний.

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

Завдання 7: Перевірити файли Windows за допомогою офлайн SFC

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

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

Windows Resource Protection found corrupt files and successfully repaired them.

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

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

Завдання 8: Відновити компонентне сховище за допомогою DISM (офлайн)

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

Image Version: 10.0.19045.3693

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

Що це означає: Стан образу Windows відновлено; тепер SFC має більше шансів на успішну роботу.

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

Завдання 9: DISM із відомим гарним джерелом з інсталяційного носія

cr0x@server:~$ dism /image:C:\ /cleanup-image /restorehealth /source:WIM:D:\sources\install.wim:1 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

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

Що це означає: DISM використав образ інсталяційного носія як джерело ремонту замість звернення до Windows Update (який у WinRE недоступний).

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

Завдання 10: Перевірити записи завантаження (BCD), щоб зрозуміти, що Windows собі «думає»

cr0x@server:~$ bcdedit /enum
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US

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

Що це означає: Boot Manager вказує на EFI-файл в ESP, а завантажувач вказує на C:. Це адекватна UEFI розкладка.

Рішення: Якщо device вказує на неправильний розділ або winload.efi відсутній — ви у зоні відновлення завантаження (потрібне відновлення ESP, реконструкція BCD).

Завдання 11: Відтворити файли завантаження на UEFI системах за допомогою bcdboot (зазвичай правильне рішення)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.19041.1

DISKPART> sel vol 2

Volume 2 is the selected volume.

DISKPART> assign letter=S

DiskPart successfully assigned the drive letter or mount point.

DISKPART> exit
Leaving DiskPart...

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

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

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

Завдання 12: Системи з MBR/Legacy: ремонт за допомогою bootrec (використовуйте лише для справжніх legacy)

cr0x@server:~$ bootrec /fixmbr
The operation completed successfully.

cr0x@server:~$ bootrec /fixboot
Access is denied.

cr0x@server:~$ bootrec /scanos
Total identified Windows installations: 1
[1]  C:\Windows

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

Що це означає: /fixmbr і /rebuildbcd спрацювали, але /fixboot отримав «Access is denied» — поширена прикрість у WinRE.

Рішення: Якщо ви насправді в UEFI, не варто продовжувати трясти bootrec як універсальний засіб. Використайте bcdboot і працюйте з ESP. Якщо ви в legacy і /fixboot не працює, інколи допомагає встановити System Reserved як активний і переконатися в правильному форматі; але часто легше запустити bcdboot C:\Windows /s X: на правильний системний розділ.

Завдання 13: Знайти правильну директорію Windows, коли літери дисків перемішані

cr0x@server:~$ dir C:\Windows
 Volume in drive C is OS
 Volume Serial Number is 8A1B-2C3D

 Directory of C:\Windows

06/01/2025  10:22 AM    <DIR>          System32
06/01/2025  10:22 AM    <DIR>          WinSxS
...

Що це означає: Схоже на реальну директорію Windows. У WinRE іноді Windows знаходиться на D: або E:.

Рішення: Завжди перевіряйте шлях перед запуском SFC/DISM/bcdboot. «Я відремонтував неправильний том» трапляється частіше, ніж думають.

Завдання 14: Спробувати Safe Mode через BCD (коли нормальне завантаження падає рано)

cr0x@server:~$ bcdedit /set {default} safeboot minimal
The operation completed successfully.

Що це означає: Наступна спроба завантаження буде в Safe Mode (мінімум драйверів). Це корисно, якщо третя сторона драйвера або служба вбиває завантаження.

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

cr0x@server:~$ bcdedit /deletevalue {default} safeboot
The operation completed successfully.

Завдання 15: Визначити нещодавні оновлення Windows (офлайн) і видалити підозріле

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

Package Identity                                             State      Release Type
-----------------------------------------------------------  ---------  ------------
Package_for_KB5030211~31bf3856ad364e35~amd64~~19041.3324.1.0 Installed  Update
Package_for_KB5031356~31bf3856ad364e35~amd64~~19041.3448.1.0 Installed  Security Update

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

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

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

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

Якщо видалення не вдається через відкладені дії, можливо треба очистити pending operations (наступне завдання).

Завдання 16: Очистити «pending» дії, які постійно відновлюють зламане оновлення

cr0x@server:~$ dism /image:C:\ /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.

Що це означає: У Windows були відкладені кроки обслуговування, які можуть кожного разу ламати завантаження. Повернення цих дій може відновити консистентний стан.

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

Завдання 17: Перевірити і встановити правильний firmware boot entry (поширено після «ремонтів»)

cr0x@server:~$ bcdedit /enum firmware
Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {a1b2c3d4-e5f6-7890-abcd-ef0123456789}
timeout                 2

Firmware Application (101fffff)
-------------------------------
identifier              {bootmgr}
description             Windows Boot Manager

Що це означає: Прошивка знає про «Windows Boot Manager». Якщо запис відсутній, порядок завантаження може вказувати кудись іще (PXE, інший диск, старий запис).

Рішення: Якщо запис прошивки відсутній або невірний — виправте в BIOS/UEFI: оберіть правильний «Windows Boot Manager», прив’язаний до потрібного диска. Програмні ремонти не завжди надійно виправляють дивності прошивки від виробника.

Завдання 18: Скопіювати дані з WinRE (коли ОС не завантажується, але диск читається)

cr0x@server:~$ robocopy C:\Users\alice\Desktop E:\Rescue\Desktop /E /R:1 /W:1 /XJ
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : Tuesday, February 4, 2026 10:42:11
   Source : C:\Users\alice\Desktop\
     Dest : E:\Rescue\Desktop\

    Files : *.*

  Options : *.* /E /R:1 /W:1 /XJ

------------------------------------------------------------------------------

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :        42        42         0         0         0         0
   Files :       380       380         0         0         0         0
   Bytes :   1.82 g   1.82 g         0         0         0         0
   Times :   0:02:11   0:02:11                       0:00:00   0:00:00

   Speed :            14.2 MBytes/sec.
   Ended : Tuesday, February 4, 2026 10:44:22

Що це означає: Дані скопійовано успішно. /XJ уникає петель через junction; /R:1 /W:1 не витрачає ваш час на марні повтори.

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

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

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

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мала парк ноутбуків для розробників. Одного ранку декілька пристроїв почали зациклюватися на «Preparing Automatic Repair» після оновлення прошивки, яке роздали інструментом управління від виробника. Внутрішній IT-канал загудів звичними повідомленнями: «Знову Windows зламався після оновлення».

Перший респондент зробив те, що більшість роблять під тиском: виконав bootrec /fixmbr і bootrec /fixboot на багатьох машинах. Деякі стали гірші — тепер вони інколи взагалі не могли знайти пристрій завантаження. Тоді спливло припущення: думали, що всі ноутбуки — legacy BIOS/MBR, бо «колись так було».

Насправді пристрої були UEFI/GPT з маленьким ESP. Оновлення прошивки скинули деякі машини в Legacy/CSM режим. Windows була цілком в порядку; прошивка просто перестала завантажувати UEFI запис. Startup Repair не міг виправити перемикач прошивки, тому цикл повторювався.

Рішення було нудним: встановити в прошивці режим UEFI, перевірити, щоб «Windows Boot Manager» був першим у порядку завантаження, а в кількох випадках відновити файли завантаження за допомогою bcdboot, тому що попередні спроби bootrec заплутали ситуацію. Після цього парк стабілізувався.

Урок: Не починайте з «ремонту Windows», коли проблема — у реальності прошивки. Рано підтверджуйте режим завантаження та схему розділів.

Міні-історія 2: Оптимізація, яка зіграла злий жарт

Команда з образів спробувала зробити ноутбуки «швидшими при завантаженні» і «чистішими при патчінгу». Вони увімкнули Fast Startup на широкій базі, налаштували живлення і стандартизували політики шифрування дисків. Пілот виглядав добре.

Потім невелика хвиля машин почала потрапляти в цикл після Patch Tuesday, особливо ті, що часто гасилися жорстко (консультанти, у дорозі, з низьким зарядом). Схема була неприємна: прапори «NTFS dirty», іноді BitLocker-промпти і WinRE, що не міг узгодити стан.

Оптимізація не була злом; вона просто підсилювала крайові випадки. Fast Startup може зберігати гібридний стан, який чутливіший до різкого відключення живлення. У поєднанні з шифруванням і агресивним патчінгом шлях відновлення звузився. Startup Repair мав справу з напігібернаційною системою, відкладеними діями обслуговування і інколи заблокованими томами.

Ремедіація не була «вимкнути все». Воно було цілеспрямованим: для постраждалої когорти відключити Fast Startup, поліпшити таймінги встановлення оновлень (не робити критичні патчі перед поїздками), і впровадити практику «закінчити оновлення, потім перезавантажитися повністю». Також покращили доступ до WinRE і забезпечили ескроу ключів відновлення.

Урок: Налаштування продуктивності можуть стати налаштуваннями надійності. Коли вони дають збій — не оголошують про це ввічливо.

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

Фінансовий відділ мав пару десятків десктопів з профільним ПЗ. Це були нудні машини, якими керували консервативно. IT-лід наполягав на двох практиках: (1) щотижневі протестовані бекапи профілів користувачів на мережевий шар, і (2) задокументований чек-лист відновлення завантаження, приклеєний усередині шафи серверної.

Одного ранку контролер сховища дав збій під час події з живленням і пошкодив кілька томів завантаження. Декілька ПК потрапили в «Preparing Automatic Repair» одночасно. Паніка була б природною; закривалися звіти за місяць.

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

Це не було героїчно. Це була процедура. Бекапи означали, що ніхто не вів переговори з помираючим диском за єдину копію таблиці.

Урок: Нудні практики — протестовані бекапи і робочі інструкції — перетворюють «катастрофу» на «неприємну вівторок».

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

План A: Хочете знову завантажитися, не погіршивши ситуацію

1. Увійдіть у WinRE (перервіть завантаження 3 рази або завантажтеся з інсталяційного носія → Repair your computer).
2. Зафіксуйте базове: режим завантаження (UEFI/Legacy), тип диска (GPT/MBR), буква тома ОС у WinRE.
3. Перевірте стан BitLocker за допомогою manage-bde -status. Розблокуйте за потреби.
4. Прочитайте SrtTrail.txt. Якщо там названо пошкоджений або відсутній файл завантаження — розглядайте це як підказку, а не як догму.
5. Запустіть CHKDSK (/f першочергово). Якщо з’являться погані сектора — перемкніться на пріоритет витягнення даних.
6. Запустіть DISM, потім SFC в офлайн-режимі, якщо підозрюється корупція.
7. Виправте файли завантаження найменш руйнівним способом:
   • UEFI/GPT: змонтуйте ESP і виконайте bcdboot C:\Windows /s S: /f UEFI.
   • Legacy/MBR: розгляньте bootrec і перевірте, що системний розділ активний.
8. Перезавантажтеся. Якщо система завантажилася — негайно стабілізуйте: перевірте стан диска у Windows, налаштуйте бекапи і уникайте несподіваних перезавантажень під час оновлень.

План B: Підозрюєте, що диск відмовляє (дійте як при відмові)

1. Припиніть інтенсивні операції запису (безкінечні цикли CHKDSK /r не є добрим рішенням).
2. Завантажтеся з зовнішніх носіїв (WinPE або Linux live).
3. Перевірте стан диска (SMART) і підтвердіть, чи диск випадково відключається.
4. Спочатку скопіюйте критичні дані (профілі, репозиторії, документи). Використовуйте інструменти, що вміють продовжувати при помилках.
5. Замініть диск, потім перевстановіть або відновіть образ. Якщо треба зберегти ОС — відновлюйте з образу, а не «ремонтуйте» хворий диск.

План C: Ймовірно, погане оновлення або драйвер

1. Спробуйте Safe Mode (через Startup Settings або встановіть safeboot у BCD).
2. Видаліть останнє оновлення через інтерфейс WinRE або DISM офлайн.
3. Поверніть відкладені дії, якщо обслуговування застрягло.
4. Відключіть проблемні драйвери сторонніх розробників (антивірус, фільтри сховища) лише якщо маєте план відкату.
5. Перезавантажтеся і перевірте. Після стабілізації оновлюйте драйвери цілеспрямовано, а не всі одразу.

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

1) Симптом: CHKDSK працює вічно, система стає повільнішою при кожному завантаженні

Корінна причина: Відмова диска (погані сектори) або проблеми контролера, що спричиняють повтори.

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

2) Симптом: «Access is denied» на bootrec /fixboot

Корінна причина: Часто UEFI/GPT системи, де bootrec не підходить, або ESP/системний розділ недоступний.

Виправлення: Використайте diskpart для монтування ESP і запустіть bcdboot. Переконайтеся, що прошивка встановлена в UEFI і порядок завантаження правильний.

3) Симптом: Startup Repair каже, що «не вдалося відновити ПК» з невизначеними помилками

Корінна причина: Startup Repair обмежений; він не може виправити апаратні проблеми диска, невідповідність режиму прошивки або складні збої обслуговування.

Виправлення: Прочитайте SrtTrail.txt, потім оберіть маршрут: перевірка цілісності диска (CHKDSK/SMART) або маршрут ланцюга завантаження (bcdboot/інспекція BCD) або обслуговування (DISM/SFC/revert pending).

4) Симптом: DISM/SFC падають з «Windows Resource Protection could not perform the requested operation»

Корінна причина: Неправильні літери дисків, офлайн-образ недоступний або том заблокований BitLocker.

Виправлення: Перевірте шлях Windows за допомогою dir. Стан BitLocker — розблокуйте. Використайте правильні параметри /image і /offwindir.

5) Симптом: Після «ремонту» з’являється «No boot device found»

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

Виправлення: Відключіть зовнішні диски. У прошивці виберіть правильний запис Windows Boot Manager. Повторно запустіть bcdboot, націливши на ESP диска ОС.

6) Симптом: Система завантажується раз, а потім повертається до циклу після оновлень

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

Виправлення: Використайте dism /revertpendingactions, видаліть останнє оновлення і перевірте диск. Якщо вдається завантажитися в Safe Mode, але не в нормальному режимі — підозрюйте драйвер/службу.

7) Симптом: WinRE бачить диск, але не може отримати доступ до файлів (виглядає порожнім або просить форматування)

Корінна причина: BitLocker без розблокування або серйозна корупція файлової системи.

Виправлення: Перевірте manage-bde. Якщо не BitLocker — припиніть записи і перейдіть до інструментів відновлення; розгляньте створення образу диска спочатку.

8) Симптом: «Preparing Automatic Repair» з’явився після зміни налаштувань BIOS

Корінна причина: Перемикання режиму завантаження (UEFI ↔ Legacy), зміни Secure Boot або скидання порядку завантаження.

Виправлення: Відновіть правильний режим завантаження і порядок. За потреби відтворіть файли завантаження за допомогою bcdboot для відповідного режиму.

FAQ

1) Чи завжди «Preparing Automatic Repair» — це проблема Windows?

Ні. Це може бути налаштування прошивки, апаратна проблема диска, поведінка контролера сховища або навіть проблема з живленням. Windows — лише місце, де проявляється симптом.

2) Яка найбільш ефективна командна рядкова команда для UEFI-проблем завантаження?

bcdboot для відбудови файлів завантаження на EFI System Partition — після того, як ви правильно ідентифікували та змонтували ESP. Це чистіше, ніж хаотичні правки BCD.

3) Чи варто одразу запускати chkdsk /r?

Не варто, якщо ви не приймаєте пов’язані компроміси. /r повільний і багато записує; на відмовному диску це може прискорити смерть. Почніть з /f для оцінки. Якщо бачите погані сектора — пріоритетуйте копіювання даних.

4) Чому WinRE показує мій диск Windows як D: або E:?

Літери дисків у WinRE призначаються динамічно. Середовище відновлення — це інша ОС-контекст. Завжди перевіряйте за допомогою diskpart і dir перед виконанням ремонтів.

5) Якщо я відтворю BCD, чи втрачу я дані?

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

6) Що робити, якщо BitLocker увімкнений, а ключа відновлення немає?

Варіантів мало. Ви можете не мати доступу до файлів або можливості ремонту. Ваше завдання — відшукати ключ відновлення там, де його зберігали (Microsoft account, AD або управління пристроями організації).

7) Чи може лише оновлення Windows викликати цей цикл?

Так. Оновлення можуть залишити відкладені дії, замінити критичні файли завантаження або викликати проблеми з драйверами. Але «оновлення все зламало» — зручна історія, яка іноді приховує вже існуючі проблеми з диском.

8) Коли варто припинити розслідування і перевстановити Windows?

Коли стан диска сумнівний, коли базові системні файли постійно коруптуються, або коли ви вже витратили більше часу, ніж машина того варта. Перевстановлення — не поразка, а контрольоване відновлення. Лише спочатку витягніть дані.

9) Чи може Secure Boot викликати цикли «Preparing Automatic Repair»?

Secure Boot може бути причетний, якщо завантажувачі не узгоджені або змінено ключі, але це менш поширено, ніж проблеми з порядком/режимом завантаження. Змінюйте налаштування Secure Boot лише якщо розумієте наслідки для вашого середовища.

10) Чому Startup Repair не може виправити навіть очевидну проблему?

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

Висновок: наступні кроки, щоб не потрапити в цей цикл знову

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

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

• Після відновлення завантаження: запустіть повну перевірку стану диска, перевірте бекапи і зафіксуйте, чи система UEFI/GPT з ESP, який ви можете змонтувати.
• Якщо CHKDSK повідомляв про погані сектори: заплануйте заміну диска. Не чекайте, поки наступний цикл стане постійним.
• Якщо причиною був скидання прошивки або порядок завантаження: задокументуйте правильні налаштування і в корпоративному середовищі контролюйте оновлення прошивки так само, як ви контролюєте зміни в продакшені.
• Якщо причиною було оновлення/драйвер: покращуйте дисципліну розгортання — поетапні оновлення, відомі робочі базові драйвери і доступні ключі відновлення, коли ноутбук перетворюється на дорогий цеглину.

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