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

Принципи: ставтеся до драйверів як до продакшн-коду

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

Контроль: вирішіть, звідки приходять драйвери

Драйвери Windows можуть надходити з кількох каналів: OEM-іміджування, інсталятори вендорів, Windows Update, WSUS, Configuration Manager,
Intune та канал «хтось скачав .exe з форуму о 2-й ночі». Ваше перше завдання — звузити це до одного-двох
дозволених каналів і зробити все інше складнішим, ніж правильний шлях.

Вам не потрібен світ, де Wi‑Fi драйвер може оновитися одночасно з вашою роздачею VPN і накопичувальним оновленням Windows.
Це не «agile». Це складання Jenga під час землетрусу.

Спостережуваність: якщо ви не можете це виміряти, ви не можете це розгортати

Для драйверів «метрики» означають: частота аварій (bugchecks), скиди пристрою, помилки в Event Viewer, регресії продуктивності
(DPC latency, таймаути сховища) та сигнали впливу на користувача (вимкнення VPN, артефакти аудіо, камера Teams не знайдена).
Вам потрібні базові показники та кореляція з версією драйвера.

Відкатність: зробіть відкат нудною операцією

Якщо оновлення драйвера не можна відкотити швидко, це не оновлення; це ставка.
Відкат має працювати як онлайн (Device Manager / pnputil), так і офлайн (WinRE / Safe Mode / DISM проти офлайн-образу).
Ваша політика має передбачати найгірше: машини, що не завантажуються, BitLocker, віддалені користувачі та відсутність фізичного доступу до клавіатури.

Темп: кільця перемагають надію

Ви не можете «протестувати в QA» кожну апаратну перестановку. Ви можете, однак, етапно розгортати:
пілот → ранні користувачі → широке розгортання → повільний хвіст, з явними точками перевірки та аварійною зупинкою.
Мета — не нуль інцидентів. Мета — маленькі інциденти, які навчають вас перед тим, як вони переростуть у великі.

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

Цікаві факти та коротка історія

• Підписування драйверів стало справжнім барʼєром з епохи 64-біт Windows Vista; незаписані кернел-драйвери перестали бути «порадою» і стали блокером для розгортання.
• WHQL сертифікація (Windows Hardware Quality Labs) існує десятиліттями, але це барʼєр сумісності, а не гарантія продуктивності чи стабільності під ваші робочі навантаження.
• WDDM (Windows Display Driver Model) замінив XPDM починаючи з Vista, змінивши взаємодію графічних драйверів із ОС і покращивши відновлення—але також додав складності.
• Фреймворки KMDF/UMDF відсунули багатьох вендорів від повністю кастомного kernel-коду; це зменшило деякі класи помилок, але погані драйвери все ще існують. Ентузіастські форуми залишаються непереможними.
• Windows Update почав доставляти більше драйверів з часом, особливо для споживчих пристроїв — це добре, доки організація не потребує суворих вікон змін.
• Ранжування Plug and Play драйверів означає, що Windows може «допоміжно» вибрати інший драйвер, ніж ви планували, якщо кілька кандидатів підходять і мають вищий ранг.
• Стеки Storport і NVMe значно виросли між релізами Windows; проблеми зі сховищем часто — це тристороння боротьба між ОС, прошивкою та драйвером вендора.
• HVCI/Memory Integrity (virtualization-based security) може ламати старі драйвери; «працювало роками» — це не доказ сумісності, це просто часовий проміжок.

Що насправді зазвичай означає «він вийшов з ладу за ніч»

Існують справжні «брік»-випадки (погані прошивки, апаратні збої), але більшість «бріків» — це одне з наступного:

Невдача завантаження після зміни драйвера сховища або чіпсету

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

BSOD, привʼязані до шляху пристрою, а не патчу Windows

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

Регресії продуктивності, що виглядають як «мережа повільна»

Погані драйвери NIC не завжди падають. Вони вимикають offload, ламають RSS або неправильно обробляють стани живлення.
Звіт користувача стає «VPN ненадійний», служба підтримки перезавантажує все, а драйвер продовжує тихо погано працювати.

Пристрій зникає: камера, аудіо, Bluetooth, док-станції

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

Жарт №1: Драйвери — як кішки: технічно приручені, але все одно зіштовхують речі зі столу, коли ви не дивитесь.

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

1) Встановіть політику: хто має право оновлювати драйвери і як

Вирішіть, чи керуватимуть драйверами WSUS/ConfigMgr, Intune або OEM-утиліти (або їх комбінація).
Потім припиніть дозволяти Windows Update безкоштовно вкладати драйвери в продакшн, якщо ви цього явно не хочете.

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

2) Зробіть базове інвентарне знімання фліту: ви не можете керувати тим, чого не інвентаризували

Ваш базовий інвентар має включати:
виробник/модель, версію BIOS/UEFI, ключові версії драйверів пристроїв (сховище/NIC/GPU) та фільтр-драйвери
(AV, DLP, шифрування, VPN, бекап). Це зазвичай головні підозрювані.

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

3) Встановіть кільця драйверів: пілот, ранні, широке, потім повільний канал

Практична модель кілець:

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

Ключ — час між кільцями. Драйвери потребують часу для прогонів. Баг у NIC може проявитися лише після циклів сон/пробудження,
підключення/відключення дока або тижня роумінгу.

4) Вибирайте, що оновлювати — і що лишити в спокої

Не всі драйвери заслуговують однакової уваги. Пріоритезуйте:

• Сховище: NVMe, RAID, HBA, контролери чіпсету. Тут живе завантажуваність і безпека даних.
• Мережа: Ethernet/Wi‑Fi, особливо на ноутбуках; залежності VPN і баги роумінгу обожнюють ці драйвери.
• Графіка: стабільність, конференції та управління живленням, плюс виправлення безпеки в GPU-стеках.
• Чіпсет та драйвери супутньої прошивки: живлення, ACPI та компонентна платформа.
• Драйвери, повʼязані з безпекою: усе, що має фільтр-драйвери (AV, DLP, шифрування, агенти кінцевої точки).

Тим часом драйвер USB-to-serial для одного лабораторного інструмента, яким користуються двічі на рік, йде в Ring 4 з позначкою:
«Оновлювати тільки за необхідності, тестуючи з присутнім інструментом».

5) Вимагайте артефакти відкату: правило «ескроу пакетів»

Перед широким розгортанням у вас має бути:

• пакет драйвера, який ви розгортаєте (INF/CAT/SYS) збережений централізовано,
• попередній відомо-ґуд пакет збережений централізовано,
• протестована процедура видалення/відкату (онлайн і офлайн),
• метод виявлення для підтвердження версії та стану інсталяції.

Якщо ви не можете надати попередній відомо-ґуд драйвер на вимогу, ви не займаєтесь управлінням змін — ви займаєтесь археологією.

6) Гейтте на сигналах, а не на відчуттях

Ваші правила «тримати/просувати» повинні бути явними. Приклади:

• Рівень bugcheck для пілотних пристроїв не перевищує базового показника.
• Немає нових кластерів Event ID для таймаутів диска, скидів NIC або проблем з виявленням пристроїв.
• Немає збільшення звернень у службу підтримки з тегами «VPN відпадає», «сон/пробудження», «док», «камера відсутня».
• Для сховища: немає збільшення попереджень storport, немає нових шаблонів «reset to device».

7) Уникайте комбінування масштабних змін

Якщо ви робите оновлення функцій Windows, не проштовхуйте одночасно нові NIC, GPU і драйвери сховища, якщо вам не подобається
дебаг з трьома рухомими частинами. Розділяйте зміни, інакше втрачається причинність.

8) Використовуйте таргетинг пристроїв: за моделлю та hardware ID

«Розгорнути на всі машини з Windows 11» — це як опинитися з оновлювачем прошивки дока на десктопах, які ніколи не бачили дока.
Таргетуйте за моделлю OEM, instance ID пристрою або хоча б за вендором і класом пристрою.
Драйвери не універсальні — саме для цього вони існують.

План швидкої діагностики

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

Перш за все: класифікуйте збій

• Не завантажується (boot loop, ранній BSOD, BitLocker recovery): розглядайте як проблему storage/chipset/boot-start драйвера, поки не доведено інше.
• Завантажується, але нестабільно (випадкові перезавантаження, BSOD): збирайте дампи, корелюйте модулі bugcheck, перевіряйте нещодавні інсталяції драйверів.
• Завантажується, але один підсистема не працює (мережа, аудіо, камера, док): фокусуйтесь на класі пристрою і переходах станів живлення.
• Завантажується, але повільно (латентність, заїдання, таймаути): перевіряйте патерни DPC latency, скиди storport, поведінку NIC offload.

Друге: знайдіть «що змінилося» з доказами

• Перевірте історію Windows Update та події інсталяції драйверів.
• Підтвердіть точну версію драйвера, що завантажена зараз.
• Визначте, чи задіяний фільтр-драйвер (AV/DLP/VPN/шифрування).

Третє: вирішіть дію для утримання

• Зупиніть розгортання: негайно призупиніть затвердження або кільця.
• Відкотіть драйвер, якщо є чітка кореляція.
• Вимкніть пристрій як тимчасовий захід, якщо відкат ризикований (наприклад, вимкніть проблемний Wi‑Fi і підключіть Ethernet).
• Зафіксуйте версію, заборонивши повторну інсталяцію проблемного драйвера політикою або видаливши пакет із driver store.

Четверте: підтвердіть відновлення і запобіжні заходи

• Перевірте стабільну роботу після перезавантаження і циклів сон/пробудження.
• Переконайтесь, що Windows Update не перевстановить одразу той самий драйвер.
• Задокументуйте сферу впливу апаратури (моделі) і межі версій драйверів (погано проти добре).

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

Це польові завдання. Те, що ви робите, коли потрібні швидкі відповіді й немає місця для фольклору.
Команди припускають, що ви працюєте в оболонці, де доступні інструменти Windows (PowerShell/Command Prompt).
Так, мітка запрошення каже «bash», тому що правила форматування дивні; команди все одно реальні Windows-команди.

Завдання 1: Побачити, які драйвери були встановлені нещодавно (швидка триаж)

cr0x@server:~$ wmic qfe list brief /format:table
HotFixID  InstalledOn  Description
KB5034123 1/10/2026     Update
KB5034204 1/10/2026     Security Update

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

Завдання 2: Перелічити встановлені сторонні драйвери з версіями й датами

cr0x@server:~$ driverquery /v /fo table
Module Name  Display Name                 Driver Type  Link Date     Path
e1dexpress   Intel(R) Ethernet Adapter    Kernel       01/05/2026    C:\Windows\System32\drivers\e1dexpress.sys
stornvme     Microsoft NVMe Controller    Kernel       12/12/2025    C:\Windows\System32\drivers\stornvme.sys

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

Завдання 3: Показати пакети драйверів у driver store (реальний інвентар)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem42.inf
Original Name  : e1dexpress.inf
Provider Name  : Intel
Class Name     : Net
Driver Version : 01/05/2026 1.2.3.4
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Що це означає: Це те, що Windows може інсталювати/переінсталювати без завантаження нічого додаткового.
Рішення: Якщо поганий драйвер є в store, його видалення або блокування запобігає «поверненню» після відкату.

Завдання 4: Визначити, який драйвер привʼязаний до конкретного пристрою (PnP)

cr0x@server:~$ pnputil /enum-devices /class Net
Instance ID: PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03\3&11583659&0&FE
Device Description: Intel(R) Ethernet Connection
Status: Started
Driver Name: oem42.inf

Що це означає: Відображення відповідності instance пристрою → пакет драйвера.
Рішення: Якщо декілька моделей мають однаковий патерн Instance ID, ви можете точно обмежити розгортання/відкат.

Завдання 5: Відкат — видалити конкретний пакет драйвера

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

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

Завдання 6: Перевірити, чи Windows тягне драйвери з Windows Update

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

Що це означає: Значення 0x1 загалом вказує, що Windows може шукати драйвери на Windows Update.
Рішення: В керованих флітах розгляньте встановлення політики, що забороняє несподіване підтягування драйверів, і доставляйте драйвери через ваш канал.

Завдання 7: Підтвердити поточну завантажену версію драйвера для мережевого адаптера

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,DriverVersion,DriverDate | Format-Table -Auto"
Name   InterfaceDescription                   DriverVersion DriverDate
Ethernet Intel(R) Ethernet Connection         1.2.3.4       1/5/2026 12:00:00 AM
Wi-Fi  Intel(R) Wi-Fi 6E AX211                22.250.1.2    12/14/2025 12:00:00 AM

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

Завдання 8: Шукати таймаути сховища та патерни скидів (storport/disk)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129 or EventID=153 or EventID=157)]]" /c:5 /f:text
Event[0]:
  Provider Name: storahci
  Event ID: 129
  Level: Warning
  Description: Reset to device, \Device\RaidPort0, was issued.

Що це означає: Події Event 129/153 — класичні ознаки проблем зі сховищем (таймаути, скиди).
Рішення: Якщо вони зʼявилися після зміни драйвера/прошивки, зупиніть розгортання і розслідуйте сумісність драйвера сховища + прошивки.

Завдання 9: Перевірити WHEA апаратні помилки, що маскуються під «проблеми драйвера»

cr0x@server:~$ wevtutil qe System /q:"*[System[(Provider[@Name='Microsoft-Windows-WHEA-Logger'])]]" /c:3 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  Level: Warning
  Description: A corrected hardware error has occurred.

Що це означає: Виправлені помилки можуть передувати невиправленим; часто корелюють з PCIe, NVMe, пам’яттю або CPU.
Рішення: Якщо WHEA різко зростає після оновлення драйвера, не робіть поспішних висновків, що драйвер «спровокував апаратні помилки» —
але врахуйте, що нові стани живлення або налаштування каналу можуть навантажувати граничне апаратне забезпечення.

Завдання 10: Підтвердити, чи увімкнено Memory Integrity (HVCI) — тригер сумісності драйверів

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Що це означає: Наявність певних служб безпеки може вказувати на активність VBS/HVCI (залежно від середовища).
Рішення: Якщо драйвер не завантажується лише на машинах з Memory Integrity, ймовірно, у вас несумісний або заблокований драйвер.

Завдання 11: Достати bugcheck і «faulting module» з системного журналу

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1001)]]" /c:3 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WER-SystemErrorReporting
  Event ID: 1001
  Description: The computer has rebooted from a bugcheck. The bugcheck was: 0x000000d1. A dump was saved in: C:\Windows\MEMORY.DMP.

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

Завдання 12: Перелічити boot-start драйвери (ті, що можуть перешкоджати завантаженню)

cr0x@server:~$ sc query type= driver state= all | findstr /i "BOOT_START"
BOOT_START

Що це означає: Цей швидкий фільтр грубий; boot-start драйвери — найнебезпечніші, бо збої стаються на ранніх етапах.
Рішення: Якщо змінений драйвер є boot-start (сховище/чіпсет), вам потрібна готовність до офлайн-відкату і обережний графік кілець.

Завдання 13: Перелічити фільтр-драйвери, приєднані до томів (часто залучені у проблеми з boot/storage)

cr0x@server:~$ fltmc filters
Filter Name                     Num Instances    Altitude    Frame
WdFilter                        10               328010      0
luafv                           1                135000      0
SomeVendorEncryptionFilter      4                189900      0

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

Завдання 14: Офлайн-видалення пакета драйвера з незавантажуваної системи (WinRE)

cr0x@server:~$ dism /image:D:\ /get-drivers /format:table
Published Name  Original Name     Provider Name  Class Name  Date       Version
oem42.inf       e1dexpress.inf    Intel          Net         01/05/2026  1.2.3.4

cr0x@server:~$ dism /image:D:\ /remove-driver /driver:oem42.inf
The operation completed successfully.

Що це означає: Можна хірургічно видалити драйвер з офлайн-образу Windows.
Рішення: Використовуйте, коли система не завантажується і драйвер відомо-поганий. Ось чому документують published name (oemXX.inf).

Завдання 15: Перевірити помилки, повʼязані зі сном/пробудженням (переходи живлення)

cr0x@server:~$ powercfg /sleepstudy
Sleepstudy report saved to C:\Windows\system32\sleepstudy-report.html

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

Жарт №2: Найшвидший спосіб навчитися дебагу ядра — оновити графічний драйвер на ноутбуці CEO. Другий найшвидший — зробити це двічі.

Три корпоративні міні-історії (і уроки)

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

Середня компанія стандартизувалась на популярній лінійці ноутбуків. ІТ припустило, що оскільки OEM використовував однакову маркетингову назву протягом року,
внутрішні NIC і Wi‑Fi компоненти «по суті однакові». План rollout трактував модель як одну апаратну корзину.

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

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

Виправлення було простим: розділити таргетинг за hardware ID і зафіксувати старішу ревізію на відомо-ґуд драйвері.
Урок не в «тестувати більше». Урок: ніколи не таргетуйте драйвери лише за маркетинговою моделлю. Таргетуйте за реальними device ID і ревізіями.

Вони оновили базовий інвентар, щоб включити PCI VEN/DEV і SUBSYS ідентифікатори для NIC.
Наступне розгортання використовувало ці ідентифікатори як групи розгортання, і міф «та сама модель» тихо помер у електронній таблиці.

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

Глобальне підприємство хотіло швидше провізіонувати девелоперів. Хтось вигадав ідею «прискорити Windows Update», дозволивши драйверам
від Microsoft приходити автоматично для будь-чого, що підходить, тоді як ІТ підтримувало тільки тонкий набір критичних драйверів в образі.
Аргумент був привабливий: менше пакування, менше OEM-утиліт, нові пристрої «просто працюють».

Це працювало. Деякий час. А потім оновлення графічного драйвера через Windows Update пройшло нормально на десктопах, але виявилось нестабільним на специфічній комбінації док+ноутбук.
Режим відмови не був крашом. Це були миготіння зовнішніх моніторів, відключення USB-пристроїв і іноді чорний екран після сну.
Девелопери звинувачували док. ІТ — док. Закупівля — док.

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

Відкат теж був проблемним, бо driver store вже містив новий пакет, і Windows Update продовжував «допомагати», перевстановлюючи його.
Команда в результаті ввела відтермінування оновлень драйверів і перейшла на поетапну модель з керованим затвердженням драйверів.

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

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

Фінансова організація мала нудну політику: кожне оновлення драйвера потребувало ескроу для відкату, а широке розгортання вимагало двох контрольних точок:
семиденне пропитування в Ring 1 і чотирнадцятиденне пропитування в Ring 2. Люди скаржилися, що це повільно.
Команда SRE не хвилювалася; вони любили спати.

Оновлення драйвера сховища для підмножини робочих станцій обіцяло покращення продуктивності. Пілот показав трохи кращі бенчмарки,
тому команда перевела на Ring 2. На девʼятий день декілька машин почали логувати скиди storport.
Ще не було звернень користувачів. Просто телеметрія і уважний аналітик, який справді читає логи.

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

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

Урок: нудні ворота плюс ескроу відкатів перемагають кмітливість. Політика не запобігла багу. Вона запобігла простою.

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

1) «Ми відкотили, але поганий драйвер повернувся»

Симптом: Device Manager показує стару версію недовго, потім вона оновлюється знову після перезавантаження.

Корінь: Пакет драйвера залишився в driver store, або Windows Update має дозвіл завантажувати драйвери.

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

2) «Тільки деякі ноутбуки уражені, хоча вони однакової моделі»

Симптом: Різна поведінка на апаратурі, що виглядає однаково.

Корінь: Різні ревізії пристроїв (SUBSYS/REV), різні партії SSD або різні прошивки дока. Маркетингові назви брешуть.

Виправлення: Таргетуйте за hardware ID. Розділіть кільця за патернами device instance. Інвентаризуйте версії BIOS/прошивки поряд із версіями драйверів.

3) «Після сну Wi‑Fi зникає до перезавантаження»

Симптом: Адаптер мережі зникає або не може перепідключитись після Modern Standby.

Корінь: Баг у станах живлення NIC, агресивне енергозбереження або взаємодія з доком/USB-хабом.

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

4) «Boot loop після оновлення драйвера»

Симптом: Перезавантаження або BSOD на ранніх етапах завантаження; може показувати INACCESSIBLE_BOOT_DEVICE.

Корінь: Збій boot-start драйвера (сховище/чіпсет) або конфлікт фільтр-драйвера в шляху сховища.

Виправлення: Офлайн-видалення драйвера через WinRE + DISM. Координуйте зміни драйверів сховища з оновленнями шифрування/AV фільтрів.

5) «Сховище повільне і випадкові застосунки зависають, але диск не «падає»»

Симптом: Інколи стаються затримки, зависання UI, спорадичні I/O таймаути.

Корінь: Скиди storport (Event 129/153), особливості прошивки NVMe або фільтр-драйвер, що додає затримок.

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

6) «Оновлення GPU виправило один додаток, але зламало конференції»

Симптом: Артефакти в Teams/Zoom, миготіння зовнішніх моніторів або апаратне прискорення спричиняє падіння.

Корінь: Зміни у GPU-драйвері щодо кодеків, станів живлення або оверлеїв; іноді взаємодія з доком і дисплей-драйверами.

Виправлення: Стаджуйте GPU-драйвери за апаратурою і групами користувачів з доками. Тримайте відомо-ґуд драйвер. Уникайте одночасних OS feature update і GPU-апдейтів.

7) «Новий драйвер не інсталюється; він каже, що не сумісний»

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

Корінь: Неправильний INF для hardware ID, ранжування драйверів вибирає інший кандидат або безпекові фічі блокують старі драйвери.

Виправлення: Підтвердіть device instance ID і привʼязку драйвера за допомогою pnputil /enum-devices; перевірте підпис і сумісність; не форсуйте «майже підходящий» пакет.

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

Покроково: побудуйте програму оновлення драйверів (практично, не амбіційно)

1. Виберіть єдину площину контролю для затвердження драйверів (WSUS/ConfigMgr або Intune). Документуйте процес винятків.
2. Визначте членство в кільцях з реальною різноманітністю пристроїв (різні моделі, доки, постачальники SSD, чіпсети Wi‑Fi, power users).
3. Встановіть ритм: щомісячно для «безпечних» драйверів (наприклад, рекомендовані вендором фікси безпеки), щоквартально для решти, з аварійним шляхом.
4. Базове інвентарне знімання: модель, BIOS, прошивка SSD якщо доступна, ключові версії драйверів, фільтр-драйвери.
5. Створіть ескроу: тримайте новий пакет драйвера і попередній відомо-ґуд пакет доступними для швидкого розгортання і відкату.
6. Напишіть runbook відкату: онлайн відкат, офлайн відкат (WinRE + DISM), нюанси BitLocker і хто може давати дозвіл.
7. Визначте гейти: пороги bugcheck, пороги попереджень storport, події NIC reset, теги звернень у службу підтримки.
8. Розгорніть у Ring 1 і чекайте достатньо часу, щоб включити сон/пробудження і звичні робочі сценарії.
9. Розгорніть у Ring 2 з таргетингом за hardware ID, а не просто «модель».
10. Пауза і ревʼю перед широким розгортанням. Якщо ви не можете чітко сформулювати сигнали — ви не готові рухатись далі.
11. Широке розгортання з аварійною зупинкою і чітким планом комунікації.
12. Після-розгортання аудит: підтвердьте версії, переконайтесь, що Windows Update не повертає заблоковані пакети, і задокументуйте отримані уроки.

Передвпроваджувальний чекліст (пакет драйвера)

• Підтверджені hardware ID, що відповідають INF (жодного «достатньо близько»).
• Підпис драйвера перевірено і сумісний з вашою безпековою позицією.
• Встановлення і видалення протестовані мінімум на двох апаратних варіантах.
• Пакет відкату підготовлений і перевірений.
• Відомі конфліктні драйвери визначені (фільтри, VPN, агенти кінцевої точки) і вікна змін скоординовані.
• Підготовлені запити телеметрії (bugchecks, події storport, скиди NIC).

Чекліст екстреної відповіді (регресія драйвера)

• Негайно призупинити затвердження/кільця.
• Визначити границю поганої версії (good vs bad driver versions).
• Визначити уражені hardware ID і моделі.
• Відкотити Ring 1 і 2 першими, щоб валідувати міру помʼякшення.
• Видалити поганий пакет з driver store там, де потрібно, щоб запобігти перевстановленню.
• Повідомити простий обхідний шлях користувачу, якщо релевантно (наприклад: вимкнути Wi‑Fi, використовувати Ethernet; уникати сну).
• Задокументувати інцидент з доказами: логи, версії і кроки відтворення.

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

1) Чи варто дозволяти Windows Update автоматично інсталювати драйвери?

Для некерованих споживчих ПК: зазвичай можна. Для підприємств: за замовчуванням — ні, якщо у вас немає поетапного розгортання і історії відкату.
Несподівані драйвери — це обхід управління змінами.

2) Чи безпечні OEM-утиліти (на кшталт апдейтерів вендорів) для масштабного запуску у фліті?

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

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

Пакет (INF + CAT + SYS та супутні файли) — це те, що Windows інсталює і зберігає в driver store.
Бінарник — це фактичний .sys, який завантажує ядро. Ви керуєте пакетами; Windows завантажує бінарники з них.

4) Чому Windows іноді вибирає інший драйвер, ніж той, який ми запакували?

Ранжування і підбір драйверів можуть вибрати більш високорейтингового кандидата, якщо кілька пакетів підходять за device ID або compatible ID.
Ось чому важливі таргетинг за hardware ID і контроль того, що є в driver store.

5) Коли варто оновлювати драйвери сховища?

Коли є виправлення безпеки, виправлення стабільності, релевантне для вашого апаратного забезпечення, рекомендація вендора, повʼязана з вашою прошивкою, або відома помилка, з якою ви стикаєтесь.
Не оновлюйте драйвери сховища тільки через наявність новішої версії. Так ви підписуєтесь на проблеми з boot.

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

Не завжди. Для регресій продуктивності і зникнення пристроїв можуть вистачити журнали подій і кореляція версій.
Для повторюваних BSOD дампи — найшвидший шлях визначити faulting module і припинити суперечки.

7) А що з «необовʼязковими» оновленнями драйверів у Windows Update?

«Необовʼязкове» означає «не примусове», а не «безпечне». Трактуйте їх як пакети, що все одно потребують кілець і гейтів.
Optional — ярлик UI, а не гарантія надійності.

8) Як утримати відновлений драйвер від повторної інсталяції?

Видаліть поганий пакет з driver store (pnputil /delete-driver) і блокуйте доставку драйверів через Windows Update, де потрібно.
Також переконайтесь, що ваше управління не перевстановлює новіший пакет.

9) Яка найпоширеніша причина «випадкової повільності», повʼязана з драйверами?

Таймаути і скиди сховища (storport warnings) та регресії NIC offload.
Вони не завжди падають; вони просто марнують час — ваш і CPU.

10) Чи можна все це зробити без Intune/ConfigMgr/WSUS?

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

Наступні кроки, які можна зробити цього тижня

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

1. Зробіть інвентар ключових драйверів (сховище, NIC, GPU) по фліту і збережіть вихід у доступному для запитів місці.
2. Виберіть кільця і назвіть людей у Ring 1. Зробіть це за згодою, а не як сюрприз.
3. Вимкніть несподівану доставку драйверів, де вона конфліктує з вашими вікнами змін, і маршрутуйте драйвери через ваші затвердження.
4. Напишіть runbook відкату і протестуйте його на одній «жертовній» машині: онлайн відкат плюс офлайн DISM-видалення.
5. Реалізуйте ескроу пакетів: тримайте поточні і попередні відомо-ґуд пакети, індексовані за hardware ID і published names.
6. Визначте два гейти: «без збільшення BSOD» і «без нових кластерів скидів storport». Далі додавайте критерії в міру дорослішання процесу.

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