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

February 21, 2026 • February 21, 2026 • Читання: 6 хв • Views: 0

Було корисно?

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

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

Що могло змінитися: драйвери, що можуть зламати завантаження

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

Критичні для завантаження драйвери сховища: SATA/AHCI, NVMe, RAID, Intel RST, фільтри виробників сховища. Якщо вони зламаються, ОС не бачить власний диск. Очікуйте помилок на кшталт INACCESSIBLE_BOOT_DEVICE.
Драйвери GPU: поганий драйвер дисплея може призвести до чорного екрану після логотипа, іноді при працюючій системі «за сценою». Він також може спричиняти збої ядра.
Драйвери в режимі ядра для безпеки та фільтри: рішення захисту кінцевої точки, DLP, шифрування, файлові фільтри. Коли вони ламаються, це часто трапляється рано під час завантаження і дуже болісно.
Драйвери стеку мережі або VPN-фільтри: зазвичай не критичні для завантаження, але можуть викликати зависання, довгі затримки або збої Safe Mode, якщо вони позначені для раннього завантаження.
Чипсетні та ACPI драйвери платформи: можуть створювати дивні зависання або проблеми з управлінням живленням, що виглядають як «мертва» машина.

Під час відкату ваша задача — знайти конкретний пакет драйвера або службу, яка змінилася, а не «скидати Windows». Скидання — крайній варіант. Відкат — це хірургія.

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

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

Перший: визначте клас помилки

Блакитний екран із зрозумілим кодом (наприклад, INACCESSIBLE_BOOT_DEVICE, SYSTEM_THREAD_EXCEPTION_NOT_HANDLED): ймовірно, критичний для завантаження драйвер або фільтр у режимі ядра.
Цикл завантаження, відсутній інтерфейс: ранній драйвер завантаження, дані конфігурації завантаження (BCD) або запит ключа шифрування диска не відображається.
Чорний екран після логотипа: часто драйвер GPU або проблема з запуском оболонки; іноді система справді завантажена, але ви її не бачите.
«Підготовка автоматичного ремонту» вічно: може бути пошкодження диска, але також зависання драйвера/служби під час завантаження.

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

Відновлення системи (System Restore), якщо є недавня точка відновлення і диск здоровий. Це оборотний «пакетний» відкат.
Налаштування запуску → Безпечний режим, якщо він завантажується. Тоді виконайте відкат у Диспетчері пристроїв або видаліть пакет драйвера.
Командний рядок WinRE для офлайн-відкату (DISM, редагування реєстру офлайн, перегляд логів). Це серйозний варіант, коли Safe Mode не працює.

Третій: ідентифікуйте винуватця, перш ніж щось видаляти

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

Перефразована ідея (атрибут): Gene Kim часто стверджує, що надійність походить від дисциплінованих, відтворюваних патернів відновлення — не від героїки в моменті.

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

Ці правила не дозволять вам перетворити виправну проблему на «перевстановіть усе».

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

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

Інструменти, які ви використовуватимете в WinRE (і чому)

WinRE (Windows Recovery Environment) — ваш офлайн-консоль для операцій. Він не гарний, але чесний.

Startup Repair: іноді виправляє BCD/ланцюжок завантаження. Він не видалить поганий драйвер, але може відновити механіку завантаження.
System Restore: відкат системних файлів і драйверів до точки відновлення. Чудово, коли така точка є і файлову систему не пошкоджено.
Командний рядок: для DISM, bcdedit, diskpart і аналізу логів.
Редактор реєстру (regedit): може завантажувати офлайн-лупи, щоб відключити службу драйвера без завантаження Windows.

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

Нижче — перевірені в полі завдання. Кожне містить команду, який вигляд має реалістичний вивід і рішення на її основі. Виконуйте їх із WinRE Command Prompt (або з Windows Setup «Repair your computer» → Command Prompt). Вивід відрізняється за системою; важливе — що він означає.

Завдання 1: Визначити букву розділу Windows (WinRE обманює з буквами)

cr0x@server:~$ diskpart
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy    Hidden
  Volume 1     C                FAT32  Partition    100 MB  Healthy    System
  Volume 2     E   Windows      NTFS   Partition    476 GB  Healthy
DISKPART> exit

Значення: Ваша інсталяція Windows знаходиться на E:, не на C:. Це нормально в WinRE.

Рішення: Використовуйте E:\Windows для офлайн-шляхів у кожній команді нижче. Якщо помилитися, DISM і reg-команди «працюватимуть» на неправильному томі — це особливий тип невдачі.

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

cr0x@server:~$ dir E:\Windows
 Volume in drive E is Windows
 Volume Serial Number is 3A1B-9C2D

 Directory of E:\Windows

02/04/2026  08:12 AM    <DIR>          .
02/04/2026  08:12 AM    <DIR>          ..
01/12/2026  06:40 PM    <DIR>          System32
01/12/2026  06:40 PM    <DIR>          INF
01/12/2026  06:40 PM    <DIR>          Logs

Значення: Схоже на реальну директорію Windows, а не випадковий розділ відновлення.

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

Завдання 3: Перевірити статус BitLocker перед тим, як ставати «кмітливим»

cr0x@server:~$ manage-bde -status E:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Volume E: [Windows]
[OS Volume]

    Size:                 475.86 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

Значення: Том ОС зашифровано й наразі заблоковано.

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

Завдання 4: Розблокувати зашифрований том ОС (якщо потрібно)

cr0x@server:~$ manage-bde -unlock E: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
The password successfully unlocked volume E:.

Значення: Тепер у вас є офлайн доступ на читання/запис.

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

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

cr0x@server:~$ wevtutil qe System /lf:true /rd:true /c:15 /f:text /q:"*[System[(Level=2)]]" /ms:5000
Event[0]:
  Log Name: System
  Source: Service Control Manager
  Date: 2026-02-04T08:15:02.000
  Event ID: 7000
  Level: Error
  Description:
  The iaStorAfs service failed to start due to the following error:
  The system cannot find the file specified.

Значення: Служба, пов’язана зі сховищем (iaStorAfs), не змогла запуститися. Це сильна підказка на невідповідність Intel RST/RAID/AHCI драйвера або його видалення.

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

Завдання 6: Переглянути журнали установки SetupAPI для останніх змін драйверів

cr0x@server:~$ type E:\Windows\INF\setupapi.dev.log | findstr /i /c:"Installing device" /c:"Driver Package" /c:"Failed" | more
>>>  [Driver Package Install - oem42.inf]
>>>  Section start 2026/02/03 19:22:11.512
     cmd: "C:\Windows\System32\drvinst.exe" /i /l
     sto:      Driver Store Path: C:\Windows\System32\DriverStore\FileRepository\iaahcic.inf_amd64_8a1c3d3b0a0a3d2e
!!!  sto: Failed to delete driver package 'oem41.inf'. Error = 0x00000002

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

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

Завдання 7: Перелік сторонніх драйверів в офлайн-образі за допомогою DISM

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

Image Version: 10.0.22631.3007

Obtained 62 driver package(s) installed in the image.

Published Name      Original File Name  Inbox  Class Name          Provider Name          Date        Version
------------------  ------------------  -----  ------------------  ---------------------  ----------  -------------
oem41.inf           iaStorAC.inf        No     SCSIAdapter         Intel Corporation      01/18/2026  19.5.1.1040
oem42.inf           iaahcic.inf         No     SCSIAdapter         Intel Corporation      02/03/2026  20.0.0.1038
oem12.inf           nvme.inf            No     SCSIAdapter         Vendor Storage Labs    02/03/2026  3.2.7.0
oem33.inf           oemgpu.inf          No     Display             Vendor GPU Inc.        02/03/2026  31.0.15.5123

Значення: Маєте кілька драйверів класу сховища, оновлених близько до часу збою. oem42.inf і oem12.inf підозрілі, бо датовані напередодні збою завантаження.

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

Завдання 8: Отримати деталі про конкретний пакет драйвера перед його видаленням

cr0x@server:~$ dism /image:E:\ /get-driverinfo /driver:oem42.inf
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Driver package information:
Published Name : oem42.inf
Original File Name : iaahcic.inf
Inbox : No
Class Name : SCSIAdapter
Provider Name : Intel Corporation
Date : 02/03/2026
Version : 20.0.0.1038
Boot Critical : Yes

Значення: DISM вказує, що він критичний для завантаження. Це ваш прапорець «не будьте легковажні».

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

Завдання 9: Спробуйте найменш руйнівну зміну — відключити проблемну службу драйвера в офлайн-реєстрі

Ми відключимо службу, встановивши тип запуску в 4 (Disabled). Робимо це офлайн, щоб Windows ніколи не завантажувала її під час старту.

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

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

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

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

Значення: Служба драйвера була налаштована на автоматичний запуск (0x0), а тепер вимкнена (4).

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

Завдання 10: Якщо відключення спрацювало, чисто видаліть пакет драйвера офлайн, щоб уникнути самовідновлення

cr0x@server:~$ dism /image:E:\ /remove-driver /driver:oem42.inf
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Searching for driver package to remove...
Removing 1 driver package(s) from the image...
[==========================100.0%==========================]
The operation completed successfully.

Значення: Пакет видалено зі сховища драйверів офлайн-образу.

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

Завдання 11: Додати (вставити) відомий робочий пакет драйвера офлайн

Іноді потрібно додати драйвер назад — особливо для контролерів сховища. Помістіть .inf і пов’язані файли на USB, наприклад F:\drivers\iastor\.

cr0x@server:~$ dism /image:E:\ /add-driver /driver:F:\drivers\iastor\ /recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Searching for driver packages to install...
Installing 1 of 2 - F:\drivers\iastor\iaStorAC.inf: The driver package was successfully installed.
Installing 2 of 2 - F:\drivers\iastor\iaStorAfs.inf: The driver package was successfully installed.
The operation completed successfully.

Значення: Ви вставили драйвери в офлайн-образ, щоб Windows могла бачити свій диск/контролер під час завантаження.

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

Завдання 12: Перевірити цілісність системних файлів офлайн (після «операції» з драйверами)

cr0x@server:~$ sfc /scannow /offbootdir=E:\ /offwindir=E:\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 під час виправлення драйверів.

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

Завдання 13: Відновити сховище компонентів офлайн, якщо SFC скаржиться

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

Image Version: 10.0.22631.3007
[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

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

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

Завдання 14: Примусити завантаження в Безпечному режимі один раз (коли нормальний цикл занадто швидкий)

Іноді можна змусити завантаження в Безпечному режимі через BCD. Ви не «одружуєтесь» з Безпечним режимом; ви лише використовуєте його, щоб видалити драйвер у зручнішому середовищі.

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

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

cr0x@server:~$ bcdedit /store E:\Boot\BCD /set {default} safeboot minimal
The operation completed successfully.

Значення: Наступне завантаження має спробувати Безпечний режим (minimal).

Рішення: Перезавантажте й спробуйте потрапити в Безпечний режим. Після виправлення драйвера приберіть прапорець safeboot, інакше Windows постійно завантажуватиметься в Безпечному режимі (смішно лише один раз).

Завдання 15: Видалити прапорець примусової загрузки в Безпечному режимі після відновлення

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

Значення: Звичайна поведінка завантаження відновлена.

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

Завдання 16: Прочитати вказівники на дампи збою офлайн і підказки з журналу завантаження

Навіть якщо ви не можете повністю проаналізувати дамп у WinRE, часто можна знайти потрібні сліди.

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

02/04/2026  08:14 AM           1,024,512 020426-11234-01.dmp

cr0x@server:~$ type E:\Windows\ntbtlog.txt | findstr /i /c:"Loaded driver" /c:"Did not load driver" | more
Loaded driver \SystemRoot\System32\drivers\CLASSPNP.SYS
Did not load driver \SystemRoot\System32\drivers\iaStorAfs.sys
Loaded driver \SystemRoot\System32\drivers\disk.sys

Значення: Логи завантаження вказують, що певний драйвер не був завантажений. Це може бути винуватець або постраждалий елемент.

Рішення: Зіставте це з журналами подій і SetupAPI. Якщо відсутній драйвер критичний для завантаження й його немає, можливо потрібно вставити його (Завдання 11), а не видаляти.

Стратегії відкату: оберіть найменш інвазивну, яка працює

Відкат драйвера без завантаження Windows — це контроль радіусу ураження. Ось як обирати метод.

Стратегія A: System Restore (краще, коли доступно)

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

Використовуйте коли: диск здоровий, є доступ до WinRE і часовий інтервал очевидний («ламалося після вчорашнього оновлення драйвера»).

Уникайте коли: підозрюєте пошкодження диска або проблеми з ключем BitLocker; відновлення може зазнати збою посередині і ускладнити відновлення.

Стратегія B: Безпечний режим → відкат в Диспетчері пристроїв (просто, але не завжди доступно)

Якщо ви можете завантажитися в Безпечному режимі, можна скористатися кнопкою відкату драйвера в Диспетчері пристроїв або видалити пристрій/пакет драйвера. Це дружній шлях для користувача.

Використовуйте коли: Безпечний режим завантажується і проблемний драйвер не потрібен у ньому (багато GPU-драйверів підстраховуються).

Уникайте коли: Безпечний режим теж падає. Так буває з драйверами типу boot-start і фільтрами безпеки.

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

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

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

Уникайте коли: ви вгадуєте зі storage-драйверами без плану відновлення. Якщо ви видалите єдиний робочий стек сховища — отримаєте помилку INACCESSIBLE_BOOT_DEVICE миттєво.

Стратегія D: Офлайн-вимкнення служби драйвера в реєстрі (тактика «вимкнути і перевірити»)

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

Використовуйте коли: ви не на 100% впевнені, який пакет винен, або драйвер позначений як критичний для завантаження.

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

Стратегія E: Відновлення BCD / перемикання прапорців Безпечного режиму (коли опції завантаження блокують)

Іноді «проблема з драйвером» насправді — прапорець завантаження (safeboot, debug, nointegritychecks) або пошкоджений BCD. Виправлення BCD не відкотить драйвер, але може дати режим, у якому ви це зробите.

Підводні камені сховища й критичних драйверів завантаження (NVMe/RAID/BitLocker)

Драйвери сховища — це місце, де «просто видалити» перетворюється на провал. Декілька реалій:

INACCESSIBLE_BOOT_DEVICE — не пропозиція. Це означає, що Windows не може спілкуватися з контролером диска з тими драйверами, які намагається використати.
Перемикання режиму сховища в BIOS (AHCI ↔ RAID) змінює потрібний драйвер. Якщо хтось поміняв налаштування BIOS під час діагностики, ви можете шукати не ту причину. Виправте режим перш ніж драйвер.
NVMe драйвери від виробника можуть бути гірші за вбудований драйвер Microsoft. Драйвери виробника іноді оптимізують під бенчмарки; надійність завантаження — не бенчмарк.
BitLocker карає за апаратні/завантажувальні зміни. Навіть «безпечні» виправлення можуть спровокувати запит ключа відновлення. Плануйте це.

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

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

Міні-історія 1: Відмова через хибне припущення

В одній середній компанії з великою парком робочих станцій команда розгорнула оновлений драйвер контролера сховища через платформу управління. У нотатках виробника було «покращує стабільність». Ця фраза — ІТ-еквівалент «довірся мені».

Припущення було просте: «це драйвер сховища; Windows Update не запропонує його, якщо він не сумісний». Звучало розумно. Але не так було. Оновлення застосувалося до підмножини машин з іншою ревізією контролера і створило невідповідність служби/драйвера boot-start.

Наступного ранку служба підтримки побачила хвилю: цикли завантаження та INACCESSIBLE_BOOT_DEVICE. Перші респондери робили звичне: Startup Repair, потім повторні перезавантаження, потім «спробуй Безпечний режим». Безпечний режим не допоміг, бо той самий драйвер завантажувався і там.

Вирішилося не магією. Технік завантажив WinRE, перерахував офлайн-драйвери DISM, знайшов найновіший OEM-INF на зламаних машинах і відключив відповідну службу в офлайн-реєстрі. Машини почали завантажуватися знов. Потім вони відкотили правильно всередині Windows і заблокували ту версію драйвера.

Урок не в «ніколи не оновлюйте драйвери». Урок — «не припускайте, що розповсюдження означає безпеку, і не ставте оновлення критичних драйверів завантаження у рутину».

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

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

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

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

Працювало нудно: WinRE, примусово Безпечний режим через BCD, видалення пакета GPU, і дозвіл Windows впасти на базовий драйвер дисплея. Завантаження стало стабільним. Пізніше вони розгорнули іншу версію драйвера у канарковому кільці і перевірили на проблемних док-моделях.

Налаштування продуктивності — добре. Але робити це в завантажувальному шляху без контролю відкату — спосіб відкрити різницю між «швидко» і «крихко».

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

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

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

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

Два фактори це зробили можливим: (1) ключі відновлення BitLocker були ескроу і доступні для уповноваженого персоналу, і (2) техніки були навчені користуватись DISM офлайн, а не просто «натискати, поки не запрацює».

Ніхто не отримає історію героя. Вони отримали тихий тиждень. Це хороший результат.

Цікаві факти та історія (коротко, конкретно)

Факт 1: Драйвери Windows зазвичай пакуються як .inf + бінарні файли і стадіються в Driver Store, щоб Windows могла перевстановлювати пристрої без зовнішніх носіїв.
Факт 2: Драйвер «boot-start» може завантажуватися до графічної сесії — так поганий драйвер може зламати завантаження ще до появи екрану входу.
Факт 3: Driver Store знаходиться під \Windows\System32\DriverStore\FileRepository і може містити кілька версій подібних драйверів поруч.
Факт 4: DISM починався як інструмент для образів, але тепер це один з найкорисніших інструментів для офлайн-ремонту зламаної інсталяції Windows.
Факт 5: Windows довго підтримувала Last Known Good Configuration (більш помітну в старіших версіях), але сучасне відновлення опирається на WinRE і точки відновлення.
Факт 6: INACCESSIBLE_BOOT_DEVICE часто запускається не лише драйверами, а й змінами режиму сховища в BIOS або відсутніми драйверами контролера після оновлення прошивки.
Факт 7: Безпечний режим — це не «без драйверів». Це «мінімальний набір драйверів», і драйвери boot-start для сховища все одно завантажуються, бо ОС потребує диска.
Факт 8: Багато продуктів безпеки кінцевої точки покладаються на файлові фільтри; поганий фільтр може завадити запуску служб і навіть оболонки.
Факт 9: Windows Update може розповсюджувати драйвери сторонніх виробників — це зручно, поки вендор не опублікує проблемний пакет і ви не дізнаєтеся, що «автоматично» не означає «безпечно».

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

Цей розділ про те, що не робити, бо ви будете спокушені.

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

Корінна причина: Несумісність драйвера контролера сховища, видалений/вимкнений критичний драйвер сховища або змінений режим сховища BIOS.
Виправлення: У WinRE перевірте історію режиму BIOS, якщо можливо, потім використайте DISM для переліку драйверів класу сховища і або відключте нову службу, або вставте відомий-робочий драйвер (Завдання 7–11).

2) Симптом: Чорний екран після логотипа, але диск активний

Корінна причина: Збій ініціалізації GPU-драйвера або проблема рукопотиску монітора/дока, спричинена новим драйвером дисплея.
Виправлення: Примусіть Безпечний режим через BCD (Завдання 14), видаліть GPU-драйвер, перезавантажте, потім встановіть стабільну версію. Якщо не потрапляєте в Безпечний режим — видаліть пакет дисплея офлайн через DISM.

3) Симптом: Цикл Automatic Repair, не доходить до робочого столу

Корінна причина: Зависання драйвера/служби під час раннього завантаження, іноді фільтри безпеки або фільтри сховища.
Виправлення: Перегляньте офлайн журнали подій і SetupAPI (Завдання 5–6). Відключіть підозрілу службу офлайн (Завдання 9). Лише тоді розгляньте видалення пакетів.

4) Симптом: Безпечний режим теж падає або цикліть

Корінна причина: Проблемний драйвер все ще завантажується в Безпечному режимі (boot-start драйвери сховища/безпеки), або система ламається раніше, ніж Безпечний режим може відрізнитися.
Виправлення: Не покладайтеся на Безпечний режим. Використайте офлайн DISM і офлайн редагування реєстру. Вимкніть службу драйвера й перезавантажте.

5) Симптом: DISM каже «The system cannot find the path specified»

Корінна причина: Ви вказали неправильну букву диска в WinRE або том заблокований BitLocker.
Виправлення: Використайте diskpart для ідентифікації томів (Завдання 1) і manage-bde для розблокування (Завдання 3–4). Потім спробуйте ще раз.

6) Симптом: Ви видалили драйвер і тепер завантаження ще гірше

Корінна причина: Ви видалили критичний для завантаження драйвер без забезпечення робочої альтернативи в образі.
Виправлення: Вставте відомо-робочий пакет драйвера офлайн (Завдання 11). Якщо його немає, потрібна медіа від виробника або копіювання з подібної машини.

7) Симптом: Після відновлення Windows постійно завантажується в Безпечному режимі

Корінна причина: Ви примусово ввімкнули Безпечний режим через BCD і забули прибрати прапорець.
Виправлення: Видаліть значення safeboot (Завдання 15).

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

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

Контрольний список A: Безпечний метод (рекомендований порядок)

Потрапити в WinRE (Automatic Repair, диск відновлення або інсталяційний носій Windows).
Визначити букву тома Windows за допомогою diskpart (Завдання 1) і перевірити dir (Завдання 2).
Перевірити BitLocker та розблокувати, якщо потрібно (Завдання 3–4).
Зібрати докази:
- Помилки з системного журналу (Завдання 5)
- Хронологія встановлення драйверів SetupAPI (Завдання 6)
- Підказки завантаження (ntbtlog.txt), якщо є (Завдання 16)
Визначити підозрілий клас:
- Сховище? пріоритет — критичні драйвери завантаження.
- GPU? пріоритет — драйвери дисплея і вхід у Безпечний режим.
- Фільтр безпеки? шукати фільтри/служби, що не запускаються.
Перелічити офлайн-драйвери за допомогою DISM (Завдання 7).
Оглянути підозрілі пакети драйверів перед дією (Завдання 8).
Віддавайте перевагу відключенню служби драйвера спочатку через офлайн-реєстр, якщо критичний для завантаження або невпевненість (Завдання 9).
Перезавантажитися і протестувати. Якщо завантаження повернулося, зробіть прибирання всередині Windows (відкат пристрою, видалення пакета, блокування оновлення).
Якщо потрібно — видаліть пакет драйвера офлайн (Завдання 10).
Якщо ви втратили видимість сховища, вставте відомо-робочий драйвер офлайн (Завдання 11).
Запустіть офлайн-перевірки цілісності (Завдання 12–13) після того, як система завантажиться, або перед фінальним перезавантаженням, якщо підозрюєте часткові установки.
Відкличте примусовий Безпечний режим, якщо його використовували (Завдання 15).

Контрольний список B: Якщо у вас рівно 20 хвилин до ескалації

Букви дисків + розблокування BitLocker (Завдання 1–4).
DISM список драйверів (Завдання 7) і знайти найновіші сторонні пакети сховища/дисплея/безпеки за датою.
Офлайн-вимкніть найновішу підозрілу службу boot-start (Завдання 9).
Перезавантажте. Якщо завантажилось — не чіпайте його і виконайте контрольований прибирання всередині Windows.

Контрольний список C: Після відновлення (щоб воно залишалося виправленим)

Підтвердити версію драйвера пристрою в Диспетчері пристроїв для постраждалого класу (сховище/GPU/безпека).
Заблокувати погане оновлення драйвера через корпоративний інструмент оновлень або політику. Не покладайтеся на пам’ять.
Створити точку відновлення, якщо середовище це дозволяє для кінцевих точок.
Переконатися, що ключі відновлення BitLocker ескроу і доступні потрібним людям.
Записати точну назву OEM INF (наприклад, oem42.inf), яка спричинила інцидент. Це ваша судова ручка для майбутньої автоматизації.

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

1) Чи можливо «Roll Back Driver» у Диспетчері пристроїв, якщо Windows не завантажується?

Не безпосередньо. Якщо ви не можете дістатися GUI, ви робите офлайн-відкат: видалення пакета через DISM, офлайн-вимкнення служби або System Restore з WinRE.

2) Яка найбезпечніша перша дія: видаляти пакет драйвера чи вимикати службу?

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

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

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

4) DISM показує кілька драйверів сховища. Який видаляти?

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

5) Якщо я видалю драйвер GPU офлайн, чи завантажиться Windows з базовим драйвером?

Зазвичай так. Windows може відкотитись до базового драйвера Microsoft. Це часто достатньо, щоб повернутися на робочий стіл і встановити стабільну версію.

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

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

7) Чи виправить Startup Repair поганий драйвер?

Рідко. Startup Repair виправляє ланцюжок завантаження, а не сумісність драйверів. Спробуйте швидко, але не зациклюйтесь на ньому, якщо збій почався після установки драйвера.

8) Чи видалить System Restore проблемний драйвер?

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

9) Я відключив службу драйвера і система завантажилась. Чи залишати її вимкненою?

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

10) Як запобігти повторній установці поганого драйвера через Windows Update?

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

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

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

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

Напишіть односторінковий внутрішній runbook з процесом доступу до ключів BitLocker, методом входу в WinRE і DISM-командами, яким ви довіряєте.
Впровадьте кільця для розгортання драйверів: пілотна група, потім ширше розгортання. Це менеджмент змін у реальному світі.
Тримайте набір відомо-робочих драйверів (сховище + мережа + базові GPU) на USB для відновлення. Не хочете шукати драйвери під час інциденту.
Після відновлення заблокуйте погану версію і зафіксуйте назву OEM INF. Ваш майбутній «я» буде втомлений і вдячний.

Схожі статті

Відключити перевірку підпису драйверів? Безпечніші альтернативи