«Невідомий пристрій» у Диспетчері пристроїв? Визначте за 60 секунд

Що насправді означає «Невідомий пристрій» (і чого це не означає)

Диспетчер пристроїв маркує дещо як Невідомий пристрій, коли Windows «бачить» щось на шині (PCI, USB, ACPI, Bluetooth тощо), але не може зіставити це зі стосом драйверів, придатних для використання. Це може означати:

• Драйвер не встановлено (класичний випадок Code 28).
• Встановлено невірний драйвер (зв’язується, але не запускається, часто Code 10).
• Пристрій вимкнено в BIOS/UEFI або сховано налаштуваннями управління живленням платформи.
• Пристрій насправді «програмний», описаний через ACPI (контролери батареї, гарячі клавіші, сенсори, інтерфейси TPM, Intel ME, AMD PSP тощо).
• Драйвер є, але його блокує підпис/політика (особливо при Secure Boot, HVCI/Memory Integrity або корпоративній політиці).
• Пристрій має електричну несправність (рідко, але трапляється; «Невідомий» може бути симптомом збоїв навчання лінку або нестабільного USB).

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

Думка з досвідом: не починайте з випадкових наборів драйверів або сторонніх «updater»‑утиліт. Вони дають короткочасну втіху, але довгостроковий хаос. Якщо ви відповідаєте за надійність парку, вам потрібна детермінованість: ідентифікуйте за Hardware IDs, знайдіть правильний драйвер від вендора та зафіксуйте зроблене.

Цитата, бо досі правдива: «Надія — це не стратегія.» — General Gordon R. Sullivan

Ще: коли пристрій «невідомий», ви не шукаєте назву. Ви шукаєте сталий ідентифікатор (Hardware ID) і шлях рішення: встановити чіпсет, встановити правильний драйвер функції, оновити BIOS або замінити апарат.

Жарт №1: «Невідомий пристрій» — це спосіб Windows сказати: «Я щось знайшов, але поки що не готовий брати на себе емоційну відповідальність.»

Швидкий план діагностики (60 секунд, без здогадок)

Ось послідовність, яку я використовую на живій системі, коли потрібна швидка відповідь, а не теорія. Мета: визначити: тип шини → Hardware ID → ймовірна сім’я драйверів → джерело встановлення.

Спершу: отримаємо Hardware IDs (10–20 секунд)

1. Відкрийте Диспетчер пристроїв → правий клік на Невідомому пристрої → Властивості.
2. Вкладка Деталі → Властивість: Hardware Ids.
3. Скопіюйте перший рядок (найточніший).

Якщо починається з:
PCI\VEN_ → це PCI/PCIe (чіпсет, контролер зберігання, мережевий контролер тощо).
USB\VID_ → це USB (док‑станція, Bluetooth, кардрідер, сенсор тощо).
ACPI\ → це описане прошивкою (живлення, гарячі клавіші, менеджмент движка, сенсори).
HID\ → це пристрій користувацького інтерфейсу (тачпад, спеціальні клавіші, сенсор).

Друге: прочитайте код помилки і статус (10 секунд)

У тому самому вікні Властивостей → вкладка Загальні. Зверніть увагу на статус і код:

• Code 28: драйвер не встановлено. Потрібен правильний INF.
• Code 10: пристрій не зміг запуститися. Часто невірний драйвер, відсутня залежність, проблема з прошивкою або живленням.
• Code 43: пристрій повідомив про проблему. Часто трапляється при нестабільному USB або збоях драйверів GPU.

Третє: вирішіть, до якої категорії ви належите (20–30 секунд)

• Свіжа інсталяція ОС і багато невідомих пристроїв? Встановіть спочатку чіпсет та платформні драйвери (Intel/AMD chipset, ME/PSP, SMBus, Serial IO тощо).
• Один невідомий пристрій після зміни? Подумайте, що змінилося: оновлення BIOS, док, USB‑периферія, драйвери віртуалізації, режим контролера зберігання, BitLocker.
• Серверна платформа? Віддавайте перевагу OEM‑пакетам драйверів і базовим прошивкам; Windows Update не є планом життєвого циклу.

Що ви шукаєте — «вузьке місце»

Більшість невідомих пристроїв не є екзотичними. Це відсутні перекладачі шини та платформні драйвери — INF чіпсету, ACPI‑пристрої та менеджмент‑контролери. Якщо встановити їх першими, половина жовтих трикутників зникне без драм.

Цікавинки та коротка історія (чому Windows опиняється тут)

• Факт 1: «Plug and Play» з’явився у масових версіях Windows у середині 1990‑х, і досі це переговори між прошивкою, шинами й INF‑файлами драйверів — не магія.
• Факт 2: PCI‑пристрої ідентифікуються через Vendor ID і Device ID (VEN/DEV). Windows використовує їх для співставлення з INF. Немає співпадіння — немає драйвера.
• Факт 3: USB‑пристрої аналогічно ідентифікуються через VID і PID, плюс коди класу. «Універсальний» класовий драйвер може працювати — якщо пристрій не потребує специфічного драйвера вендора.
• Факт 4: ACPI (Advanced Configuration and Power Interface) — причина, чому ноутбуки показують багато «пристріїв», що не є фізичними периферіями: термозони, кнопки, сенсори, інтерфейси управління живленням.
• Факт 5: Багато «невідомих пристроїв» на сучасних системах — це платформні контролери: SMBus, I2C, Serial IO, GPIO та менеджмент‑движки. Без драйверів чіпсету вони виглядають як нісенітниця.
• Факт 6: Windows веде детальний журнал інсталяції та рішень при співставленні драйверів у SetupAPI; це фактично «чорний ящик» для PnP.
• Факт 7: Політика підпису драйверів посилилася з часом. Драйвер, що «працював минулого року», може бути заблокований після змін політик чи параметрів безпеки.
• Факт 8: «Code 28» — нудний і дружній: ОС каже «драйвер не встановлено». «Code 10» — той, що краде вечори.
• Факт 9: Контролери зберігання особливі: якщо обрати невірний драйвер або режим (AHCI/RAID/NVMe), можна перетворити завантажувальну систему на не завантажувальну одним перезавантаженням.

Практичні завдання: 12+ команд для ідентифікації пристрою та прийняття рішення

Це практичні завдання, які я справді використовую. Кожне містить: команду, реалістичний вивід, що це означає, і яке рішення прийняти. Я використовую команди Windows, але формат рядка shell для узгодженості. Запускайте їх у підвищеному PowerShell або CMD, де зазначено.

Завдання 1: Швидко перелічити проблемні пристрої (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object {$_.Status -ne 'OK'} | Select-Object Status,Class,FriendlyName,InstanceId | Format-Table -Auto"
Status  Class        FriendlyName       InstanceId
Error   Unknown      Unknown device     ACPI\VEN_INT&DEV_34C5\3&11583659&0
Error   Net          Ethernet Controller PCI\VEN_10EC&DEV_8168&SUBSYS_01231025&REV_15\01000000684CE00000

Що це означає: Ви бачите пристрої, які присутні і не в статусі OK, включно з InstanceId (ключова інформація).

Рішення: Скопіюйте InstanceId. Якщо є кілька проблем, спочатку виправляйте чіпсет/платформу; NIC/audio/card reader часто залежать від цього.

Завдання 2: Отримати Hardware IDs для конкретного екземпляра пристрою

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDeviceProperty -InstanceId 'PCI\VEN_10EC&DEV_8168&SUBSYS_01231025&REV_15\01000000684CE00000' -KeyName 'DEVPKEY_Device_HardwareIds' | Select-Object -ExpandProperty Data"
PCI\VEN_10EC&DEV_8168&SUBSYS_01231025&REV_15
PCI\VEN_10EC&DEV_8168&SUBSYS_01231025
PCI\VEN_10EC&DEV_8168&CC_020000
PCI\VEN_10EC&DEV_8168&CC_0200

Що це означає: Hardware IDs стають менш специфічними вниз по списку. Перший рядок зазвичай найкращий для підбору драйвера.

Рішення: Використовуйте найточніший ID, щоб знайти правильний драйвер OEM або вендора. Для PCI‑пристроїв VEN/DEV показують виробника та сімейство чіпа.

Завдання 3: Ідентифікувати невідомі USB за VID/PID

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class USB -PresentOnly | Select-Object FriendlyName,InstanceId | Format-Table -Auto"
FriendlyName                  InstanceId
USB Composite Device           USB\VID_0BDA&PID_5411\00E04C680001
Unknown USB Device (Port Reset Failed) USB\VID_0000&PID_0002\5&2B1B8B0&0&2

Що це означає: VID_0000/PID_0002 зазвичай не є «реальною» ідентифікацією пристрою; це невдала перерахунковість.

Рішення: Для реальних VID/PID знайдіть драйвер. Для випадків з VID_0000 підозрюйте кабель/док/живлення, прошивку концентратора або мертвий порт.

Завдання 4: Використати pnputil для переліку встановлених драйверів (driver store)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem12.inf
Original Name  : netrtx64.inf
Provider Name  : Realtek
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 10/21/2022 116.0.0.0
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

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

Рішення: Якщо бракує пакетів чіпсету/ACPI — встановіть їх. Якщо вони є, але не зв’язуються — перевірте підтримувані IDs у INF (наступні завдання).

Завдання 5: Примусово додати відомий пакет драйверів у сховище

cr0x@server:~$ pnputil /add-driver "C:\Drivers\Chipset\*.inf" /subdirs /install
Processing inf : C:\Drivers\Chipset\iaLPSS2_GPIO2.inf
Driver package added successfully.
Published Name : oem42.inf
Driver package installed on matching devices.

Що це означає: Ви додали INF‑файли чіпсету/платформи і Windows зв’язав їх з пристроями.

Рішення: Перевірте Диспетчер пристроїв / Get-PnpDevice. Якщо невідомі зникли — вам просто бракувало платформних драйверів. Якщо ні — продовжуйте розбиратися з рештою IDs.

Завдання 6: Дізнатися, до якого драйвера прив’язано пристрій

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDeviceProperty -InstanceId 'PCI\VEN_10EC&DEV_8168&SUBSYS_01231025&REV_15\01000000684CE00000' -KeyName 'DEVPKEY_Device_DriverInfPath','DEVPKEY_Device_DriverProvider','DEVPKEY_Device_DriverVersion' | Format-List"
Data : oem12.inf

Data : Realtek

Data : 10/21/2022 116.0.0.0

Що це означає: У вас є точний INF‑пакет у грі.

Рішення: Якщо пристрій все ще падає (Code 10/43), можна відкотити/оновити саме цей драйвер замість хаотичного «перевстановлювання всього».

Завдання 7: Прочитати журнал інсталяції SetupAPI навколо помилки

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path 'C:\Windows\INF\setupapi.dev.log' -Pattern 'PCI\\VEN_10EC&DEV_8168' -Context 2,6 | Select-Object -First 1"
>>>  [Device Install (Hardware initiated) - PCI\VEN_10EC&DEV_8168&SUBSYS_01231025&REV_15]
>>>  Section start 2026/02/04 10:21:14.312
     cmd: "C:\Windows\system32\svchost.exe" -k DcomLaunch -p
     dvi: Searching for hardware ID(s):
     dvi:      pci\ven_10ec&dev_8168&subsys_01231025&rev_15
     dvi: Selected driver installs from section [RTL8168.ndi] in "C:\Windows\INF\oem12.inf".

Що це означає: Windows показує, що шукало, що обрало і з якої секції INF.

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

Завдання 8: Опитати коди помилок Диспетчера через CIM/WMI

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPEntity | Where-Object {$_.ConfigManagerErrorCode -ne 0} | Select-Object Name,PNPDeviceID,ConfigManagerErrorCode | Format-Table -Auto"
Name                                   PNPDeviceID                                            ConfigManagerErrorCode
Unknown device                          ACPI\VEN_INT&DEV_34C5\3&11583659&0                     28
Standard NVM Express Controller          PCI\VEN_144D&DEV_A808&SUBSYS_A801144D&REV_00\4&...    10

Що це означає: 28 — відсутній драйвер. 10 — пристрій не стартує.

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

Завдання 9: Перевірити контролери зберігання та диски (бо інциденти з дисками — назавжди)

cr0x@server:~$ powershell -NoProfile -Command "Get-StorageController | Format-Table -Auto"
FriendlyName                     Manufacturer           Version
Standard SATA AHCI Controller     Standard              10.0.22621.1
Standard NVM Express Controller   Standard              10.0.22621.1

Що це означає: Ви на inbox‑драйверах Microsoft. Часто це нормально, іноді — ні, особливо для корпоративних NVMe або RAID HBA.

Рішення: Якщо невідомий пристрій ймовірно пов’язаний із зберіганням (PCI клас 0106/0108/0104), віддавайте перевагу драйверам OEM або вендора контролера, валідуваним для вашої платформи, плюс узгодженій прошивці.

Завдання 10: Підтвердити, чи це ACPI‑платформні речі (поширено на ноутбуках)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPEntity | Where-Object {$_.PNPDeviceID -like 'ACPI*' -and $_.ConfigManagerErrorCode -ne 0} | Select-Object Name,PNPDeviceID,ConfigManagerErrorCode | Format-Table -Auto"
Name            PNPDeviceID                              ConfigManagerErrorCode
Unknown device  ACPI\VEN_INT&DEV_34C5\3&11583659&0       28
Unknown device  ACPI\PNP0C14\2&DABA3FF&0                  28

Що це означає: ACPI\PNP0C14 часто — «WMI Event» пристрій; утиліти вендора іноді постачають драйвер для цього. ACPI\VEN_INT&DEV_* зазвичай вказує на Intel‑платформні компоненти.

Рішення: Встановіть OEM‑пакет платформних/ACPI драйверів (чіпсет + Serial IO + MEI для Intel; чіпсет + PSP + GPIO/I2C для AMD). Не намагайтесь використовувати випадкові сторонні INF.

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

cr0x@server:~$ dism /image:D:\ /add-driver /driver:E:\Drivers\Storage\ /recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Installing 1 of 3 - E:\Drivers\Storage\iaStorVD.inf: The driver package was successfully installed.
The operation completed successfully.

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

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

Завдання 12: Перевірити журнали подій Windows щодо помилок DeviceSetupManager

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-DeviceSetupManager/Admin -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
2/4/2026 10:22:01 AM 200 Information      Device install requested for 'PCI\VEN_10EC&DEV_8168...'
2/4/2026 10:22:03 AM 201 Error            Device install failed. Error: 0x80070103

Що це означає: DeviceSetupManager повідомляє, що Windows намагалася (можливо через Windows Update) і зазнала невдачі. 0x80070103 часто означає «драйвер не кращий за той, що вже встановлений» або дивне рішення підбору драйвера.

Рішення: Перестаньте очікувати, що Windows Update вирішить платформ‑специфічні драйвери. Використовуйте OEM‑перевірені пакети та забезпечте коректне співставлення.

Завдання 13: Чисто видалити неправильний пакет драйверів (коли невірний INF переміг)

cr0x@server:~$ pnputil /delete-driver oem99.inf /uninstall /force
Driver package deleted successfully.

Що це означає: Ви видалили OEM‑INF і відв’язали його від пристроїв.

Рішення: Робіть це лише після підтвердження, що пакет був невірно прив’язаний або спричиняв Code 10/43. Потім негайно встановіть коректний драйвер, щоб не залишити пристрої в пошкодженому стані.

Завдання 14: Перевірити, чи пристрій приховано або вимкнено

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.FriendlyName -like '*Unknown*'} | Select-Object FriendlyName,Status,Problem,Present,InstanceId | Format-List"
FriendlyName : Unknown device
Status       : Error
Problem      : 28
Present      : True
InstanceId   : ACPI\VEN_INT&DEV_34C5\3&11583659&0

Що це означає: Present=True означає, що пристрій справді перелічується, а не «привид». Problem=28 — простий випадок відсутнього драйвера.

Рішення: Не витрачайте час на пошуки «фантомів». Цей пристрій існує і потребує драйвера або налаштування BIOS/UEFI для коректного виставлення інтерфейсу.

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

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

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

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

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

Через два тижні VPN‑клієнт почав падати при відновленні зі сну для тих самих машин. Не завжди — але часто. Корінь не в VPN. «Невідомий пристрій» виявився інтерфейсом управління живленням платформи (ACPI), а універсальний пакет встановив невірний компонент живлення. Він не вбивав систему, але ламав рукопотискання сон/пробудження, внаслідок чого мережеві адаптери опинялися в дивному стані.

Вони відкотилися до OEM‑чіпсетних/платформних пакетів, сумісних з моделлю ноутбука, і VPN‑помилки зникли. Висновок: неправильне припущення було не «це сенсор». Воно було «якщо Диспетчер пристроїв чистий, стек правильний». Чисто ≠ правильно. Чисто іноді просто тихо.

Міні‑історія 2: Оптимізація, що обернулась проти

Інша команда, Windows‑орієнтована інженерна організація зі строгими часами збірки. Час іміджу був занадто довгим, отже десктоп‑команда «оптимізувала», вирізавши драйвери з базового образу та плануючи, що Windows Update дістане все під час першого запуску. На папері — елегантно: невеликий образ, швидке розгортання, решта — хмара.

У офісі з хорошим інтернетом це працювало. У захищених лабораторіях з обмеженим виходом — провал. Системи піднімалися з невідомими пристроями для контролерів зберігання і USB‑хабів, деякі периферії не працювали, техи підключали інші доки — і з’являлося ще більше невідомих пристроїв. Хаос заміщенням.

Найгірше: частина машин мала контролер зберігання, який поводився нормально на inbox‑драйвері, але при інтенсивному I/O почав логувати ресети. Не катастрофа, але достатньо, щоб коруптувати великі збірки час від часу. Налагодження зайняло дні, бо симптом був «нестабільні артефакти збірки», а не «несумісний драйвер контролера».

Фікс був нудний: відновити кураторований драйверний базовий набір у образі — чіпсет, зберігання, NIC та платформа — і потім дозволити Windows Update для довгого хвоста. Час іміджу трохи виріс. Частота інцидентів впала значно. Оптимізація — хороша річ, але лише коли ви зрозуміли, для чого оптимізуєте. «Швидше розгортання» ≠ «менше невідомих змінних».

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

Фінансова фірма тримала Windows‑сервери для вендорського застосунку, який вимагав фізичні хости. Їхня SRE‑команда ставилася до цього як до будь‑якої продуктивної системи: стандартизовані образи, контрольовані драйвери і строгий матрикс сумісності прошивки/драйверів, який вели люди з відмінною дисципліною змін.

Після планового вікна обслуговування один хост повернувся з Unknown device і Code 10 на функції контролера зберігання PCI. Зміна мала бути рутиною: оновлення BIOS плюс невелике оновлення драйвера. Більшість команд почали б перевстановлення довільних компонентів, поки повідомлення не зникне.

Ця команда зробила нешиковну річ: порівняла машину з базою. Вони перевірили точний INF, прив’язаний до контролера, співставили версії прошивки і переглянули SetupAPI‑журнали, щоб побачити, який INF обрали. Виявилось, що Windows перемапила пристрій на inbox‑драйвер після оновлення BIOS, бо змінився reported subsystem ID.

Оскільки у них був контрольований репозиторій драйверів і документований відкат, фікс був хірургічним: встановити правильну версію OEM‑драйвера, що відповідала новому subsystem ID, перевірити прив’язку, валідувати I/O під навантаженням і продовжити роботи. Просто в межах вікна обслуговування. Без героїв. Без Slack‑воєн з 27 учасниками і одного, хто вночі перезавантажував сервери.

Мораль нудна, але правильна: найкраща відповідь на інцидент — це надійна база і журнали, які ви справді читаєте.

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

1) «Невідомий пристрій» після свіжої установки Windows на ноутбуці

Симптом: Кілька невідомих пристроїв, відсутній SMBus контролер, можливі відсутні функції тачпада.

Корінь: Чіпсетні та платформні драйвери не встановлені. Inbox‑драйвери Windows не покривають усе, особливо ACPI/I2C/GPIO стек.

Виправлення: Встановіть OEM‑чіпсет + Serial IO/I2C + management engine/PSP пакети першими. Потім audio, графіку, Wi‑Fi, Bluetooth.

2) Невідомий USB‑пристрій з VID_0000&PID_0002

Симптом: «Unknown USB Device (Device Descriptor Request Failed)» або «Port Reset Failed».

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

Виправлення: Спробуйте інший порт, приберіть проміжні хаби, оновіть прошивку дока, тимчасово відключіть USB selective suspend для тесту і перевірте журнали на повторні підключення/відключення. Якщо проблема йде разом з периферією — замініть її.

3) Code 28 лишається після встановлення драйвера

Симптом: Ви запустили інсталятор, але пристрій залишається невідомим з Code 28.

Корінь: Пакет драйвера не містить INF, що відповідає вашому Hardware ID (часто з «достатньо близькими» драйверами), або інсталятор аварійно завершився.

Виправлення: Використайте Hardware IDs і перевірте підтримувані IDs у INF. Використайте pnputil /add-driver з /install, потім підтвердіть прив’язку через Get-PnpDeviceProperty DriverInfPath.

4) Code 10 після «виправлення» невідомого пристрою

Симптом: Пристрій тепер має ім’я, але «This device cannot start. (Code 10)».

Корінь: Невірна прив’язка драйвера, відсутня залежність (чіпсет) або невідповідність прошивки/BIOS.

Виправлення: Перегляньте SetupAPI‑журнали для вибору. Видаліть невірний INF (pnputil /delete-driver), встановіть коректну OEM‑версію і оновіть прошивку, якщо це вимагає вендор.

5) Невідомий пристрій з’являється лише при докуванні

Симптом: Ноутбук без дока чистий; док додає невідомі пристрої.

Корінь: Док відкриває USB‑Ethernet, аудіокодек або USB‑хаб, які потребують драйвера/прошивки вендора; іноді — політика Thunderbolt.

Виправлення: Встановіть пакет драйверів дока і оновіть прошивку дока. Якщо задіяно Thunderbolt, перевірте налаштування безпеки BIOS і списки дозволених пристроїв.

6) Невідомий пристрій після оновлення BIOS/UEFI

Симптом: Раптово з’явився новий невідомий ACPI або PCI‑пристрій, або змінилася прив’язка.

Корінь: BIOS оновлення змінило ACPI‑таблиці або subsystem IDs; Windows бачить «новий» екземпляр пристрою, що потребує відповідного драйвера.

Виправлення: Перевстановіть OEM‑пакети платформи, сумісні з тією версією BIOS. Перевірте екземпляр пристрою і прив’язку драйвера; не припускайте, що старі пакети все ще підходять.

7) Контролер зберігання «невідомий» або Code 10 на серверному обладнанні

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

Корінь: Відсутній HBA/RAID драйвер, невірна гілка драйвера або несумісний режим контролера (RAID vs HBA vs AHCI).

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

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

Чекліст A: Один невідомий пристрій на стабільній машині

1. Витягніть Hardware IDs з Диспетчера пристроїв (Деталі → Hardware Ids).
2. Занотуйте код помилки (вкладка Загальні).
3. Класифікуйте за префіксом: PCI / USB / ACPI / HID.
4. Перевірте, чи з’явився пристрій після конкретної зміни (док, BIOS, оновлення драйвера, оновлення ОС).
5. Використайте Get-PnpDevice, щоб підтвердити InstanceId і Present=True.
6. Перегляньте SetupAPI‑журнал навколо цього InstanceId для причин вибору/помилки драйвера.
7. Встановіть правильний OEM або вендорський пакет драйверів, що явно підтримує цей Hardware ID.
8. Перезавантажте, якщо це платформний драйвер (чіпсет/MEI/PSP) або контролер зберігання. Не намагайтесь «перезапустити» в Диспетчері як основний варіант.
9. Переконайтесь, що статус OK і функціональність працює (не лише «жовтий трикутник зник»).

Чекліст B: Багато невідомих пристроїв після реімеджу

1. Встановіть спочатку чіпсет/платформний пакет (Intel chipset + MEI + Serial IO; AMD chipset + PSP залежно від платформи).
2. Потім встановіть контролери зберігання (якщо не inbox), потім NIC/Wi‑Fi.
3. Тільки після стабілізації мережі дозволяйте Windows Update завантажувати опційні драйвери.
4. Повторно проскануйте: Get-PnpDevice -PresentOnly | Where Status -ne OK.
5. Для залишкових невідомих пристроїв ідентифікуйте за Hardware ID і встановіть цільові драйвери.

Чекліст C: Продуктивні/серверні системи (мінімізувати сюрпризи)

1. Почніть із фіксації стану: список драйверів (pnputil /enum-drivers), версії прошивок (інструменти вендора) та список проблемних пристроїв.
2. Не встановлюйте випадкові пакети драйверів. Користуйтесь затвердженим набором платформи.
3. Для контролерів зберігання та мережі обирайте OEM‑сертифіковані драйвери і тримайте прошивку/драйвер у відповідності.
4. Після змін валідуйте: журнали подій (DeviceSetupManager), помилки зберігання і лічильники продуктивності під навантаженням.
5. Документуйте відповідність Hardware ID → пакет драйвера для відтворюваності.

FAQ

1) Який найшвидший спосіб ідентифікувати невідомий пристрій?

Hardware IDs. Диспетчер пристроїв → Властивості → Деталі → Hardware Ids. Перший рядок (найточніший) — ваш ключ для пошуку і запис у зміні контролю.

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

Бо багато «пристроїв» насправді — платформні шини та контролери (SMBus, I2C, GPIO, Serial IO). Без них залежні пристрої не зможуть коректно енумеруватися або знайти свої драйвери.

3) Що означає Code 28, і чи варто хвилюватися?

Code 28 означає, що драйвер не встановлено. Зазвичай це легко: знайдіть відповідний драйвер і встановіть його. Хвилюйтеся, якщо це критичний контролер (зберігання, мережа) або з’явився після зміни прошивки.

4) Що означає Code 10?

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

5) Чи може Windows Update надійно виправити невідомі пристрої?

Іноді, особливо для поширеного комісійного обладнання. Але платформні/ACPI‑пристрої і серверні контролери зазвичай потребують OEM‑кураторованих пакетів. Якщо ви відповідаєте за надійність — Windows Update доповнення, а не стратегія драйверів.

6) Як ідентифікувати USB‑пристрій, якщо він постійно не проходить енумерацію?

Якщо бачите VID_0000/PID_0002 або помилки дескриптора, у вас може не бути реальної ідентифікації для співставлення. Поміняйте порт/кабель/хаб, оновіть прошивку дока і перевірте стабільність перед пошуком драйверів.

7) Чи безпечно видаляти драйвери зі сховища драйверів?

Може бути, але робіть це свідомо. Використовуйте pnputil /delete-driver, коли впевнені, що невірний INF прив’язаний або спричинює збої, і майте готову корекцію.

8) Чому після оновлення BIOS з’являються невідомі пристрої?

Оновлення BIOS може змінити ACPI‑таблиці або subsystem IDs. Windows трактує це як «новий» апарат, і старе співставлення драйвера може більше не підходити. Перевстановіть платформні драйвери, сумісні з цією версією BIOS.

9) Я бачу лише «Невідомий пристрій» і немає Hardware IDs. Що робити?

Зазвичай можна отримати InstanceId через PowerShell (Get-PnpDevice) або CIM (Win32_PnPEntity). Якщо навіть це відсутнє — підозрюйте глибшу помилку енумерації або пристрій, що постійно відключається.

10) Який найбезпечніший порядок встановлення драйверів на відновленій машині?

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

Висновок: практичні подальші кроки

«Невідомий пристрій» — не детективний роман. Це індексний запис: Windows побачила апарат, не змогла знайти драйвер і лишила вам крихти слідів — Hardware IDs, SetupAPI‑журнали і коди помилок.

Зробіть наступне, у зазначеному порядку:

1. Витягніть Hardware ID і код помилки.
2. Класифікуйте (PCI/USB/ACPI/HID) і вирішіть, чи це платформа, периферія чи контролер.
3. Встановіть чіпсет/платформні драйвери першими, якщо є багато невідомих або будь‑які ACPI‑пристрої.
4. Використовуйте pnputil + SetupAPI‑журнали, щоб підтвердити пакет драйверів, який фактично прив’язався.
5. Для контролерів зберігання та серверного обладнання: узгоджуйте драйвер + прошивку, не імпровізуйте.
6. Запишіть мапінг (Hardware ID → пакет драйвера), щоб наступного разу витрачати 60 секунд замість дня.

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