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

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

«Встановлення драйвера» — це не одна річ. Зазвичай це пакет:
драйвер у режимі ядра (.sys), INF-пакет, запис служби, можливо фільтр-драйвери,
можливо ко-інсталятор, можливо допоміжний процес у користувацькому режимі, який телефонує додому під час завантаження, якщо може.
Коли драйвер ламає завантаження, він зазвичай робить це одним із п’яти способів:

1. Краш драйвера на етапі завантаження: Start=0 (BOOT_START) служба завантажується рано і робить недоречний доступ. Результат: миттєвий BSOD.
2. Псування стеку зберігання: драйвер контролера зберігання/NVMe/RAID/фільтр змінює спосіб, у який диски перелічуються. Результат: недоступний завантажувальний пристрій, відсутній том або плутанина з BitLocker.
3. Перевірка цілісності коду / примус підпису: Windows відмовляє в завантаженні неподписаного/заблокованого драйвера. Результат: збій завантаження або цикл відновлення з повідомленням «driver can’t be loaded».
4. Пошкодження пам’яті ядра: драйвер «працює», доки не пошкодить пам’ять і ви не впадете пізніше. Результат: BSOD не відразу при логотипі; у вас є кілька секунд/хвилин.
5. Невідповідність залежностей: драйвер очікує іншу збірку ОС, інші налаштування гіпервізора або конфліктуючий стек постачальника. Результат: випадкові збої, іноді тільки на певних апаратних ревізіях.

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

Ще одне: драйвери — це інфраструктура. Ставтеся до них як до змін конфігурації в продакшені.
Відкати повинні бути нудними, зворотними і задокументованими (навіть якщо «задокументовано» — це фото екрана, бо ви в парку).

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

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

Перший: класифікуйте BSOD та поведінку завантаження

• Миттєвий краш на етапі логотипу/крутилки → ймовірно BOOT_START драйвер або проблема зі стеком зберігання.
• Краш після появи екрану входу → часто відео-, мережевий або драйвер безпеки (також у режимі ядра, але пізніше).
• Код зупинки «INACCESSIBLE_BOOT_DEVICE» → драйвер контролера зберігання, фільтр-драйвер або BCD/шлях до пристрою.
• Згадує .sys файл → у вас є головний підозрюваний. Запишіть його.

Другий: оберіть найменший важіль відкату

• Startup Settings → Safe Mode (мінімальне завантаження), якщо доступно. Видаліть або відкатіть драйвер з-під Windows.
• WinRE → System Restore, якщо є контрольні точки й ви можете їх допустити.
• WinRE → Command Prompt для офлайн-відкату: DISM видалення пакета драйвера або офлайн-реєстр для відключення служби драйвера.

Третій: перевірте завантаження, потім підвищіть стійкість

• Підтвердіть, що система завантажується двічі поспіль. Одне вдале завантаження — це жартівливий сигнал.
• Збережіть логи/дампи. Визначте корінь проблеми — пакет драйвера — і заблокуйте його повторну появу.
• Переінсталюйте драйвери цілеспрямовано (з пакета постачальника або Windows Update), а не «те, що знайде майстер».

Як потрапити в Windows Recovery Environment (WinRE), не погіршивши ситуацію

WinRE — це ваше «out-of-band» керування для ноутбуків і серверів Windows без iDRAC/iLO.
Це не гламурно, але зазвичай достатньо.

Стандартні способи потрапити в WinRE

• Automatic Recovery: після кількох невдалих завантажень Windows часто переходить у «Preparing Automatic Repair». Дайте йому завершити. Не вимикайте живлення під час діагностики, якщо він не завис дійсно.
• Під час завантаження: переривайте завантаження 2–3 рази (вимкніть живлення щойно з’явилися крапки), щоб викликати відновлення. Це грубо, але дієво.
• З USB із інсталятором: «Repair your computer» → Troubleshoot → Advanced options. Це часто найчистіший шлях, якщо локальний WinRE пошкоджений.

Про BitLocker — реальність

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

Жарт №1: Якщо у вас немає ключа відновлення BitLocker, у вас немає плану відновлення — у вас є план надії.

Докази перш за все: що зібрати перед тим, як «виправляти»

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

У WinRE докази здебільшого про: який Windows встановлений на якому буквеному диску, які драйвери додані останніми,
і чи вказує дамп/лог на конкретний .sys.

• Зафіксуйте точний код зупинки і будь-який названий драйвер (фото підходить).
• Визначте букву тома Windows у WinRE (зазвичай це не C:).
• Перевірте наявність minidump і логів завантаження (якщо є).
• Перелічіть нещодавно додані пакети драйверів офлайн (DISM це може зробити).

Мета проста: відповідати на питання «Що ми прибрали/відключили і чому?»

Шляхи відкату з режиму відновлення (оберіть найменш руйнівний)

Шлях A: Safe Mode, потім стандартне видалення/відкат

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

Використайте WinRE: Troubleshoot → Advanced options → Startup Settings → Restart, потім оберіть:
4 (Safe Mode) або 5 (Safe Mode with Networking), якщо потрібно завантажити відомий добрий драйвер.

У Safe Mode:
видаліть драйвер/програмне забезпечення через Programs and Features, якщо це пакет постачальника,
або зробіть відкат через Device Manager, коли це оновлення драйвера пристрою,
або використайте pnputil для прицільного видалення.

Шлях B: System Restore (швидко, інколи грубо)

System Restore може відкотити встановлення драйверів, тому що драйвери — це частина «стану системи», який відстежується точками відновлення.
Це часто найшвидший шлях, коли ви не знаєте, який драйвер порушив завантаження. Торг — можна відкотити інші зміни теж (оновлення, налаштування).

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

Шлях C: Офлайн-видалення драйвера через DISM (точно, надійно)

DISM може інспектувати та видаляти пакети драйверів із офлайн-образу Windows.
Це метод, який застосовують, коли Safe Mode не завантажується, а System Restore відсутній або ризикований.

Це також метод, який дає аудит: «видалено oem42.inf, який містив badstor.sys».

Шлях D: Офлайн-редагування реєстру для відключення служби драйвера (скальпель останньої інстанції)

Іноді пакет неможливо чисто видалити (заблокований стан, залежність, заплутаний стек постачальника),
але можна заборонити драйверу завантажуватись, змінивши його тип запуску.
Це може бути достатньо для завантаження, а потім завершити прибирання у звичайному сеансі.

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

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

Всі завдання нижче передбачають, що ви в Command Prompt у WinRE (або в підвищеному командному рядку в Safe Mode, де зазначено).
Найпоширеніша помилка тут — припускати, що диск ОС це C:. У WinRE часто ні.

Завдання 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    237 GB  Healthy
  Volume 1         SYSTEM       FAT32  Partition    100 MB  Healthy    System
  Volume 2     E   Recovery     NTFS   Partition    900 MB  Healthy    Hidden

DISKPART> exit

Що це означає: Том Windows — D:, а не C:.
Рішення: Використовуйте D:\Windows для всіх офлайн-шляхів нижче.

Завдання 2: Переконатися, що ви дивитесь у правильну папку Windows

cr0x@server:~$ dir D:\Windows\System32
 Volume in drive D is Windows
 Volume Serial Number is 34E2-9A1C

 Directory of D:\Windows\System32

...snip...

Що це означає: Каталог існує і виглядає як реальна ОС.
Рішення: Продовжуйте; розподіл букв вірний.

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

cr0x@server:~$ manage-bde -status D:
BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Volume D: [Windows]
    Size:                 237.00 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        Numerical Password

Що це означає: Том зашифрований, але розблокований у WinRE (поширено, якщо відновлення вже аутентифіковано).
Рішення: Якби том був заблокований, треба manage-bde -unlock D: -RecoveryPassword YOUR-KEY перед тим, як DISM зможе його читати.

Завдання 4: Знайти докази BSOD попереднього завантаження в офлайн журналях подій

cr0x@server:~$ wevtutil qe /lf:true D:\Windows\System32\winevt\Logs\System.evtx /q:"*[System[(EventID=41 or EventID=1001)]]" /c:5 /rd:true /f:text
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Level: Error
  Description: The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000007B ...
Event[1]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Event ID: 41
  Level: Critical
  Description: The system has rebooted without cleanly shutting down first.

Що це означає: У вас є код bugcheck (тут 0x7B, класичний inaccessible boot device).
Рішення: Фокус на драйверах контролера зберігання/фільтрах і нещодавніх встановленнях, пов’язаних зі зберіганням.

Завдання 5: Перевірити наявність minidump і скопіювати їх кудись безпечно

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

02/04/2026  08:13 AM           1,245,184 020426-9328-01.dmp
               1 File(s)      1,245,184 bytes

Що це означає: Minidump є. Добре — він може назвати проблемний драйвер пізніше.
Рішення: Скопіюйте його поза коробку (USB, мережева шара) перед будь-якими змінами, якщо це можливо.

Завдання 6: Перелічити встановлені сторонні пакети драйверів офлайн (DISM)

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

Image Version: 10.0.19045.3803

Published Name  Original Name  Inbox  Class Name          Provider Name       Date
-------------  -------------  -----  ------------------  ------------------  ----------
oem12.inf      iaStorVD.inf   No     SCSIAdapter         Intel              01/29/2026
oem21.inf      nvme.inf       No     SCSIAdapter         VendorStorageCo     02/03/2026
oem34.inf      netwtw10.inf   No     Net                 Intel              11/10/2025

Що це означає: Є нещодавно доданий драйвер зберігання (oem21.inf) датований безпосередньо перед крашем.
Рішення: Це кандидат на видалення або відключення, але підтвердіть, що це не єдиний драйвер, потрібний для завантаження вашого контролера.

Завдання 7: Інспектувати конкретний пакет драйвера на предмет файлів і версій

cr0x@server:~$ dism /image:D:\ /get-driverinfo /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Driver package information:
Published Name: oem21.inf
Original File Name: nvme.inf
Provider Name: VendorStorageCo
Class Name: SCSIAdapter
Class GUID: {4d36e97b-e325-11ce-bfc1-08002be10318}
Driver Version: 02/03/2026 2.1.0.14
Signer Name: Microsoft Windows Hardware Compatibility Publisher

Що це означає: Це драйвер класу зберігання, нещодавно встановлений. Підписаний, отже, ймовірно помилка/несумісність, а не відмова через підпис.
Рішення: Якщо BSOD це 0x7B, видалення цього пакета — розумний наступний крок, хіба що він замінив єдиний необхідний драйвер для вашого контролера.

Завдання 8: Видалити підозрілий пакет драйвера офлайн

cr0x@server:~$ dism /image:D:\ /remove-driver /driver:oem21.inf
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Removing driver package: oem21.inf
[==========================100.0%==========================]
The operation completed successfully.

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

Завдання 9: Якщо вдається завантажити Safe Mode, використайте pnputil для видалення пакета (онлайн)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem12.inf
Driver Package Provider : Intel
Class : SCSIAdapter
Driver Version And Date : 01/29/2026 19.6.1.1053
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Published Name : oem34.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 11/10/2025 22.250.1.2
Signer Name : Microsoft Windows Hardware Compatibility Publisher

Що це означає: Ви бачите, що встановлено, коли Windows запущена (навіть у Safe Mode).
Рішення: Використайте pnputil /delete-driver oemXX.inf /uninstall для цілеспрямованого прибирання, особливо для пакетів постачальників, які постійно перевстановлюють драйвери.

Завдання 10: Увімкнути журнал завантаження, щоб зафіксувати, який драйвер підвантажується останнім (коли доступні Startup Settings)

cr0x@server:~$ bcdedit /store D:\Boot\BCD /set {default} bootlog Yes
The operation completed successfully.

Що це означає: Наступні спроби завантаження запишуть ntbtlog.txt.
Рішення: Перезавантажте, дайте збоїтись один раз, потім поверніться у WinRE і перевірте лог.

Завдання 11: Прочитати журнал завантаження офлайн, щоб побачити останній підвантажений драйвер

cr0x@server:~$ type D:\Windows\ntbtlog.txt
Loaded driver \SystemRoot\system32\ntoskrnl.exe
Loaded driver \SystemRoot\System32\drivers\CLASSPNP.SYS
Loaded driver \SystemRoot\System32\drivers\disk.sys
Loaded driver \SystemRoot\System32\drivers\badstor.sys

Що це означає: Останнім у списку завантажених драйверів є badstor.sys. Це явний доказ.
Рішення: Видаліть його пакет через DISM або відключіть його службу офлайн.

Завдання 12: Відключити службу драйвера офлайн, редагуючи hive реєстру (безпечніше, ніж видаляти наосліп)

Це хід «припинити його завантаження». Ви завантажуєте офлайн hive SYSTEM, редагуєте ключ служби, відвантажуєте hive.

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

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

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

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

Що це означає: Start=0 (boot start) змінилося на Start=4 (disabled).
Рішення: Перезавантажте. Якщо система завантажується, у вас є стабільна платформа, щоб коректно прибрати драйвер і встановити відомо добру версію.

Завдання 13: Підтвердити активний control set (щоб не правити невірний)

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

cr0x@server:~$ reg query HKLM\OFFSYS\Select
HKEY_LOCAL_MACHINE\OFFSYS\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    LastKnownGood    REG_DWORD    0x2

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

Що це означає: Current=1 вказує, що ControlSet001 актуальний.
Рішення: Якби Current було 2, ви б правили ControlSet002 (або обидва для перестраховки).

Завдання 14: Використати логіку Last Known Good Configuration (ручна підказка)

Windows не показує «Last Known Good» так, як раніше, але реєстр все ще його відстежує.
Якщо драйвер на етапі завантаження зламався, примусове завантаження з вибором last known good control set може допомогти.
Практичний підхід — відключити драйвер в обох control set 001 і 002, якщо ви не впевнені.

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

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

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

Що це означає: Ви відключили драйвер і в альтернативному control set.
Рішення: Це зменшує сюрпризи на кшталт «воно завантажилося один раз, а потім знову зламалося».

Завдання 15: Перевірити, чи файл драйвера дійсно існує офлайн (а не є залишком)

cr0x@server:~$ dir D:\Windows\System32\drivers\badstor.sys
 Volume in drive D is Windows
 Directory of D:\Windows\System32\drivers

02/03/2026  06:21 PM           842,752 badstor.sys
               1 File(s)        842,752 bytes

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

Завдання 16: Якщо драйвер — фільтр, визначити точки приєднання (офлайн-перевірка реєстру)

Фільтр-драйвери для зберігання часто живуть у UpperFilters/LowerFilters і можуть вивести з ладу завантаження, якщо неправильно налаштовані.

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

cr0x@server:~$ reg query "HKLM\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}" /v UpperFilters
HKEY_LOCAL_MACHINE\OFFSYS\ControlSet001\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}
    UpperFilters    REG_MULTI_SZ    badstorflt

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

Що це означає: Є upper filter, приєднаний до класу дисків. Якщо він зіпсований, увесь клас може працювати неправильно.
Рішення: Відключіть службу фільтра (або видаліть пакет) замість того, щоб грубо виривати значення реєстру — хіба що у вас є сильні докази, що саме запис UpperFilters корумпований.

Завдання 17: Запустити офлайн перевірку системних файлів (коли підозрюєте побічні ушкодження, а не лише драйвер)

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 did not find any integrity violations.

Що це означає: Основні файли Windows цілі.
Рішення: Зосередьтесь на відкаті драйвера, а не на відновленні ОС.

Завдання 18: Перевірити диск на помилки файлової системи (особливо після циклів крашів)

cr0x@server:~$ chkdsk D: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
No problems found.

Що це означає: Файлова система виглядає здоровою.
Рішення: Якщо були знайдені помилки, виправте їх перед тим, як ганятися за привидами драйверів: chkdsk D: /f (може знадобитися перезавантаження).

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

Міні-історія 1 (помилкове припущення): «Це лише драйвер GPU, він не може вплинути на завантаження»

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

У понеділок декілька машин застрягли в циклі завантаження. Код зупинки був непослідовним.
Деякі показували названий .sys файл, пов’язаний зі стеком GPU. Інші просто перезавантажувались до того, як хтось устиг прочитати.
Служба підтримки пробувала Startup Repair багато разів. Це нічого не дало, окрім витрати часу і впевненості.

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

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

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

Міні-історія 2 (оптимізація, що відпалилася): заміна драйверів зберігання задля «більшої продуктивності»

Невелика SaaS-компанія купила нові NVMe для кількох локальних Windows-серверів, що зберігали артефакти збірки.
Хтось знайшов постачальницький «драйвер продуктивності» і утиліту управління, що обіцяли покращене оброблення черги і нижчу затримку.
Вікно змін було коротким. Аргумент був простий: «це рекомендований драйвер постачальника».

Драйвер встановився чисто і сервер перезавантажився нормально один раз. Потім, після ще одного рестарту, виник INACCESSIBLE_BOOT_DEVICE.
WinRE бачив диск, але Windows не змогла змонтувати завантажувальний том вчасно. Це такий тип відмови, що змушує розглядати хобі на кшталт столярства,
де інструменти принаймні чесні у своїй небезпеці.

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

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

Урок післямортему: оптимізації, що зачіпають критичні шляхи завантаження, потребують тестування через цикли перезавантаження і різні стани прошивки.
Зміна, що пережила одне перезавантаження, не є доведеною; вона просто пощастила.

Міні-історія 3 (нудна, але правильна практика): кільця розгортання драйверів і збережені ключі відновлення виручили

ІТ-команда підприємства керувала тисячами ноутбуків із повним дисковим шифруванням.
У них була звичка, про яку ніхто не хвалився: поетапні розгортання драйверів у кільцях (pilot → early → broad),
та перевірка, що ключі відновлення BitLocker збережені і доступні для чергових інженерів.

Оновлення Wi‑Fi драйвера прийшло внутрішнім пакетом. На невеликому підмножині машин з певною апаратною ревізією
воно спричинило BSOD незабаром після входу. Не під час завантаження, але близько настільки, що користувачі називали це «не стартує».
Пілотне кільце спіймало це за кілька годин.

Реакція команди не була героїчною. Вона була процедурною: заблокували оновлення для подальшого розгортання,
опублікували короткий внутрішній runbook і інструктували постраждалих користувачів завантажитись у Safe Mode та відкатити драйвер.
Для машин, що не могли потрапити в Safe Mode, чергові використовували WinRE з recovery key, потім відключали службу драйвера офлайн.

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

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

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

1) «Startup Repair не допоміг, отже Windows пошкоджена»

Симптом: Цикл Automatic Repair; «Startup Repair couldn’t repair your PC.»

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

Виправлення: Використайте WinRE Command Prompt для переліку нещодавніх драйверів (dism /get-drivers), видаліть підозрілий пакет або відключіть службу офлайн.

2) «Я видалив .sys файл і стало ще гірше»

Симптом: Новий код зупинки або Windows скаржиться на відсутній драйвер; стек пристрою працює інакше.

Корінь проблеми: Ви видалили бінарник, але лишили посилання служби та INF-пакету.

Виправлення: Надавайте перевагу видаленню пакета (dism /remove-driver офлайн або pnputil /delete-driver онлайн). Якщо вже видалили, відновіть його зі сховища драйверів або перевстановіть відому добру версію.

3) «DISM не може знайти образ»

Симптом: DISM помилки при використанні /image:C:\.

Корінь проблеми: Невірна буква диска у WinRE.

Виправлення: Використайте diskpart → list vol щоб ідентифікувати том Windows, потім вкажіть правильну букву (часто D:).

4) «Я відключив драйвер зберігання і тепер отримую INACCESSIBLE_BOOT_DEVICE»

Симптом: 0x7B після редагування значень Start у реєстрі.

Корінь проблеми: Ви відключили необхідний miniport/RAID/NVMe драйвер замість проблемного додатку/фільтра.

Виправлення: Заново ввімкніть драйвер (поверніть Start) і натомість видаліть нещодавній фільтр або сторонній пакет; використайте точку відновлення, якщо доступна.

5) «Safe Mode теж показує синій екран; я застряг»

Симптом: Навіть Safe Mode падає.

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

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

6) «Драйвер постійно повертається після видалення»

Симптом: Після відновлення Windows Update перевстановлює той самий драйвер; BSOD повертається.

Корінь проблеми: Автоматичні оновлення драйверів повторно застосовують проблемну версію.

Виправлення: Використайте політики/налаштування, щоб заблокувати оновлення драйверів для цього класу пристроїв або сховайте оновлення; встановіть відому добру версію і закріпіть її.

7) «WinRE просить ключ BitLocker і у нас його немає»

Симптом: Немає доступу до D:\Windows або не можна запустити DISM; том заблоковано.

Корінь проблеми: Зашифрований том ОС і відсутній процес отримання ключа відновлення.

Виправлення: Отримайте ключ відновлення з системи ескроу організації або з облікового запису Microsoft користувача. Без нього можливості обмежені.

8) «Я видалив драйвер, але воно все одно падає»

Симптом: Той самий код зупинки зберігається.

Корінь проблеми: Видалений драйвер не був тим, що завантажувався першим, або існує кілька компонентів (фільтр + miniport + служба).

Виправлення: Увімкніть журнал завантаження і перевірте ntbtlog.txt; перевірте фільтри класу; видаліть/відключіть фактичний компонент, що завантажується.

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

Контрольний список 1: Послідовність відновлення з мінімальним ризиком

1. Увійдіть у WinRE (Automatic Recovery або USB з інсталятором).
2. Запишіть код зупинки і будь-який згаданий .sys файл.
3. Відкрийте Command Prompt. Визначте букву тома Windows через diskpart.
4. Перевірте стан BitLocker; розблокуйте, якщо потрібно.
5. Спробуйте Startup Settings → Safe Mode. Якщо вдається завантажитись, видаліть/відкотіть драйвер стандартно.
6. Якщо Safe Mode не допоміг, перелічіть офлайн-драйвери через DISM; шукайте нещодавні не-inbox драйвери за часом збою.
7. Видаліть підозрілий пакет драйвера офлайн через DISM.
8. Перезавантажте. Якщо все ще не вдається, увімкніть журнал завантаження через bcdedit, відтворіть один збій, потім перевірте ntbtlog.txt.
9. Якщо виявлено драйвер, що блокує завантаження, відключіть його службу офлайн (встановіть Start=4 в правильному control set).
10. Після завантаження стабілізуйте систему: встановіть відому добру версію драйвера, заблокуйте проблемну версію від повторного встановлення, збережіть дампи/логи для аналізу.

Контрольний список 2: Якщо код зупинки INACCESSIBLE_BOOT_DEVICE (0x7B)

1. Припустіть проблему зі шляхом зберігання. Не відключайте драйвери наосліп.
2. Використайте DISM, щоб перелічити драйвери класу зберігання і сортувати їх за датою (ментально, за виводом).
3. Спочатку видаліть найновіший сторонній драйвер зберігання/фільтр.
4. Якщо ви редагували реєстр, перевірте, що не відключили потрібний miniport драйвер.
5. Перевірте фільтри класу дисків (UpperFilters/LowerFilters) і відключіть службу фільтра за потреби.
6. Тільки після цього розгляньте глибше відновлення (SFC/CHKDSK), якщо докази вказують на проблеми файлової системи.

Контрольний список 3: Якщо BSOD називає .sys файл

1. Знайдіть файл на диску: D:\Windows\System32\drivers\name.sys.
2. Використайте DISM driver info, щоб зіставити його з INF-пакетом, якщо можливо.
3. Видаліть пакет через DISM (офлайн) або pnputil (Safe Mode/онлайн).
4. Якщо видалення не вдається, відключіть службу офлайн.
5. Завантажтесь, потім замініть на відому добру версію від OEM або через контрольований Windows Update.

Жарт №2: «Просто перевстановіть Windows» — це ІТ-еквівалент вирішення скрипучих дверей шляхом переїзду.

Цікаві факти та історичний контекст

• Драйвери Windows часто — це служби. Драйвери ядра зазвичай реєструються під HKLM\SYSTEM\...\Services з типом запуску Start, що контролює, коли вони завантажуються.
• BOOT_START драйвери завантажуються раніше, ніж ви встигаєте ввійти. Якщо драйвер на етапі завантаження ламається, навіть Safe Mode може впасти, бо Safe Mode все ще потребує базових драйверів зберігання і класових драйверів.
• INACCESSIBLE_BOOT_DEVICE (0x7B) — класика. Він з’являється, коли Windows не може спілкуватись із завантажувальним томом — часто через зміни драйвера контролера зберігання або фільтр-драйверів.
• Пакети драйверів живуть у driver store. Driver store дозволяє відкотити і забезпечувати послідовні встановлення, але це також означає, що «вилучити .sys» не видаляє пакет і може створити неповний стан.
• DISM може обслуговувати офлайн-образи. Він був створений для управління образами Windows, і та сама механіка працює для пошкодженого тома ОС з WinRE.
• Фільтр-драйвери — потужні і небезпечні. Антивірус, шифрування, резервні копії та інструменти зберігання часто використовують фільтри; поганий фільтр може зламати увесь клас пристроїв.
• Букви дисків у WinRE нестабільні. Середовища відновлення призначають букви інакше, ніж ваша працююча ОС, тому «C:\Windows» часто вводить в оману.
• BitLocker змінив культуру реагування на інциденти. Шифрування — корисна річ, але воно змушує організації відпрацьовувати ескроу ключів і робочі процеси відновлення — або платити за це під час простоїв.
• Windows Error Reporting фіксує bugcheck-и. Навіть коли користувачі не встигають прочитати BSOD, система часто логуватиме інформацію про bugcheck і створюватиме minidump для подальшого аналізу.

Парафраз ідеї (Werner Vogels): будуй системи з припущенням, що відмови відбудуться, і роби відновлення першокласною опцією.

FAQ

1) Що спочатку використовувати: System Restore чи DISM для видалення драйвера?

Якщо у вас є точка відновлення і вам потрібна швидкість, System Restore підходить. Якщо хочете точність і чіткий аудиторський слід — використовуйте DISM.
У корпоративному середовищі я вважаю за краще DISM, коли підозрюваний драйвер очевидний і критичний для завантаження.

2) Чому Safe Mode все ще показує синій екран?

Safe Mode — «мінімальний», а не «без драйверів». Драйвери на етапі завантаження, драйвери класу зберігання та деякі компоненти безпеки досі підвантажуються.
Якщо краш відбувається в цьому ранньому наборі — Safe Mode не врятує. Ідіть офлайн: DISM або відключення реєстром.

3) Чи можна відкотити драйвер без його видалення?

Іноді так. Якщо Windows може завантажитись, «Roll Back Driver» у Device Manager може повернути попередню версію.
З WinRE офлайн зазвичай видаляють проблемний пакет, а потім після завантаження перевстановлюють відому добру версію.

4) Що робити, якщо DISM каже «The driver package could not be installed» або видалення не вдається?

Якщо видалення офлайн не вдається, перевірте, чи том розблокований (BitLocker) і чи вказаний вірний шлях до образу.
Якщо й далі не вдається, відключіть службу драйвера офлайн (встановіть Start=4), щоб завантажити систему, а потім прибирайте зсередини Windows.

5) Чи безпечно відключати службу драйвера, присвоївши Start=4?

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

6) Мій BSOD не називає драйвер. Як знайти винуватця?

Використайте офлайн журнали подій для отримання кодів bugcheck, перевірте наявність minidump, увімкніть журнал завантаження і шукайте нещодавні встановлення драйверів через DISM.
Скоординуйте за часом: що змінилося безпосередньо перед початком збоїв.

7) Після відновлення як заборонити Windows Update перевстановлювати поганий драйвер?

У керованих середовищах використовуйте політики для блокування оновлень драйверів або обмеження по класу пристроїв.
На автономних машинах можна вимкнути автоматичні оновлення драйверів і встановити відому добру версію від OEM.
Мета — розірвати цикл «перевстановлення → перезавантаження → краш».

8) Видалення пакета драйвера видалить мої дані?

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

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

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

10) Чи варто іноді перевстановити Windows?

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

Висновок: кроки, що запобігають повторенню

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

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

Практичні кроки (зробіть сьогодні)

• Перевірте, що ключі відновлення BitLocker ескроудені і доступні черговому персоналу.
• Запровадьте кільця розгортання драйверів: спочатку пілот, потім розширення.
• Тримайте завантажувальний USB з інсталятором Windows (або еквівалент) для критичних машин.
• Задокументуйте один внутрішній runbook для офлайн-видалення драйверів через DISM та офлайн-відключення служб.
• Після відновлення зафіксуйте відому добру версію драйвера і заблокуйте механізм, що спричинив проблему.