«Цей пристрій не може запуститися (код 10)»: кроки ремонту, які справді допомагають

Що насправді означає Код 10 (і чого він не означає)

Код 10 — це не одна помилка. Це загальний випадок «драйвер пристрою запустився… а пристрій — ні». Таке може статися через те, що:
пристрій неправильно перелічився (enumeration), прошивка плутається, до апаратного ID прив’язано неправильний драйвер, драйвер запустився але
впав під час ініціалізації, або Windows застосував політику/функцію, яка зламала шлях запуску пристрою.

Уявіть собі запуск пристрою в Windows як конвеєр завантаження: виявлення (PnP), співставлення (INF/сховище драйверів), інсталяція (копіювання + реєстр),
запуск (завантаження служби) і функціональна ініціалізація (виклики, специфічні для пристрою). Код 10 зазвичай виникає на межі «запуск/ініціалізація».
Ваше завдання — знайти, що змінилося та який рівень бреше.

Типові місця, де ховається Код 10

• USB і док‑станції: бюджет живлення, selective suspend, прошивка хаба або ілюзія «на моєму порту працює».
• Мережеві адаптери: NDIS‑фільтри, VPN‑клієнти, засоби безпеки кінцевих точок або поганий драйвер від Windows Update.
• Контролери накопичувачів: Intel RST/VMD, NVMe‑драйвери, драйвери чипсету в неправильному порядку або перемикачі BIOS.
• Bluetooth/аудіоінтерфейси: застарілі пакети драйверів, зламані класові фільтри або невідповідність прошивки/кодеків.

Надійна стратегія виправлення звучить нудно: збирати докази, визначити інстанцію пристрою, читати потрібні журнали, а потім
або (1) виправити прив’язку драйвера, (2) видалити конфліктний фільтр, (3) виправити прошивку/живлення, або (4) визнати, що апарат виходить з ладу.

Одна перефразована ідея від Werner Vogels (CTO Amazon): Все ламається; проєктуйте і експлуатуйте так, ніби відмова — нормальний стан.
Код 10 — це настільна версія цієї філософії, тільки він ламається прямо перед вашою нарадою.

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

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

Перший крок: підтвердіть домен збою (перелічення vs драйвер vs політика)

1. Чи перелічується пристрій? Якщо він не показуєся з Hardware ID, ви в зоні живлення/порту/кабелю/прошивки.
2. Чи прив’язує Windows очікуваний драйвер? Якщо прив’язано загальний або неправильний драйвер постачальника — виправте прив’язку.
3. Чи зафіксував його фільтр‑драйвер? VPN, EDR, фільтр для накопичувача, аудіо‑поліпшення — фільтри часто стають «ще однією річчю», що ламає запуск.

Другий крок: перевірте журнали, де Windows «зізнається»

1. Журнали установки SetupAPI для рішень про співставлення/прив’язку.
2. Вкладка «Події» в Диспетчері пристроїв для деталей «Пристрій не запустився» і часових позначок.
3. Переглядач подій (Event Viewer) для збоїв завантаження драйверів/служб, скидань USB‑хаба і kernel PnP‑подій.

Третій крок: застосуйте найменшу зміну, що підлягає відкату

1. Відкат драйвера, якщо проблема почалася після оновлення.
2. Видаліть підозрілий пакет драйвера за допомогою інструментів сховища драйверів (не лише «Видалити пристрій» в Диспетчері).
3. Перевірка прошивки / BIOS тільки після розуміння поточного стану — зміни прошивки можуть або вирішити, або «подарувати» вам ще більші проблеми.

Жарт №1: Перезавантаження — не виправа; це зізнання, що у вас не було часу на налагодження.

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

• Коди помилок у Диспетчері пристроїв походять із ери Windows NT/2000, коли Plug and Play мав стати безпечним для підприємств.
• Журнали SetupAPI з давніх‑давен є авторитетним джерелом «чому Windows вибрав цей драйвер?» — ще з Windows 2000, задовго до того, як «телеметрія» стала звичним словом.
• Підписування драйверів ставало жорсткішим; на x64 Windows це було переломним моментом, який зменшив хаос і збільшив трафік звернень «чому мій старий драйвер не завантажується?».
• Доставка драйверів через Windows Update покращила підключення пристроїв для споживачів, але створила новий режим відмови: «компаньйон‑неправильний драйвер», що поширюється масово.
• USB selective suspend існує, щоб економити енергію, особливо на ноутбуках, але воно може виявити маргінальні кабелі, хаби і пристрої, які не витримують агресивних переходів живлення.
• NDIS‑фільтр‑драйвери (VPN, фаєрволи, EDR) за замовчуванням потужні: вони можуть перехоплювати трафік і також здатні креативно ламати ініціалізацію адаптера.
• Intel VMD/RST змінив спосіб подання NVMe‑пристроїв Windows; перемикання цього режиму в BIOS може зробити завантажувальний диск «зниклим», поки не існує відповідного драйвера контролера.
• Ключі реєстру Class filter (UpperFilters/LowerFilters) — історична точка розширення, яку використовували виробники; вони також часто спричиняють Code 10 і Code 19, коли стають застарілими.

Перевірені завдання: команди, вихід, рішення

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

Завдання 1 — Визначте інстанцію пристрою, що не працює (PnP entity)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Status Error | Select-Object -First 5 Status,Class,FriendlyName,InstanceId | Format-Table -Auto"
Status Class        FriendlyName                         InstanceId
------ -----        ------------                         ----------
Error  Net          Intel(R) Ethernet Connection (7)...  PCI\VEN_8086&DEV_15F3&SUBSYS_...
Error  USB          USB Composite Device                 USB\VID_0BDA&PID_5411\00A0C6...

Що це означає: Тепер у вас є InstanceId, який є опорою для всього: подій, прив’язки драйвера та стану в реєстрі.

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

Завдання 2 — Витягніть Hardware IDs (що використовує співставлення драйвера)

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_HardwareIds' | Select-Object -ExpandProperty Data"
PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03
PCI\VEN_8086&DEV_15F3&SUBSYS_00008086
PCI\VEN_8086&DEV_15F3&CC_020000

Що це означає: Hardware IDs — це істина, з якою Windows порівнює INFs. Якщо вони виглядають загальними або неправильними, можливо, ви маєте справу з іншим режимом (наприклад, RAID/VMD).

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

Завдання 3 — Перевірте, який драйвер фактично прив’язаний (і його INF)

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_DriverInfPath' | Select-Object -ExpandProperty Data"
oem42.inf

Що це означає: Драйвер встановлено з OEM‑INF в сховищі драйверів. Саме цей INF, можливо, треба видалити або замінити.

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

Завдання 4 — Перегляньте деталі пакета драйвера (постачальник, версія, дата)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | Select-String -Context 0,6 'Published Name\s*:\s*oem42.inf'"
Published Name : oem42.inf
Original Name  : e1d68x64.inf
Provider Name  : Intel
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 12/15/2024 2.1.4.0
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

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

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

Завдання 5 — Прочитайте деталі «Пристрій не запустився» з подій Диспетчера пристроїв через PowerShell

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Kernel-PnP/Configuration'; ID=411} -MaxEvents 20 | Where-Object {$_.Message -like \"*$id*\"} | Select-Object -First 1 TimeCreated,Message | Format-List"
TimeCreated : 2/4/2026 9:12:44 AM
Message     : Device PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03\3&11583659&0&FE had a problem starting.
              Driver Name: oem42.inf
              Class Guid: {4d36e972-e325-11ce-bfc1-08002be10318}
              Service: e1dexpress
              Problem: 0x0
              Problem Status: 0xC00000E5

Що це означає: «Problem Status» дає вам статусний код на рівні ядра. Це часто більш дієво, ніж сам Код 10.

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

Завдання 6 — Переконайтеся, що служба драйвера існує і запускається (або падає)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name e1dexpress | Format-List Name,Status,StartType"
Name      : e1dexpress
Status    : Stopped
StartType : Manual

Що це означає: Багато драйверів пристроїв — це служби ядра, які не виглядають як «Running» на кшталт веб‑сервера. «Stopped» не завжди погано — але це підказка.

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

Завдання 7 — Перевірте SetupAPI для реального рішення про прив’язку драйвера

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir'\inf\setupapi.dev.log' -Pattern 'PCI\\VEN_8086&DEV_15F3','oem42.inf','!    dvi: Device not started' -SimpleMatch | Select-Object -Last 12"
>>>  [Device Install (DiInstallDevice) - PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03]
>>>  Section start 2026/02/04 09:12:41.812
     dvi: Selected driver installs from section [E1DExpress.ndi.NTamd64.10.0] in "C:\WINDOWS\INF\oem42.inf".
     dvi: Driver Service Name: e1dexpress
!!!  dvi: Device not started: Device has problem: 0x0: 0xC00000E5
<<<  Section end 2026/02/04 09:12:45.120

Що це означає: SetupAPI точно каже, який розділ INF було вибрано і де сталося падіння під час старту. Тут теорія «Windows вибрав неправильний драйвер» перестає бути теорією.

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

Завдання 8 — Перелічіть встановлені пристрої в тому ж класі (знайдіть дублікати/привиди)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
Status Unknown  WAN Miniport (IP)                         ROOT\NET\0000
Status OK       Intel(R) Wi-Fi 6E AX211 160MHz            PCI\VEN_8086&DEV_51F0&SUBSYS_...
Status Error    Intel(R) Ethernet Connection (7)...       PCI\VEN_8086&DEV_15F3&SUBSYS_...

Що це означає: Ви бачите, чи лише один пристрій має помилку або весь клас веде себе дивно (що вказує на класові фільтри або політику).

Рішення: Якщо кілька пристроїв того самого класу падають після встановлення VPN/EDR, перевірте фільтр‑драйвери далі.

Завдання 9 — Перевірте NDIS‑фільтри (поширена причина Code 10 для NIC)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterBinding -Name '*' -ComponentID ms_tcpip,ms_lltdio,ms_rspndr,ms_pacer | Select-Object Name,ComponentID,Enabled | Format-Table -Auto"
Name                          ComponentID Enabled
----                          ----------- -------
Intel(R) Ethernet Connection  ms_tcpip    True
Intel(R) Ethernet Connection  ms_lltdio   True
Intel(R) Ethernet Connection  ms_rspndr   True
Intel(R) Ethernet Connection  ms_pacer    True

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

Рішення: Якщо бачите несподівані компоненти фільтрів (від VPN/EDR), тимчасово відключіть їх (за наявності дозволу на зміну контролю) і повторно протестуйте запуск пристрою.

Завдання 10 — Перелічіть проблеми контролера USB і хаба (для USB Code 10)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class USB | Where-Object {$_.Status -ne 'OK'} | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
Error USB Composite Device         USB\VID_0BDA&PID_5411\00A0C6...
Error Generic USB Hub              USB\VID_2109&PID_2817\5&2b3d...

Що це означає: Якщо хаби/контролери відмовляють, справа не в самому пристрої — ваша USB‑дерева має проблему.

Рішення: Перемістіть пристрій на інший порт/контролер (передній vs задній, USB‑C vs USB‑A), або відключіть док/хаб і тестуйте напряму.

Завдання 11 — Вимкніть USB selective suspend (цільовий тест, а не догма)

cr0x@server:~$ powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND_DISABLED
Power Setting Index value set.

Що це означає: Ви вимкнули selective suspend для живлення від мережі у поточній схемі. Це прибирає цілу категорію ненадійної поведінки при відновленні/ініціалізації.

Рішення: Якщо це вирішує Code 10 для USB‑пристроїв, ймовірно, у вас маргінальне апаратне забезпечення/прошивка (док, хаб, кабель) або проблемна прошивка пристрою. Вирішіть, чи тримати налаштування, чи замінити слабке місце.

Завдання 12 — Перебудуйте стек драйвера шляхом видалення пакета драйвера (реальне видалення)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /delete-driver oem42.inf /uninstall /force"
Microsoft PnP Utility

Driver package deleted successfully.

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

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

Завдання 13 — Примусове сканування апаратури (PnP пере‑перелічення)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /scan-devices"
Microsoft PnP Utility

Scanning for hardware changes...
Scan completed.

Що це означає: Windows повторно запускає виявлення і прив’язку. Якщо тепер він прив’яжеться до іншого INF, ви побачите це в SetupAPI.

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

Завдання 14 — Перевірте несподіванки диска/контролера (Code 10, пов’язані зі зберіганням)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class SCSIAdapter | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
OK    Intel(R) Volume Management Device NVMe RAID Controller   PCI\VEN_8086&DEV_9A0B&SUBSYS_...

Що це означає: Якщо ви очікували звичайний NVMe‑контролер, а бачите VMD/RST, то режим зберігання в BIOS має значення. Code 10 на накопичувачах часто з’являється після скидання BIOS або перемикання «для продуктивності».

Рішення: Не перемикайте режим зберігання в BIOS для завантажувального диска без підготовки. Переконайтеся, що правильний драйвер контролера встановлено перед зміною режимів, інакше ви поміняєте Code 10 на «немає завантаження».

Завдання 15 — Перевірте UpperFilters/LowerFilters (класична точка поломки)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}' /v UpperFilters"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}
    UpperFilters    REG_MULTI_SZ    edrNdisflt

Що це означає: Клас‑широкий фільтр приєднано до всіх мережевих карт. Якщо цей фільтр зламаний або частково видалений, адаптери можуть не запуститися (привіт, Код 10).

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

Завдання 16 — Перевірте, чи Windows вважає, що пристрій присутній, але «має проблему»

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_ProblemCode','DEVPKEY_Device_ProblemStatus' | Format-Table KeyName,Data -Auto"
KeyName                     Data
-------                     ----
DEVPKEY_Device_ProblemCode  10
DEVPKEY_Device_ProblemStatus 3221225701

Що це означає: Ви можете зафіксувати точні числові значення, які ОС використовує — це допомагає зіставляти по журналах і інцидентах.

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

Жарт №2: USB‑C доки — це корпоративний еквівалент несподіваної залежності: ви його не розгорнули, але він точно у вашому критичному шляху.

Три корпоративні історії з польових боїв

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

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

IT міняли доки. Та сама проблема. Поміняли Ethernet‑кабелі. Та сама проблема. Переінсталювали один ноутбук. Працював годину, потім знову впав.
Тим часом офісний Wi‑Fi був перевантажений, бо половина команди одночасно втратила дротовий доступ.

Справжня відмова була в припущенні, що NIC дока — «проблема дока». Ні. Оновлення VPN‑клієнта встановило NDIS‑фільтр.
На машинах, де NIC дока перелічувався перед Wi‑Fi під час завантаження, фільтр приєднувався під час ініціалізації адаптера і іноді викликав дедлок шляху старту.
Код 10 був симптомом; корінь — фільтр‑драйвер.

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

Міні‑історія 2: «Оптимізація», що зіграла злий жарт

Інженерна організація хотіла швидше завантаження і кращу автономність. Внутрішній гайд рекомендував агресивні налаштування живлення:
увімкнути modern standby, залишити USB selective suspend, і дозволити Windows агресивно керувати живленням пристроїв.
У загальному такий підхід не був неправильним. Він був неправильним у конкретному випадку.

Частина користувачів покладалася на певний USB‑аудіоінтерфейс для дзвінків. Після оновлення Windows ці пристрої почали кидати Code 10
після відновлення з режиму сну. Перепідключення іноді допомагало. Вимикання й увімкнення пристрою іноді допомагало. Реальна проблема була в інтермітентному таймінгу відновлення:
прошивка аудіопристрою не любила, коли хаб теж переходив у інший стан живлення.

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

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

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

Фінансовий відділ мав приклад програми, яка залежала від апаратного захисного донгла. Одного понеділка після оновлень донгли на кількох робочих станціях
почали відмовляти з Кодом 10. Настала паніка, бо «аудитори йдуть» — це закон природи.

Десктоп‑команда мала одну непопулярну звичку: вести невеликий внутрішній каталог «перевірених пакетів драйверів» і записувати, які імена OEM INF
використовуються для критичних пристроїв. Також був суворий принцип: не покладатися на Windows Update для цього класу пристроїв; пакувати драйвер у їхній інструмент управління.

Коли з’явився Код 10, вони не гадали. Порівняли прив’язки oem*.inf на проблемних машинах з каталогом.
І справді: Windows Update замінила драйвер донгла новішим пакетом, який заявляв сумісність, але змінив поведінку ініціалізації.

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

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

1) «Код 10 на USB‑пристрої, але він працює на іншому ПК»

• Симптом: Пристрій падає на одній машині, ок на іншій; іноді працює після перепідключення.
• Корінна причина: Крайній випадок управління живленням (selective suspend), ненадійна прошивка хаба/дока або порт/контролер цієї машини працює інакше.
• Виправлення: Тестуйте на прямому порту (без хаба), вимкніть selective suspend для діагностики, оновіть прошивку дока, уникайте фронтальних портів на десктопах, якщо довжина кабелю маргінальна.

2) «Код 10 після Windows Update; драйвер каже, що він останній»

• Симптом: Раптовий злам після патчу; Диспетчер пристроїв наполягає, що нового драйвера немає.
• Корінна причина: Windows Update доставив «новіший» драйвер, який гірший для вашої ревізії апаратури/прошивки.
• Виправлення: Відкат, потім видалення проблемного oem*.inf зі сховища драйверів і установка схваленого OEM‑пакета. Розгляньте блокування цього оновлення.

3) «Мережева карта показує Код 10 тільки коли встановлено VPN/EDR»

• Симптом: Адаптер не запускається або зникає; перевстановлення драйвера NIC не допомагає.
• Корінна причина: Конфлікт NDIS‑фільтра або застарілі записи UpperFilters/LowerFilters після часткового видалення.
• Виправлення: Відновіть або чисто перевстановіть VPN/EDR. Якщо потрібно, видаліть застарілі записи фільтрів з планом відкату та офлайн‑доступом.

4) «Контролер зберігання показує Код 10 після оновлення/скидання BIOS»

• Симптом: NVMe/RAID‑контролер показує Код 10; іноді Windows ще завантажується, але продуктивність падає або диски зникають.
• Корінна причина: BIOS перемкнув VMD/RST режим, змінив мапінг PCIe ліній або скинув налаштування за замовчуванням без відповідного стеку драйверів.
• Виправлення: Відновіть попередній режим зберігання або встановіть правильний драйвер контролера перед зміною режимів. Розглядайте це як міграцію, а не перемикач.

5) «Bluetooth Код 10 після сну/глибокого сну»

• Симптом: Bluetooth‑адаптер не працює після відновлення; перезавантаження тимчасово вирішує проблему.
• Корінна причина: Баг перехідних станів прошивки/драйвера, іноді спрацьовує через Fast Startup/глибокий режим сну.
• Виправлення: Оновіть Bluetooth і драйвери чипсету, протестуйте вимкнення Fast Startup і перевірте, чи адаптер підключений через внутрішній USB‑хаб із власними проблемами.

6) «Аудіопристрій показує Код 10 з увімкненими «поліпшеннями»»

• Симптом: Зовнішній аудіоінтерфейс не працює; внутрішні динаміки працюють.
• Корінна причина: Шар розширень постачальника або невідповідність APO після оновлення.
• Виправлення: Перевстановіть правильний пакет аудіо‑драйверів; тимчасово вимкніть поліпшення; видаліть застарілі аудіо‑фільтри, якщо вони ідентифіковані.

7) «Видалення пристрою не допомогло»

• Симптом: Ви видаляєте в Диспетчері пристроїв, перезавантажуєте, і він повертається з тією ж проблемою.
• Корінна причина: Пакет драйвера залишається в сховищі драйверів, тому Windows знову прив’язує той самий INF одразу.
• Виправлення: Використайте pnputil /delete-driver oemXX.inf /uninstall, щоб видалити пакет, потім проскануйте і встановіть перевірений.

8) «Пристрій показує Код 10 та Код 43 на різних завантаженнях»

• Симптом: Коди помилок змінюються; поведінка залежить від часу завантаження/відновлення.
• Корінна причина: Маргінальне апаратне з’єднання, нестабільність живлення або умови гонки прошивки (поширено для доків/хабів).
• Виправлення: Усуньте проміжні пристрої, оновіть прошивку, вимкніть агресивні переходи живлення та замініть сумнівні кабелі/хаби.

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

Покроковий план для однієї машини (версія «не погіршувати стан»)

1. Зафіксуйте стан: інстанція пристрою, Hardware IDs, INF драйвера, версія драйвера та часову мітку, коли він востаннє працював.
2. Підтвердіть масштаб: це один пристрій, весь клас (USB/Net) чи кілька пристроїв відмовляють одночасно?
3. Перевірте події: журнали Kernel‑PnP configuration та події Диспетчера пристроїв для «Device not started» і статусних кодів.
4. Прочитайте SetupAPI: знайдіть розділ інсталяції і чому Windows вибрав цей драйвер.
5. Спробуйте найменшу зміну, що підлягає відкату:
   • Відкат драйвера, якщо нещодавно оновлювалися.
   • Вимкнення selective suspend (USB) для діагностики.
   • Видалення стороннього компоненту фільтра, якщо він явно причетний (віддавайте перевагу ремонту/деінсталяції продукту, а не редагуванню реєстру).
6. Виконайте реальний скидання драйвера: видаліть пакет драйвера зі сховища драйверів, якщо потрібно, і потім проскануйте.
7. Встановіть перевірені драйвери в правильному порядку: спочатку чипсет, потім драйвери контролерів (storage/USB), потім специфічні драйвери пристроїв.
8. Лише потім торкайтеся прошивки: оновлюйте BIOS/прошивку дока/пристрою з урахуванням стабільності живлення і нотатками для відкату.
9. Перевірте холодне завантаження і відновлення: деякі помилки Code 10 проявляються лише після сну/гібернації.

Чек‑лист для флоту (коли Code 10 раптово «усюди»)

1. Припиніть хаотичні виправлення: один інженер, що «вирішує» проблему вручну, може створити проблеми з даними для аналізу.
2. Виберіть 3 тестові машини: різні ревізії апаратури, якщо можливо, і одну контрольну машину без проблем.
3. Зафіксуйте відмінності сховища драйверів: визначте, які oem*.inf змінилися і корелюйте з кільцем оновлень.
4. Перевірте спільне ПЗ‑фільтр: VPN, EDR, DLP, аудіо‑світи — все, що вставляється в стек.
5. Розгорніть детерміноване виправлення: фіксація пакета драйвера, ремонт фільтра або цільова зміна налаштувань живлення.
6. Вимірюйте повторюваність: якщо «переважно» працює — вважайте це не виправленим. Code 10 любить переривчасті відмови.

Якщо ви мусите робити зміни в реєстрі

Іноді застряглий запис UpperFilters/LowerFilters не лишає альтернатив. Якщо робити це:
зробіть повний експорт реєстру відповідного ключа, упевніться, що маєте офлайн‑доступ (локальний адміністратор, out‑of‑band або безпечний режим),
і знайте, як відновити підключення, якщо зламаєте мережевий стек.

Поширені питання

1) Чи завжди Код 10 — проблема драйвера?

Ні. Часто це проблема прив’язки драйвера або помилка ініціалізації, але це може бути живлення, прошивка або пристрій, що ніколи правильно не перелічився.
Якщо немає стабільного Hardware ID, перестаньте звинувачувати драйвери і почніть перевірку портів, хабів, BIOS та станів живлення.

2) Чому «Оновити драйвер» у Диспетчері пристроїв так рідко допомагає?

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

3) У чому різниця між «Видалити пристрій» і видаленням пакета драйвера?

Видалення пристрою прибирає інстанцію пристрою. Видалення пакета драйвера видаляє INF і бінарники зі сховища драйверів.
Якщо ви не видалите пакет, Windows може перевстановити той самий проблемний драйвер при наступному скані.

4) Як зрозуміти, чи VPN або EDR спричинили Код 10 на NIC?

Перевірте наявність NDIS‑фільтр-компонентів, подивіться UpperFilters для GUID класу мережі і корелюйте час появи проблеми з інсталяцією/оновленням цього ПЗ.
Якщо декілька адаптерів падають (Ethernet і Wi‑Fi), фільтри повинні бути у верхній частині вашого списку підозр.

5) Чи може оновлення BIOS спричинити Код 10?

Так. BIOS може скинути налаштування, змінити режим пристрою або порядок перерахування. Режими зберігання (VMD/RST/AHCI) особливо чутливі.
Ставтесь до змін BIOS як до інфраструктурних: плануйте, перевіряйте і майте можливість відкату.

6) Чому пристрій працює після перезавантаження, але падає після сну?

Сон/відновлення проганяють інші стани живлення, ніж холодний старт. Пристрої і хаби, які переживають завантаження, можуть все одно не пройти ініціалізацію при відновленні.
Тестуйте з вимкненим selective suspend і оцінюйте прошивку дока/хаба та поведінку живлення.

7) Чи є Код 10 ознакою того, що апарат помер?

Іноді. Якщо пристрій відмовляє на різних портах, на різних машинах, і журнали показують повторні помилки перерахування, апарат — реальна можливість.
Але не списуйте апарат, поки не усунете прив’язку драйвера, фільтри і управління живленням.

8) Чи варто використовувати сторонні «оновлювачі драйверів»?

Ні. У корпоративних умовах це рулетка ланцюга постачання. Вони можуть встановити невідповідні драйвери, додати фільтри і створити нові режими відмов.
Користуйтеся каналами OEM або кураторськими внутрішніми пакетами.

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

Не дергайтеся. Завантажтеся з recovery‑медіа, підтвердіть режим зберігання в BIOS і переконайтеся, що потрібний драйвер контролера доступний.
Випадкові перемикання можуть зробити ОС незавантажуваною, змінивши ідентичність контролера, яку очікує система.

10) Коли «Відновлення системи» — розумний крок?

Коли у вас є вагомі докази, що злам пов’язаний з нещодавнім драйвером або оновленням ПЗ, і потрібен швидкий відкат.
Це не витончений підхід, але може бути контрольованим відкатом, якщо ви зафіксуєте, що змінилося після нього.

Висновок: наступні кроки, що працюють

Код 10 — це повідомлення Windows «угода запуску порушена». Найшвидший вихід — перестати гадати і допитати стек:
перелічіть пристрій, підтвердіть прив’язку драйвера, прочитайте SetupAPI, перевірте фільтри, а потім робіть одну відкатну зміну за раз.

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

1. На наступній машині з Кодом 10 зафіксуйте InstanceId + Hardware IDs + Driver INF перед будь‑якими діями.
2. Використайте SetupAPI, щоб підтвердити, що Windows вибрав і чому.
3. Якщо видалення пристрою не допомагає, видаліть реальний пакет драйвера за допомогою pnputil.
4. Якщо відмови корелюють з VPN/EDR — розглядайте фільтри як першу групу підозри і ремонтуйте через правильну інсталяцію продукту.
5. Для проблем USB/дока тестуйте пряме підключення, налаштування живлення і прошивку — потім замініть найслабше ланку замість того, щоб сперечатися з нею.

Мета не «змусити проблему зникнути». Мета — зробити відмову зрозумілою, відтворюваною і попереджуваною.
Так ви перетворюєте пожежну тривогу Code 10 на рутинну технічну задачу — тиху, задокументовану і трохи горду.