Приховане меню інструментів WinRE: що можна виправити з середовища відновлення

Що WinRE насправді таке (і чому воно працює, коли Windows не працює)

WinRE — це мінімальне виконуване середовище Windows, призначене для відновлення. Думайте: «Windows, але з меншими претензіями». Воно завантажується з образу відновлення (зазвичай winre.wim) і дає підбірку інструментів: Startup Repair, System Restore, Uninstall Updates, System Image Recovery, Reset this PC і — найважливіше — Command Prompt.

Практична причина його корисності: WinRE працює поза встановленим томом Windows. Це означає, що ваша офлайн‑Windows не блокує власні файли, драйвери не завантажуються з поламаної інсталяції, а сервіси, що застрягли в циклі, не працюють. У термінах зберігання: ви виконуєте обслуговування файлової системи, коли вона не змонтована (або принаймні не активна як ОС). Ви отримуєте чистіші ремонти й менше хибних «файл використовується» повідомлень.

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

1. Чи це проблема ланцюжка завантаження (UEFI/EFI/BCD), проблема інтегритету ОС (системні файли/компонентне сховище) або проблема диска (I/O помилки, погані блоки, відмова SSD/NVMe)?
2. Чи дані доступні й розшифровуються (BitLocker), щоб ви могли їх скопіювати перед тим, як щось чіпати?
3. Чи можна відремонтувати на місці, чи це вже ситуація з перевстановленням і відновленням?

Парафразована ідея, приписана: Системи успішні, коли ви проектуєте під відмови й практикуєте відновлення, а не коли вважаєте, що нічого не поламається. — Werner Vogels (парафразована ідея)

Як потрапити в WinRE без гадань

З працюючої Windows (найкращий випадок)

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

cr0x@server:~$ shutdown /r /o /t 0
...rebooting into Advanced Startup...

Рішення: Якщо ви можете потрапити в WinRE таким способом, ймовірно це проблема псевдовиконання (драйвер/оновлення/програма), а не ланцюжок завантаження. Використайте «Uninstall Updates», «Startup Settings» і «System Restore» перед тим, як переписувати розділи.

З не завантажуваної системи (реальне життя)

На більшості інсталяцій Windows 10/11 три послідовні перервані завантаження спричиняють Automatic Repair, що може привести у WinRE. Якщо це не вдається або ви в циклі, завантажтеся з інсталяційного носія Windows (USB), потім оберіть «Repair your computer» замість «Install».

Для операторів парків: тримайте стандартизований USB для відновлення з потрібною збіркою Windows і драйверами для зберігання/мережі. Якщо ви покладаєтеся на «якийсь ISO, який хтось скачав торік», ви проводите інцидент‑реакцію з простроченим обладнанням.

Коли Secure Boot, TPM або BitLocker ускладнюють вхід

WinRE може завантажуватися нормально під Secure Boot. Проблеми зазвичай виникають, коли ви намагаєтесь отримати офлайн‑доступ до зашифрованих томів. Якщо BitLocker увімкнено, багато дій (SFC, DISM, копіювання журналів) вимагають спочатку розблокувати ОС‑том. WinRE не буде ввічливо нагадувати; воно просто поверне помилки доступу й дасть вам привід звинувачувати всесвіт.

Швидка діагностика: перші/другі/треті перевірки

Це швидка послідовність триажу, яку я використовую, коли Windows‑машина падає й мені потрібно вирішити, ремонтувати чи замінювати. Вона орієнтована на швидкість і уникнення самозаробленої втрати даних.

Перше: підтвердіть, що ви не боретесь із апаратним забезпеченням

1. Перевірте, чи диск видно й чи стабільний. У WinRE Command Prompt: використайте diskpart → list disk. Якщо диски відсутні або розміри дивні, зупиніться й розслідуйте прошивку/RAID/NVMe/контролер.
2. Проскануйте на очевидні пошкодження файлової системи. Використайте chkdsk на томі Windows. Якщо воно повідомляє про багато поганих кластерів або «failed to transfer logged messages», підозрюйте відмову сховища.
3. Пошукайте I/O помилки в офлайн журналах. Якщо ви можете змонтувати і прочитати C:\Windows\System32\winevt\Logs, витягніть журнали System пізніше. У моменті наявність повторюваних помилок NTFS або диска змінює план: пріоритет — витяг даних.

Друге: класифікуйте домен відмови

1. Проблема ланцюжка завантаження? Симптоми: «No boot device», «0xc000000e», миттєве перезавантаження, відсутність записів ОС. Виправляйте EFI/BCD за допомогою bcdboot і перевіряйте EFI System Partition (ESP).
2. Проблема цілісності ОС? Симптоми: завантажується до входу, потім крашиться; Explorer ламається; постійні сповіщення SFC; помилки оновлення. Використовуйте офлайн sfc і dism.
3. Регресія після оновлення? Симптоми: почалося після Patch Tuesday, «undoing changes», чорний екран від драйвера. Використайте «Uninstall latest quality update» або «feature update», розгляньте Safe Mode.

Третє: оберіть найменш руйнівний ремонт, який може спрацювати

1. Спробуйте «Startup Repair», якщо підозрюєте просту проблему конфігурації завантаження.
2. Спробуйте «Uninstall Updates», якщо хронологія вказує на регресію після оновлення.
3. Спробуйте офлайн SFC/DISM, якщо файли пошкоджені, але диск здається здоровим.
4. Лише потім робіть ручні операції з BCD/ESP, скидання або перевстановлення.

Одне правило: якщо ви бачите ознаки відмови диска, припиніть «ремонт» і почніть «рятування». Ремонти б’ють по диску багатьма читаннями/записами. Помираючий диск не потребує підбадьорення.

Меню інструментів WinRE: що насправді робить кожен пункт

Startup Repair

Startup Repair намагається автоматично виправити процес завантаження. Практично воно перевіряє відсутні/пошкоджені файли завантаження, проблеми BCD і деякі метадані диска. Це безпечно, іноді ефективно і іноді вводить в оману повідомленням «couldn’t repair your PC», навіть коли ланцюжок завантаження очевидно зламаний.

Використовуйте, коли: система раптово перестала завантажуватися й ви не «оптимізували» розділи.

Не покладайтесь на нього, коли: маєте справу з BitLocker/TPM змінами, клонованими дисками або переміщеним EFI розділом. Воно рідко вгадує такі ситуації.

System Restore

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

Uninstall Updates

Це доросле рішення для «після оновлення зламалось». Має два варіанти:

• Latest quality update: щомісячний накопичувальний патч. Менший ризик при видаленні.
• Latest feature update: велике оновлення версії. Більший радіус ураження, але іноді необхідне.

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

Startup Settings (Безпечний режим)

Safe Mode завантажує мінімальний набір драйверів. Для відновлення він здебільшого потрібен, щоб видалити поганий драйвер, повернути налаштування GPU або видалити агент безпеки, який раптом вирішив, що ваш ядро підозріле.

Command Prompt

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

System Image Recovery

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

Reset this PC

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

Думка: Якщо у вас немає перевірених бекапів і сховищ ключів BitLocker, «Reset» — це підкидний міньйон з посмішкою.

UEFI Firmware Settings

Дає доступ до налаштувань прошивки з WinRE. Корисно, коли комбінації клавіш непослідовні або Fast Boot унеможливлює впіймати підказку. Некоректні налаштування прошивки — неправильний порядок завантаження, відключений режим NVMe, переключений Secure Boot — спричиняють дивну кількість інцидентів «Windows зламалась».

Командний рядок у WinRE: тут відбувається реальна робота

Командний рядок WinRE — це не «ваш звичайний світ C:». Букви дисків можуть змінюватися. Томат ОС може бути D:. EFI System Partition зазвичай не має букви. Ваше перше завдання — зіставити реальність.

Також: WinRE — не Linux, незважаючи на оболонку в прикладах. Команди — це Windows‑команди й виконуються в командному рядку WinRE. Формат запиту — лише узгоджена обгортка для цієї статті.

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

• Визначте розділ Windows, шукаючи каталог \Windows, а не довіряйте «C:».
• Запишіть номери дисків і розділів перед тим, як виконувати diskpart команди, що змінюють щось.
• Якщо задіяний BitLocker — розблокуйте спочатку. Інакше ви неверно діагностуєте «пошкодження», яке насправді шифрування.
• Надавайте перевагу bcdboot перед bootrec /fixboot на сучасних UEFI‑системах. Старий потік bootrec може бути крихким.

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

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

Завдання 1: Підтвердити, що WinRE бачить диски (і чи ви на GPT/UEFI)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.22621.1

DISKPART> list disk

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

Значення виводу: Disk 0 — GPT (зірочка * під Gpt), ймовірно диск ОС. Disk 1 — ймовірно диск даних або другий диск.

Рішення: Якщо диск ОС не вказаний або в статусі «Offline», зупиніться і розслідуйте сховище/прошивку. Якщо GPT присутній — плануйте роботу з EFI System Partition.

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

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D                NTFS   Partition    475 GB  Healthy
  Volume 1                      FAT32  Partition    100 MB  Healthy    System
  Volume 2     E   WINRETOOLS   NTFS   Partition    900 MB  Healthy    Hidden

Значення виводу: Windows ймовірно на D: (великий NTFS). 100MB FAT32 — це EFI System Partition (Info: System). Є розділ інструментів відновлення.

Рішення: Використовуйте D: у наступних командах. Якщо ви запустите SFC/DISM по неправильній букві, ви «вилікуєте» нічого і будете почуватися продуктивно, але даремно.

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

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

 Directory of D:\Windows

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

Значення виводу: Це реальна інсталяція Windows, не просто випадковий том з даними.

Рішення: Продовжуйте з офлайн‑командами ремонту, використовуючи D: як том ОС.

Завдання 4: Перевірити статус BitLocker (і чи треба розблокувати)

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

Volume D: [OS]
    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: None
    Key Protectors:
        TPM

Значення виводу: Том ОС зашифрований і наразі заблокований у WinRE. Офлайн SFC/DISM і доступ до файлів будуть невдалими, доки ви його не розблокуєте.

Рішення: Розблокуйте за допомогою recovery key або іншого захисного механізму, потім повторіть команди, що падали.

Завдання 5: Розблокувати BitLocker за ключем відновлення

cr0x@server:~$ manage-bde -unlock D: -recoverypassword 111111-222222-333333-444444-555555-666666-777777-888888
Key successfully applied to volume D:.

Значення виводу: Том тепер доступний для ремонту і витягнення даних.

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

Завдання 6: Запустити CHKDSK для виявлення пошкоджень файлової системи й поганих секторів

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

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

Значення виводу: Базова структура NTFS виглядає здоровою. Це не доводить, що SSD у доброму стані, але зменшує ймовірність «завантаження не вдається, бо NTFS горить».

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

Завдання 7: Ідентифікувати EFI System Partition і призначити йому букву

cr0x@server:~$ diskpart
DISKPART> select disk 0

Disk 0 is now the selected disk.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             100 MB  1024 KB
  Partition 2    Reserved            16 MB   101 MB
  Partition 3    Primary            475 GB   117 MB
  Partition 4    Recovery           900 MB   475 GB

DISKPART> select part 1

Partition 1 is now the selected partition.

DISKPART> assign letter=S

DiskPart successfully assigned the drive letter or mount point.

Значення виводу: EFI System Partition (ESP) тепер доступний як S:.

Рішення: Використовуйте S: для ремонту файлів завантаження. Якщо розділ «System» відсутній або має NTFS, можливо це legacy BIOS інсталяція або пошкоджена таблиця розділів.

Завдання 8: Відновити файли завантаження сучасним способом за допомогою bcdboot

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

Значення виводу: Файли завантаження були скопійовані і BCD‑сховище створено/оновлено на ESP для UEFI‑завантаження.

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

Завдання 9: Переглянути існуючі записи BCD (саніті‑чек)

cr0x@server:~$ bcdedit /enum firmware
Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
timeout                 1

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=S:
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Значення виводу: Прошивка вказує на Windows Boot Manager на S:. Це бажане для стандартної UEFI інсталяції.

Рішення: Якщо device/path неправильні або відсутні — виправте знову bcdboot, підтвердіть букву ESP, або перевірте наявність кількох ESP на різних дисках.

Завдання 10: Використовувати bootrec продумано (здебільшого для сканування, не «fixboot»)

cr0x@server:~$ bootrec /scanos
Scanning all disks for Windows installations.

Please wait, since this may take a while...

Successfully scanned Windows installations.
Total identified Windows installations: 1
[1]  D:\Windows

Значення виводу: Офлайн Windows виявлена. Це хороше підтвердження, що ваш том ОС читається й розпізнається.

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

Завдання 11: Запустити офлайн SFC для ремонту системних файлів

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.
Details are included in the CBS.Log windir\Logs\CBS\CBS.log.

Значення виводу: Системні файли були пошкоджені й відновлені за рахунок компонентного сховища. Це може виправити цикли завантаження, зламані сервіси та дивні краш‑повідомлення інтерфейсу.

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

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

cr0x@server:~$ dism /Image:D:\ /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22621.1

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

Значення виводу: Компонентне сховище (WinSxS) знову консистентне. Часто це розблокує SFC і виправляє пошкодження, пов’язані з оновленнями.

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

Завдання 13: Використати DISM з вказаним джерелом (коли RestoreHealth не знаходить файли)

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

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

Index : 1
Name : Windows 11 Pro
Description : Windows 11 Pro
Size : 16,234,567,890 bytes

The operation completed successfully.

cr0x@server:~$ dism /Image:D:\ /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:1 /LimitAccess
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Значення виводу: DISM взяв відновні компоненти з інсталяційного носія замість Windows Update.

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

Завдання 14: Відкотити проблемний драйвер (офлайн) шляхом вимкнення служби

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" /s /f "Start" | findstr /i "badfilter"
HKLM\OFFLINE_SYSTEM\ControlSet001\Services\badfilter
    Start    REG_DWORD    0x0

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

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

Значення виводу: Ви змонтували офлайн‑hive SYSTEM, змінили тип запуску служби на Disabled (4) і коректно відмонтували hive.

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

Завдання 15: Видалити очікуване оновлення, яке застрягло (відкат pending actions)

cr0x@server:~$ dism /Image:D:\ /Cleanup-Image /RevertPendingActions
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22621.1

Reverting pending actions from the image...
[==========================100.0%==========================]
The operation completed successfully.

Значення виводу: Windows мала очікувані дії сервісінгу (часто після невдалого оновлення) і вони скасовані, що може розв’язати цикли завантаження типу «Working on updates 30%… reboot… repeat.»

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

Завдання 16: Витягнути критичні дані на зовнішній диск (бо ремонти — не бекапи)

cr0x@server:~$ wmic logicaldisk get name,description,freespace,size
Description       FreeSpace      Name  Size
Local Fixed Disk  10234567890    D:    509876543210
Removable Disk    456789012345   F:    1000204886016

cr0x@server:~$ robocopy D:\Users\alice\Documents F:\salvage\alice\Documents /E /R:1 /W:1 /XJ
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

   Started : Tuesday, February 04, 2026 02:12:44
   Source : D:\Users\alice\Documents\
     Dest : F:\salvage\alice\Documents\

    Files : *.*

  Options : *.* /S /E /DCOPY:DA /COPY:DAT /R:1 /W:1

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

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :        42        42         0         0         0         0
   Files :      1200      1200         0         0         0         0
   Bytes :   8.3 g     8.3 g         0         0         0         0
   Times :   0:03:11   0:03:11                       0:00:00   0:00:00

Значення виводу: Ви знайшли зовнішній диск (F:) і скопіювали дані з мінімальною кількістю повторних спроб. Підсумок Robocopy з FAILED 0 — саме те, що потрібно.

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

Завдання 17: Перевірити, чи сам 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-1234567890ab
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

Значення виводу: WinRE увімкнено і вказує на розділ відновлення. Якщо воно вимкнене або відсутнє, майбутні відновлення ускладнюються.

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

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

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

Ноутбуки фінансової команди почали відмовляти після оновлення прошивки OEM. Вони могли потрапити в WinRE, і служба підтримки мала runbook: запустити офлайн SFC проти C:\Windows, потім bcdboot C:\Windows. Було швидко. Було неправильно.

На цих моделях WinRE призначав букви дисків по‑іншому. Том Windows був D:; C: був невеликим OEM інструментальним розділом. SFC щасливо запустився проти існуючої папки, але це не була активна ОС. Команда не впала. Вона просто не допомогла. Це найгірший тип відмови: «успіх», який нічого не змінює.

Потім стало гірше. Хтось запустив bcdboot C:\Windows, що створило конфігурацію завантаження, вказуючу на неправильний каталог Windows. Тепер системи, які раніше іноді могли завантажуватись, перестали завантажуватись взагалі. Інцидент ескалював від «нестабільні завантаження» до «парк недоступний».

Виправлення було нудне: зіставити томи за допомогою diskpart, підтвердити наявність \Windows, потім запустити bcdboot D:\Windows /s S: /f UEFI з призначеною буквою ESP. Урок не в «поганій допомозі». Урок у тому, щоб ніколи не закладати припущення про букви дисків у runbook для відновлення.

Також пост‑мортем ввів маленьку культурну зміну: техніки повинні були вставляти в тикет вивід list vol перед тим, як робити зміни. Це зупинило наступний інцидент «C: — Windows» перш ніж він почався.

2) Оптимізація, яка обернулася проти: «ми видалили розділ відновлення, щоб зекономити місце»

Стандартний образ компанії був щільним, бо хтось наполягав, що 256GB SSD «достатньо для всіх». Щоб звільнити місце, скрипт образування видалив WinRE‑розділ і вимкнув WinRE. Це зекономило менше гігабайта. Хтось отримав похвалу за «ефективність».

Місяці потому накопичувальне оновлення запустило цикл завантаження на підмножині машин з певним контролером зберігання. Без локально доступного WinRE автоматичний шлях відновлення не працював. Користувачі не могли послідовно потрапити в Advanced Startup, а віддалена підтримка не мала локального середовища відновлення.

Єдиним реалістичним виправленням стало: відправити USB‑носії або привезти пристрої на місце. Це не технічна проблема; це логістична. А логістичні проблеми — те, як ви перетворюєте невеликий регрес на тижневу втрату продуктивності.

Коли пристрої нарешті прибули, реальний ремонт був простим: видалити якісне оновлення або відкотити pending actions, потім застосувати новіший драйвер. Але час‑на‑виправлення був визначений відсутністю інструментів відновлення. Заощадивши шматочок диска, вони створили велику операційну відповідальність.

Вони відмінили «оптимізацію», стандартизували перевірки стану WinRE за допомогою reagentc /info і збільшили обсяг SSD при наступній закупівлі. Жарт в опсах був: «Ми обміняли 900MB на 900 запитів у службу підтримки.»

3) Нудна, але правильна практика, що врятувала день: сховище ключів BitLocker

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

Саме тут нудна практика зіграла роль: організація мала ключі BitLocker у централізованому сховищі як частину політики управління пристроями. Жодних героїчних хаків. Жодних «спробуйте цей сумнівний інструмент». Просто контрольований доступ у чергового інженера, щоб витягти ключ через належний канал.

У WinRE інженер розблокував том за допомогою manage-bde -unlock, запустив chkdsk для перевірки файлової системи, а потім скопіював критичні дані на зашифрований зовнішній диск за допомогою robocopy. Лише після того, як дані були в безпеці, відновили файли завантаження і знову заховали BitLocker.

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

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

Цікаві факти та коротка історія WinRE

• WinRE побудовано на Windows PE (Preinstallation Environment). По суті це спеціалізована міні‑ОС для інсталяції та відновлення.
• Образ відновлення зазвичай зберігається у WIM‑файлі. Його часто бачать як winre.wim, що зберігається на розділі відновлення або в тілі ОС‑розділу.
• Windows Vista популяризувала брендинг «Windows Recovery Environment». Раніші версії Windows мали Recovery Console, яка була значно обмеженіша і, чесно, менш дружня.
• UEFI змінив підхід до ремонту завантаження. На сучасних системах частіше ремонтують EFI файли завантаження і BCD‑сховище, ніж класичні MBR‑виправлення.
• BitLocker змістив фокус від «чи можемо ми прочитати диск?» до «чи можемо ми його розблокувати?» Шифрування робить багато класичних офлайн‑трюків невдалими, поки ви не розблокували том.
• Букви дисків у WinRE нестабільні за дизайном. WinRE призначає їх за порядком виявлення, а не за вашими уявленнями про те, що «C:» має бути.
• ESP зазвичай FAT32 і невеликий. Часто 100–260MB; коли він заповнений завантажувачами постачальника або залишками кількох ОС, оновлення і ремонти завантаження можуть падати.
• «Automatic Repair» не завжди WinRE. Це може бути поток завантаження, що знижує в WinRE, але якщо саме WinRE відсутнє або пошкоджене, ви можете застрягти в циклі.
• Reset/Refresh еволюціонували з поколіннями Windows. Windows 8 ввела сучасні концепції скидання; Windows 10/11 їх вдосконалили, але корпоративні робочі процеси часто віддають перевагу перепровізуванню через інструменти управління.

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

Чекліст A: Помилка завантаження на UEFI/GPT системі (більшість Windows 10/11 пристроїв)

1. Зайдіть у WinRE → Command Prompt.
2. Запустіть diskpart → list vol, ідентифікуйте том ОС (шукайте \Windows) і ESP (FAT32, «System»).
3. Якщо BitLocker увімкнено і заблоковано — розблокуйте том ОС спочатку.
4. Призначте букву для ESP (наприклад, S:).
5. Запустіть bcdboot <OS>:\Windows /s S: /f UEFI.
6. Запустіть bcdedit /enum firmware, щоб підтвердити, що шлях boot manager виглядає коректно.
7. Перезавантажте. Якщо все ще не вдається — перевірте порядок завантаження в прошивці і чи не мають кілька дисків ESP.

Чекліст B: Цикл завантаження після оновлень

1. Спробуйте WinRE → Uninstall Updates → видалити останнє якісне оновлення.
2. Якщо цикл триває, використайте Command Prompt і запустіть dism /Image:<OS>:\ /Cleanup-Image /RevertPendingActions.
3. Запустіть офлайн sfc /scannow.
4. Завантажтесь у Safe Mode (Startup Settings) і видаліть драйвер/додаток, що спричинив регресію.
5. Після відновлення призупиніть оновлення для цього кільця і перевірте драйвери перед повторним застосуванням.

Чекліст C: Підозра на відмову диска (не «ремонтуйте», поки не витягнете дані)

1. Запустіть diskpart, щоб переконатися, що диск видно і томи перелічуються.
2. Запустіть chkdsk <OS>: /scan. Якщо повідомляє про погані сектори — припиніть інтенсивні записи.
3. Розблокуйте BitLocker, якщо потрібно.
4. Скопіюйте критичні дані за допомогою robocopy з низькою кількістю повторів.
5. Плануйте заміну диска і чисту перевстановлення/відновлення. Ремонти на відмовному накопичувачі — тимчасове театро.

Чекліст D: Пошкодження та дивні симптоми без очевидних помилок диска

1. Запустіть офлайн dism /Image:<OS>:\ /Cleanup-Image /RestoreHealth.
2. Запустіть офлайн sfc /scannow.
3. Якщо DISM не вдається, надайте відповідний install.wim як джерело.
4. Перезавантажте і перевірте симптоми на рівні додатків.

Жарт #1: WinRE як вогнегасник — якщо ви тільки згадуєте про нього, коли будівля вже горить, ви робите не так.

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

1) Симптом: SFC говорить, що завершив, але нічого не змінюється

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

Виправлення: Використайте diskpart щоб знайти том ОС; підтвердіть наявність <drive>:\Windows; розблокуйте BitLocker за допомогою manage-bde; повторіть:
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows.

2) Симптом: «Boot files successfully created» але все ще «No bootable device»

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

Виправлення: Від’єднайте другорядні диски, якщо можливо, або ретельно ідентифікуйте, який диск містить активний ESP. Підтвердіть за допомогою bcdedit /enum firmware і налаштувань прошивки.

3) Симптом: Startup Repair «couldn’t repair your PC» повторно

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

Виправлення: Перейдіть до ручного режиму: розблокуйте BitLocker, запустіть CHKDSK, призначте букву ESP, запустіть bcdboot, потім офлайн DISM/SFC за потреби.

4) Симптом: DISM RestoreHealth падає з помилками джерела

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

Виправлення: Використайте відповідний носій інсталяції і вкажіть /Source:wim:E:\sources\install.wim:1 /LimitAccess. Переконайтеся, що індекс відповідає вашому виданню.

5) Симптом: «Access is denied» при спробі копіювати файли

Корінна причина: Том BitLocker заблоковано, або ви намагаєтесь копіювати захищені директорії без відповідного контексту.

Виправлення: Розблокуйте за допомогою manage-bde. Використовуйте robocopy замість Провідника. Копіюйте спочатку з шляхів профілю користувача.

6) Симптом: Система завантажується тільки після вимкнення Secure Boot / зміни налаштувань прошивки

Корінна причина: Файли завантажувача/EFI несумісні, сторонні компоненти завантажувача або проблеми з ключами/DB прошивки.

Виправлення: Віддавайте перевагу відновленню стандартного шляху Windows за допомогою bcdboot, потім знову увімкніть Secure Boot. Якщо проблема повториться, дослідіть сторонні EFI‑драйвери і оновлення прошивки.

7) Симптом: «Automatic Repair» цикл, не можна потрапити на робочий стіл, видалення оновлень не допомагає

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

Виправлення: Запустіть dism /RevertPendingActions. Якщо застрягає — офлайн‑відключіть проблемну службу через завантаження/відключення hive реєстру і перезавантажте.

8) Симптом: Diskpart показує диск, але томи не монтуються / читання файлів видає помилки

Корінна причина: Підлеглі I/O помилки диска, проблеми контролера або серйозне пошкодження NTFS.

Виправлення: Віддавайте пріоритет витягненню даних з мінімальною кількістю читань; розгляньте можливість створення образу диска; замініть апарат. Уникайте повторних запусків CHKDSK /f на відмовному диску, якщо ви не готові прийняти ризик.

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

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

1) Чи WinRE те саме, що Безпечний режим?

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

2) Чому букви дисків у WinRE інші?

Тому що WinRE призначає букви за власними правилами виявлення. Трактуйте букви як тимчасові. Ідентифікуйте розділи за розміром, типом файлової системи і наявністю \Windows.

3) Коли використовувати bootrec або bcdboot?

На сучасних UEFI/GPT системах надавайте перевагу bcdboot. Використовуйте bootrec /scanos для виявлення. Старіший потік з bootrec /fixmbr більше стосується legacy BIOS/MBR конфігурацій.

4) Як визначити, чи я на UEFI або legacy BIOS з WinRE?

Якщо диск ОС — GPT і ви маєте FAT32 «System» розділ (ESP), ви, як правило, на UEFI. diskpart → list disk (стовпець Gpt) і list vol розкажуть історію.

5) Чи може WinRE виправити проблеми з BitLocker?

WinRE може розблокувати томи BitLocker, якщо у вас є recovery key. Воно не «зламуватиме» шифрування, і не повинно цього робити. Якщо у вас немає ключа і TPM‑відновлення не працює, шлях — отримання ключа, а не технічні імпровізації.

6) Коли варто припинити спроби ремонту і просто перевстановити?

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

7) Чи «Reset this PC» зберігає мої дані?

Іноді. «Keep my files» зберігає файли користувача, але видаляє додатки і драйвери. Це не бекап і не гарантія. Якщо дані важливі — скопіюйте їх перш ніж діяти.

8) Чому DISM іноді потребує інсталяційного носія?

Бо RestoreHealth може потребувати компонентів, яких немає локально, а WinRE не тягне з Windows Update. Відповідний install.wim дає відомо‑добрий джерело.

9) Чи можна запускати антивірус або очищення від шкідливого ПЗ з WinRE?

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

10) Яка найкорисніша звичка WinRE для інституціоналізації?

Сховище ключів BitLocker плюс runbook, що починається з «map volumes» і «confirm encryption state». Більшість «таємничих пошкоджень» насправді — «неправильний розділ» або «заблокований том».

Висновок: наступні кроки, щоб уникнути повторних відмов

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

Зробіть це далі:

1. На здоровій машині запустіть reagentc /info і підтвердіть, що WinRE увімкнено і вказує на валідне місце.
2. Перевірте сховище ключів BitLocker і людський процес отримання ключів під час інцидентів.
3. Створіть мінімальний runbook WinRE: мапінг diskpart, розблокування BitLocker, CHKDSK‑скан, ремонт bcdboot, офлайн DISM/SFC.
4. Практикуйтеся один раз на лабораторній VM. Відновлення — це навичка, а не бажання.

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