Windows постійно перевстановлює погані драйвери: припиніть це назавжди

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

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

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

Це не містика. Це політики, рейтинг, пакети драйверів у Driver Store і Windows Update, який робить те, що вважає за краще — на основі правил, які ви можете переважити, якщо готові бути конкретними й трохи наполегливими.

Як Windows вирішує «допомогти» вам (і чому він постійно перевстановлює)

Windows не просто «встановлює драйвер». Він вибирає пакет драйвера, що відповідає вашим ідентифікаторам обладнання, потім розміщує його в Driver Store, а потім прив’язує до пристрою. Вибір базується на ранжуванні. Ранжування враховує специфічність збігу hardware ID, довіру підпису, дату, версію і іноді метадані від вендора. Система прагне зійтися на «найкращому» драйвері, а не зберегти ваші почуття.

Коли Windows постійно перевстановлює поганий драйвер, це майже ніколи не одна причина. Зазвичай це одна з таких схем:

Windows Update доставляє драйвер, і він має вищий рейтинг, ніж ваш бажаний.
Пакет поганого драйвера залишається в Driver Store, тож Plug and Play може перевстановити його під час повторних сканувань або перенумерації пристроїв.
OEM‑утиліти (Lenovo Vantage, Dell Command Update, HP Support Assistant, комплекти драйверів GPU) «допомагають» за своїм розкладом.
MDM/Intune/WSUS централізовано схвалюють або таргетують драйвери.
Фічеві оновлення або операції відновлення повторно розміщують інбокс‑драйвери або «вищі за рейтингом» пакети.

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

Цитата для нотатки біля монітора (парафраз): «Надія — це не стратегія». — часто приписується колам інженерного керівництва; парафраз

Швидкий план діагностики

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

Перше: підтвердьте, який драйвер активний зараз

Диспетчер пристроїв → пристрій → Властивості → вкладка Драйвер (версія, провайдер, дата).
Потім перевірте в CLI (бо GUI приховують важливе): використайте pnputil та dism (див. завдання нижче).

Друге: визначте канал доставки

Встановлено через Windows Update? Перевірте історію оновлень і журнали Event Viewer (SetupAPI, WindowsUpdateClient).
Встановлено через агент OEM? Перевірте інстальовані програми/служби/планувальник завдань.
Підприємство? Перевірте групову політику / MDM політику і чи приходять драйвери з WSUS/Microsoft Update.

Третє: оберіть рівень стримування

Робоча станція / одиничний пристрій: приховайте конкретне оновлення + видаліть пакет з Driver Store + зупиніть автоматичні оновлення драйверів.
Малий офіс: групова політика для блокування оновлень драйверів або обмеження встановлення пристроїв за hardware ID.
Підприємство: припиніть схвалення драйверів у WSUS, зафіксуйте політику в Intune і використайте контрольоване коло розгортання з відомо‑хорошими пакетами.

Четверте: перевірте, що зміни залишилися після перенумерації

Перезавантаження.
Вимкнути/увімкнути пристрій.
Скан для змін обладнання.
Знову перевірте Driver Store. Якщо поганий пакет ще присутній і має високий рейтинг, він повернеться.

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

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

Windows Driver Store став центральним за часів Vista, дозволивши стаґувати драйвери й простіший відкат, але також зробив видалення драйвера двоступеневою проблемою (пристрій vs пакет).
Ранжування Plug and Play не випадкове: більш специфічний збіг hardware ID може перемогти новішу версію драйвера, залежно від таргетингу INF і обчислень рангу.
WHQL‑підпис (а пізніше attest‑підпис) значно підвищили довіру до драйверів у масштабі, але це також дало Windows Update впевненість масово роздавати драйвери.
Windows Update почав активніше розповсюджувати драйвери за часів Windows 10, щоб зменшити кількість «невідомих пристроїв» та покращити початкову роботу системи.
Фічеві оновлення поводяться як in‑place upgrade і можуть повторно оцінювати драйвери, іноді віддаючи перевагу «вбудованим» сумісним драйверам, щоб уникнути помилок оновлення.
OEM можуть публікувати драйвери в Windows Update через канал Microsoft для апаратного забезпечення, тому іноді в провайдері з’являється «Microsoft» для вендорського коду.
Відкат драйвера зазвичай відновлює попередній драйвер для цього екземпляра пристрою, але не обов’язково евіксує новіший пакет з Driver Store.
Windows має окремі політики для «якісних оновлень» і «оновлень драйверів», і підприємства часто блокують одне, але випадково дозволяють інше.
Обмеження встановлення пристроїв за hardware ID існують роками і залишаються одними з найдетермінованіших способів заблокувати зміну драйвера конкретного пристрою.

Жарт №1: Драйвери — як інтерни з правами root: переважно нормальні, поки не вирішать «оптимізувати».

Справжні кореневі причини (не припущення)

1) Поганий драйвер все ще в Driver Store

Якщо пакет залишається стаґованим, Windows може прив’язати його під час:

перенумерації пристроїв (док‑станції, USB NIC, скиди GPU)
«скану для змін обладнання»
циклів виявлення Windows Update
міграції під час фічевих оновлень

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

2) Windows Update має драйвер, що перевищує ваш

Windows вибирає найкращий збіг. Якщо Microsoft Update пропонує драйвер із точнішим hardware ID або кращим рейтингом, він може перемогти, навіть якщо ви встановили щось інше вручну — особливо якщо ваш драйвер — загальний пакет вендора, а пропонований — таргетований на конкретний subsystem ID.

3) Ви боретеся з неправильним джерелом оновлень

Підприємства часто вважають, що є лише Windows Update. Ні. OEM‑інструменти планують оновлення драйверів. Політики MDM можуть нав’язувати драйвери. Системи управління кінцевими пристроями можуть «латати» драйвери, як браузери. Якщо ви блокуєте Windows Update, але Dell Command Update продовжує штовхати пакети, ви все одно програєте.

4) Конфлікт політик: «не включати драйвери» не застосовується там, де ви думаєте

Є багато важелів: локальна групова політика, доменна GPO, MDM CSP політики, схвалення в WSUS і кільця Windows Update for Business. Якщо ви встановили один локально, але доменна політика його перепише, ваша локальна зміна — декоративна.

5) Фічеве оновлення / in‑place upgrade скидає дошку

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

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

Усі завдання нижче можна виконати в Windows. Я форматую їх у стилі bash‑блоків за запитом, але команди — PowerShell/CMD, які можна запускати у піднятому привілеєм середовищі, якщо не зазначено інше.

Завдання 1: Визначити прив’язаний зараз драйвер для пристрою (вид PnP)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | ? {$_.FriendlyName -like '*Wi-Fi*'} | ft -AutoSize Status,Class,FriendlyName,InstanceId"
Status Class    FriendlyName                     InstanceId
------ -----    ------------                     ----------
OK     Net      Intel(R) Wi-Fi 6 AX201 160MHz    PCI\VEN_8086&DEV_06F0&SUBSYS_00748086&REV_00\3&11583659&0&A3

Що це означає: У вас є InstanceId пристрою. Цей ідентифікатор — ваша якірна точка для всього іншого.

Рішення: Якщо пристрій не присутній/не OK, ви не відлагоджуєте «перевстановлення», а діагностуєте виявлення або апаратну несправність.

Завдання 2: Отримати версію/провайдера драйвера, прив’язаного до того пристрою

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPSignedDriver | ? {$_.DeviceID -like 'PCI\\VEN_8086&DEV_06F0*'} | select DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | fl"
DeviceName         : Intel(R) Wi-Fi 6 AX201 160MHz
DriverVersion      : 22.250.1.2
DriverDate         : 2024-03-18T00:00:00.0000000
DriverProviderName : Intel
InfName            : oem42.inf

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

Рішення: Якщо провайдер — «Microsoft», а ви очікували Intel/NVIDIA/AMD, можливо це репакований драйвер із Windows Update.

Завдання 3: Перелічити пакети Driver Store і знайти підозрілий INF

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf Provider Class Version"
Published Name : oem42.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 22.250.1.2 03/18/2024

Що це означає: Пакет драйвера існує в Driver Store як oem42.inf.

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

Завдання 4: Подивитися, чи Windows Update нещодавно встановлював драйвер (історія оновлень)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log; Select-String -Path $env:TEMP\WindowsUpdate.log -Pattern 'Driver' -SimpleMatch | Select-Object -First 5"
2026/02/03 21:14:09.1234567  1234  5678  Agent  * Title = Intel - Net - 22.250.1.2
2026/02/03 21:14:09.1237890  1234  5678  Agent  * UpdateId = {GUID}
2026/02/03 21:14:09.1240000  1234  5678  Agent  * Revision = 201

Що це означає: Windows Update запропонував і, ймовірно, встановив драйвер, що відповідає прив’язаному.

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

Завдання 5: Перевірити логи SetupAPI для того, хто що встановив

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir\inf\setupapi.dev.log -Pattern 'oem42.inf' | Select-Object -Last 8"
>>>  [Driver Install (UpdateDriverForPlugAndPlayDevices) - PCI\VEN_8086&DEV_06F0...]
>>>  Section start 2026/02/03 21:15:02.100
     inf:       Opened INF: 'C:\Windows\INF\oem42.inf' ([strings])
     dvi:       {DIF_SELECTBESTCOMPATDRV} 21:15:02.180
     dvi:       Selected driver installs from section [Install.NT]
     dvi:       {DIF_INSTALLDEVICE} 21:15:02.650
<<<  Section end 2026/02/03 21:15:06.900

Що це означає: Драйвер встановлено через шлях PnP update. Логи SetupAPI — найближче до аудиту встановлення драйверів і прив’язок у Windows.

Рішення: Якщо часові мітки співпадають з активністю Windows Update, зосередьтеся на контролі WU. Якщо збігається з розкладом OEM‑задач, вимкніть OEM‑оновлювач.

Завдання 6: Вимкнути автоматичне завантаження драйверів (зручний перемикач)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching
    SearchOrderConfig    REG_DWORD    0x1

Що це означає: 0x1 — «Так, виконувати автоматично» в багатьох збірках; 0x0 — «Ні».

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

Завдання 7: Застосувати політику «Не включати драйвери в оновлення Windows» (підтримувана політика)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate
ERROR: The system was unable to find the specified registry value or key.

Що це означає: Політика не встановлена (або встановлена в іншому місці через MDM). Ви можете встановити її через GPO або реєстр (у флотах краще GPO/MDM).

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

Завдання 8: Встановити значення політики в реєстрі (локальний тест, потім робіть правильно)

cr0x@server:~$ reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f
The operation completed successfully.

Що це означає: Це наказує Windows Update не включати оновлення драйверів у якісні оновлення.

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

Завдання 9: Видалити поганий пакет драйвера з Driver Store (реальне вигнання)

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

Driver package deleted successfully.
Deleted driver package: oem42.inf

Що це означає: Пакет видалено, і Windows не може прив’язати його знову, якщо його не реімпортувати.

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

Завдання 10: Підтвердити, що він справді зник

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf"

Що це означає: Відсутність виводу означає, що INF не присутній у Driver Store.

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

Завдання 11: Встановити відому‑хорошу версію драйвера і перевірити прив’язку

cr0x@server:~$ pnputil /add-driver "C:\Drivers\WiFi\Netwtw06.inf" /install
Microsoft PnP Utility

Driver package added successfully.
Published name: oem77.inf
Driver package installed on matching devices.

Що це означає: Ви стаґували і встановили відому‑хорошу версію; тепер це oem77.inf.

Рішення: Запишіть oem77.inf та версію/дату. Це те, що ви будете захищати.

Завдання 12: Заблокувати оновлення драйвера для конкретного пристрою за hardware ID (детерміновано)

cr0x@server:~$ powershell -NoProfile -Command "$id='PCI\VEN_8086&DEV_06F0&SUBSYS_00748086'; $id"
PCI\VEN_8086&DEV_06F0&SUBSYS_00748086

Що це означає: Ви захопили hardware ID для використання в обмеженнях встановлення пристроїв (GPO), щоб Windows не могла інсталювати сумісні драйвери, окрім тих, що вже дозволені.

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

Завдання 13: Перевірити, які GPO фактично застосовані (бо «я встановив» — це не доказ)

cr0x@server:~$ gpresult /r
COMPUTER SETTINGS
------------------
    Applied Group Policy Objects
    -----------------------------
        Workstation Baseline
        Windows Update Control

Що це означає: Ви бачите, чи застосовано об’єкт політики, який має контролювати драйвери.

Рішення: Якщо очікуваний GPO не вказаний, виправлення потрібно в Active Directory, а не в реєстрі.

Завдання 14: Переглянути значення політик Windows Update, що часто конфліктують

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    ExcludeWUDriversInQualityUpdate    REG_DWORD    0x1
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    UseWUServer    REG_DWORD    0x1

Що це означає: Драйвери виключені, і машина вказує на WSUS (UseWUServer=1).

Рішення: Якщо ви використовуєте WSUS, виправте схвалення там; локальне приховування оновлень не допоможе, якщо WSUS постійно нав’язує їх.

Завдання 15: Перелік встановлених сторонніх драйверів через DISM (корисно для розбору інцидентів)

cr0x@server:~$ dism /online /get-drivers /format:table | more
Published Name   Original Name  Inbox  Class Name  Provider Name  Date       Version
-------------   -------------  -----  ----------  -------------  ---------  -------------
oem77.inf       netwtw06.inf   No     Net         Intel          2023-11-10  22.220.0.4
oem13.inf       nv_dispi.inf   No     Display     NVIDIA         2024-01-05  551.23

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

Рішення: Якщо після Patch Tuesday ви бачите неочікуване підняття провайдера/дати, у вас проблема драйверного дрейфу.

Завдання 16: Примусити повторне сканування і спостерігати, чи повертається поганий драйвер

cr0x@server:~$ pnputil /scan-devices
Microsoft PnP Utility

Scanning devices completed.

Що це означає: Машина переоцінювала збіги пристроїв і драйверів. Це безпечний спосіб перевірити, чи тримається ваше блокування/вигнання.

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

Стратегії блокування, які дійсно працюють

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

Рівень 1: Блокуйте оновлення драйверів широко (швидко, грубо)

Використовуйте ExcludeWUDriversInQualityUpdate через GPO/MDM. Це зупиняє поширення драйверів через якісні оновлення Windows Update. Воно не зупиняє ручні інсталяції, OEM‑оновлювачі або поведінку під час фічевих оновлень. Проте це варто робити в середовищах, де стабільність драйверів важливіша за новизну.

Коли використовувати: офісні парки, VDI‑вузли, кіоски, системи зі валідацією апаратного стека, аудіо‑станції, промислові пристрої.

Коли не використовувати: ноутбуки, що залежать від частих вендорських виправлень (регресії Wi‑Fi/BT) або коли немає альтернативного процесу доставки драйверів.

Рівень 2: Приховати/заблокувати конкретне оновлення драйвера (точково, але залежить від джерела)

Якщо конкретний драйвер пропонується через Windows Update, ви можете приховати його, щоб WU не перевстановлював його. У споживацьких середовищах це роблять через утиліту «show or hide updates». У керованих — через схвалення оновлень (WSUS) або контролі таргетингу драйверів (MDM). Сенс один: зупинити доставку в джерелі.

Підводний камінь: Приховування працює, поки оновлення не перепубліковано як нова ревізія або трохи змінений пакет. Тоді це знову «нове» оновлення і ви повертаєтесь у петлю.

Рівень 3: Обмеження встановлення пристроїв за hardware ID (найдетермінованіше)

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

Простіше: ви створюєте «швейцара» для змін драйвера цього пристрою.

Підводний камінь: Якщо блокувати занадто широко (наприклад клас «Display» у середовищі з великою кількістю GPU), ви врешті підірвете апгрейди та заміни обладнання.

Евіксія поганого пакета з Driver Store (обов’язково)

Якщо ви хочете «припинити це назавжди», видаліть пакет, який Windows постійно обирає. Інакше ви покладаєтесь на рейтинг і випадок. Використовуйте pnputil /delete-driver з /uninstall і /force за потреби. Потім підтвердіть, що його немає.

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

Робота з OEM‑оновлювачами (вони добрі наміри; все одно ламають)

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

Якщо IT відповідає: видаліть/відключіть OEM‑оновлювачі або налаштуйте їх на режим тільки‑повідомлення.
Якщо OEM відповідає: прийміть дрейф і побудуйте моніторинг плюс автоматизацію відкатів.

Жарт №2: Windows Update — найупевненіший колега у світі: завжди «виправляє» те, що ви нарешті стабілізували.

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

Міні‑історія 1: Інцидент через хибне припущення

У них був гібридний парк: робочі станції інженерів в офісі, віддалені ноутбуки по VPN і кілька загальних лабораторних машин з дорогим вимірювальним обладнанням. Хтось помітив нестабільний драйвер USB‑to‑Ethernet на частині ноутбуків — випадкові відключення, особливо після сну.

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

Через два тижні лабораторні машини почали відвалюватися з мережі під час довготривалих тестів. Не ноутбуки. Не віддалені. Тільки лабораторні. Постачальник дорікав кабелями. Мережники — spanning tree. Лабораторія — всім.

Корінь проблеми виявився в OEM‑утиліті, що працював як SYSTEM на образі лабораторії. Йому налаштували «auto‑apply recommended updates» місяці тому. Йому байдуже до політики виключення драйверів Windows Update, бо він не Windows Update. Він завантажив новіший драйвер прямо з OEM‑каталогу і встановив його під час вікна техобслуговування.

Виправлення: видалили OEM‑оновлювач з образу лабораторії, перевели BIOS/прошивки в контрольований щомісячний процес і застосували обмеження встановлення пристроїв для конкретних hardware ID USB NIC. Хибне припущення не було злим наміром; воно просто не враховувало всі джерела. У доставки драйверів кілька ротів.

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

Група десктоп‑інженерів хотіла пришвидшити розгортання. Вони зробили «золотий образ» з напханий Driver Store: чипсет, GPU, аудіо, NIC — все попередньо стаґовано. Ідея була проста: перший запуск — ніяких відсутніх пристроїв, мінімум проблем для користувача.

Працювало бездоганно… поки не перестало. Частина машин почала обирати старіший, але більш специфічний GPU‑драйвер, що був стаґований місяці тому для трохи іншого subsystem ID. Він мав високий рейтинг, добре збігався і лежав у сховищі, як навантажений капкан.

Симптоми були дивні: деякі CAD‑додатки крешили, але лише на певних ревізіях апаратного забезпечення. Відкат допомагав на день. Потім після циклу док/віддок або скану Windows Update старий драйвер повертався. Їхня «оптимізація» створила більший набір кандидатів, підвищивши шанси Windows вибрати те, чого вони не хотіли.

Виправлення: змінили процес іміджування, щоб стаґувати лише драйвери, потрібні для конкретної моделі SKU, а не весь вендорський універсум. Також додали пост‑провізійну валідацію, що перелічує пакети Driver Store і видаляє відомі‑погані INF. Провізія стала трохи повільнішою. Середній час до здорового стану зріс драматично.

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

Фінансовий відділ мав десктопи з підключеним старим, але критичним сканером квитанцій. Сканер залежав від дуже конкретної версії драйвера USB‑контролера — новіші «працювали», але давали переривчасту корупцію, що було важко помітити до аудитів. Всі ненавиділи цю конфігурацію — отже вона була важливою.

Замість гри у whack‑a‑mole команда кінцевих точок зробила три непоказні речі. По‑перше, документували точні hardware ID контролера і сканера. По‑друге, створили базовий пакет драйверів і зберегли його внутрішньо в процесі іміджування. По‑третє, застосували обмеження встановлення пристроїв, щоб контролер не міг змінити драйвер без явного вікна змін.

Потім пройшло фічеве оновлення. Передбачувано, воно спробувало модернізувати драйвери. На більшості пристроїв це пройшло нормально. На цих — заміна не відбулася через обмеження, і пристрої продовжили працювати з дозволеною версією.

Ніякого інциденту. Ніякого хаосу. Ніяких панічних листів керівництву з «any updates???» Сумна, але правильна практика — явні правила allow/block і відома‑хороша пакуваль — не зробила їх популярними, але зробила правильними. В операціях правильне перемагає.

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

1) Симптом: «Я відкатую драйвер, але він повертається після перезавантаження»

Корінь проблеми: Новіший/поганий пакет все ще в Driver Store і має вищий рейтинг. Відкат змінює прив’язку, а не набір кандидатів.

Виправлення: Видаліть поганий INF з Driver Store за допомогою pnputil /delete-driver ... /uninstall. Потім встановіть відому‑хочу версію і перевірте через скан.

2) Симптом: «Я вимкнув оновлення драйверів, але драйвер все одно змінюється»

Корінь проблеми: OEM‑оновлювач або політика MDM встановлює драйвер поза Windows Update, або фічеве оновлення замінює драйвери.

Виправлення: Визначте джерело через логи SetupAPI + планувальник завдань/служби. Видаліть/відключіть OEM‑оновлювач або відрегулюйте політику MDM/WSUS. Для дійсно стійкого контролю використайте обмеження встановлення пристроїв.

3) Симптом: «Диспетчер пристроїв показує одну версію, але поведінка відповідає поламаній версії»

Корінь проблеми: Кілька компонентів: пакет драйвера vs прошивка vs супутнє ПЗ; або пристрій насправді використовує інший екземпляр (наприклад dock NIC vs внутрішній NIC).

Виправлення: Підтвердьте InstanceId і hardware ID. Перелічіть Win32_PnPSignedDriver за DeviceID. Переконайтеся, який саме пристрій фейлить за журналами подій.

4) Симптом: «pnputil delete-driver не вдається: драйвер використовується»

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

Виправлення: Видаліть пристрій(и), від’єднайте знімне обладнання, перезавантажтеся або зайдіть у Safe Mode. Потім знову видаліть драйвер. Підтвердіть через pnputil /enum-drivers.

5) Симптом: «Після фічевого оновлення драйвери повернулися до старіших»

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

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

6) Симптом: «Тільки деякі машини постраждали»

Корінь проблеми: Різні subsystem ID, різні OEM‑образи або різний вміст Driver Store вже на машинах.

Виправлення: Порівняйте hardware ID і вміст Driver Store. Не робіть припущення, що «та сама модель» = «ті самі ID»; часто це не так.

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

Одна машина: припинити кровотечу за 30 хвилин

Визначте екземпляр пристрою (Завдання 1) і поточний INF (Завдання 2).
Підтвердіть, що поганий INF є в Driver Store (Завдання 3).
Перевірте, чи Windows Update його доставив (Завдання 4) і підтвердіть через SetupAPI (Завдання 5).
Вигнайте поганий пакет через pnputil /delete-driver (Завдання 9), потім підтвердіть (Завдання 10).
Встановіть відому‑хорошу версію драйвера (Завдання 11).
Вимкніть доставку драйверів через Windows Update через політику (Завдання 8), принаймні тимчасово.
Примусово проскануйте (Завдання 16) і перезавантажте. Перевірте версію/провайдера драйвера.

Малий флот: стабілізувати без створення нових проблем

Оберіть відому‑хорошу версію драйвера і задокументуйте її (провайдер, версія, INF, hardware ID).
Зупиніть оновлення драйверів через політику Windows Update (переважно GPO). Перевірте через gpresult (Завдання 13).
Видаліть поганий драйвер з Driver Store скриптом (pnputil) під час вікон обслуговування.
Вимкніть OEM‑оновлювачі або налаштуйте їх на режим тільки‑повідомлення.
Додайте моніторинг: періодично виконувати DISM інвентар драйверів (Завдання 15) і позначати дрейф за провайдером/датою/версією.

Підприємство: зробити це нудним, повторюваним і аудитовим

Визначте відповідальність: Windows Update vs OEM vs IT‑пакетовані драйвери. Змішана відповідальність викликає дрейф.
Впровадьте драйверні кільця: спочатку пілотна група, потім широке розгортання після валідації.
Використовуйте WSUS/MDM контролі щоб запобігти небажаному розгортанню драйверів. Не покладайтеся на приховування на кінцевих пристроях.
Використовуйте обмеження встановлення пристроїв для критичних периферій і проблемних пристроїв.
Побудуйте playbook відкату, що включає евіксію з Driver Store, а не лише відкат пристрою.
Під час фічевих оновлень заплануйте пост‑апгрейдну ремедіацію для повторного застосування дозволених драйверів і видалення заборонених.

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

1) Чому Windows постійно перевстановлює той самий поганий драйвер після відкату?

Тому що відкат змінює активну прив’язку, але новіший пакет часто залишається в Driver Store і все ще має найкращий рейтинг. Евіксуйте пакет через pnputil /delete-driver і блокуйте доставку.

2) Чи достатньо «Не включати драйвери в оновлення Windows»?

Іноді. Це блокує доставку драйверів через якісні оновлення, але не зупиняє OEM‑оновлювачі, MDM‑пуші або заміни драйверів під час фічевих оновлень. Якщо вам потрібні гарантії, додайте евіксію з Driver Store і обмеження встановлення пристроїв.

3) Чи видалення пристрою в Диспетчері пристроїв видалить драйвер?

Не завжди надійно. Воно може видалити екземпляр пристрою, але пакет драйвера може залишитися стаґованим. Використовуйте pnputil /enum-drivers, щоб підтвердити, чи INF ще існує.

4) У чому різниця між «провайдер Microsoft» і «провайдер Intel/NVIDIA/AMD»?

«Microsoft» часто означає, що драйвер доставлений через канал Microsoft (або інбокс‑драйвер). Це все одно може бути код вендора. Не робіть висновків про якість лише за рядком провайдера — перевіряйте версію, INF і джерело.

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

Так, але механізм залежить від середовища. У керованих мережах блокуйте його в WSUS/MDM таргетингу. На автономному ПК приховання оновлення може працювати, але перепубліковані ревізії можуть обійти приховування.

6) Чи безпечно примусово видаляти драйвери за допомогою pnputil?

Може бути безпечно, якщо ви розумієте залежності. Не видаляйте примусово драйвери зберігання, чипсету або критичні для завантаження, якщо у вас немає засобів відновлення і протестованого шляху відкату. Для GPU і NIC ризик зазвичай нижчий, але плануйте час простою.

7) Чому лише деякі машини отримують поганий драйвер?

Hardware ID відрізняються більше, ніж очікують люди — subsystem ID, ревізії і OEM‑кастомізації змінюють матчинг і ранжування. Також різні машини накопичують різний вміст Driver Store з часом.

8) Як довести, звідки прийшов драйвер?

Корелюйте часові мітки SetupAPI у C:\Windows\inf\setupapi.dev.log з логами Windows Update і розкладами OEM‑оновлювачів. Це не ідеальна атрибуція, але достатня, щоб знайти виконавця.

9) Чи шкодить блокування драйверів безпеці?

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

10) Що з прошивками, що виглядають як драйвери?

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

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

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

Визначте екземпляр пристрою, поточну версію драйвера і ім’я INF (Завдання 1–3).
Евіксуйте небажаний пакет з Driver Store і встановіть вашу відому‑хорошу версію (Завдання 9–11).
Застосуйте межу: блокуйте доставку драйверів через політику і/або зафіксуйте пристрій обмеженнями встановлення (Завдання 8, 12–14).

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