Коди синього екрану: швидкий спосіб звузити причину

Як насправді працюють BSOD (і чому код зупинки — лише заголовок)

Синій екран смерті — це рішення Windows, що найбезпечніше, що вона може зробити, — зупинитися. Це звучить драматично, але часто правильно: продовження могло б пошкодити пам’ять, зіпсувати дані на диску або зафіксувати ядро в стані, що перешкоджає відновленню. Суть у тому, що BSOD — це контрольований краш. Windows фіксує стан (якщо налаштовано), виводить код зупинки і перезавантажується (якщо налаштовано). Ваше завдання — витягти й інтерпретувати те, що вона зафіксувала.

Код зупинки проти bugcheck і параметрів

На екрані ви бачите код зупинки, наприклад IRQL_NOT_LESS_OR_EQUAL або WHEA_UNCORRECTABLE_ERROR. Під капотом це — «bugcheck» з числовим кодом (наприклад 0xA або 0x124) та чотирма параметрами. Ці параметри важливі. Вони часто вказують на адресу, рівень IRQL або тип структури даних — речі, які кажуть вам, чи маєте ви справу з неправильним указівником від драйвера, помилкою CPU machine check або тим, що шлях сховища повертає некоректні дані.

Дампи аварій: міні, kernel, complete

Дампи аварій — ваш «реєстратор чорних скриньок». «Міні»-дамп — як свідчення: корисний, але неповний. Kernel-дампи зазвичай містять достатньо інформації, щоб ідентифікувати проблемні драйвери та стек викликів. Complete-дампи величезні й часто неприйнятні на серверах із великою ОЗП — до того ж у них може міститися чутлива інформація. Якщо ви працюєте в продакшні на Windows, моя упереджена але перевірена рекомендація: kernel dump, якщо немає конкретної причини інакше.

Дві класи відмов: програма «зібрехала» ядру проти апаратури

Більшість BSOD зводиться до двох істин:

• Програма «збрехала» ядру: драйвер звернувся до недійсної пам’яті, використав звільнену пам’ять, пошкодив пул або порушив правила IRQL. Це часто відтворювані проблеми і часто спрацьовують при завантаженні або на певному шляху пристрою.
• Апаратне забезпечення «збрехало» ядру: біти в ОЗП, CPU machine checks, помилки PCIe, сховище повертає брудні дані або нестабільне живлення. Такі помилки можуть виглядати «випадковими» і часто залежать від часу або температури/навантаження.

Цитата, яка має переслідувати ваш канал інцидентів

Надія — не стратегія. — Gene Kranz

Цікаві факти та історичний контекст (бо минуле формує ваше нинішнє пекло)

• «Синій екран» — це не просто маркетинг: ранні Windows NT використовували екрани зупинки як поверхню для відлагодження помилок ядра, розраховану на адміністраторів, а не кінцевих користувачів.
• Ера «сумного обличчя»: у Windows 8+ з’явилися дружніші екрани зупинки, але механіка ядра не стала дружнішою — лише інтерфейс користувача.
• WHEA змінило правила гри: Windows Hardware Error Architecture стандартизувала звітування апаратних помилок (CPU, PCIe, пам’ять), зробивши 0x124 поширеним «апаратно-орієнтованим» кодом зупинки.
• Підпис драйверів колись був нестрогий: у старих екосистемах допустиміші драйвери ядра; сучасний Windows посилив правила, але старі постачальники ще винахідливі.
• NTFS має власну мову відмов: коди зупинки на кшталт NTFS_FILE_SYSTEM часто означають, що файлова система наткнулась на те, чого відмовляється інтерпретувати — іноді корупція, іноді шлях сховища, що повернув нісенітницю.
• «Kernel-Power 41» не є коренем проблеми: це визнання Windows, що воно несподівано перезавантажилося, а не пояснення чому. Це запис симптома, а не діагноз.
• За замовчуванням minidump-установки еволюціонували: багато систем налаштовані на малі дампи, які зручні, але лишають вас сліпими, коли стек ушкоджений.
• Віртуалізація додає новий рівень звинувачень: гіпервізори можуть приховувати апаратну поведінку; ваш «апаратний BSOD» може бути проблемою хоста, сховищної мережі або віртуального драйвера пристрою.

Короткий жарт, як обіцяно та дозовано: BSOD — це Windows, що каже: «Я б із задоволенням допомогла, але вирішила стати скріншотом.»

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

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

Перше: класифікуйте крах з мінімальними зусиллями

1. Отримайте код зупинки і часову мітку (фото, журнал подій, метадані дампа).
2. Перевірте, чи повторюється: той самий код зупинки, той самий драйвер, та сама машина, та сама операція?
3. Пошукайте очевидні недавні зміни: оновлення Windows, оновлення драйверів, оновлення прошивки, новий агент захисту кінцевої точки, нові налаштування мультипатингу сховища.

Рішення: Якщо код зупинки — WHEA (0x124) або CLOCK_WATCHDOG_TIMEOUT, вважайте це «апарат/прошивка/живлення, доки не доведено протилежне». Якщо це DRIVER_IRQL_NOT_LESS_OR_EQUAL або SYSTEM_SERVICE_EXCEPTION — вважайте це «драйвер/ПЗ, доки не доведено протилежне».

Друге: збирайте докази перед тим, як «щось пробувати»

1. Переконайтеся, що дампи існують: Minidump або MEMORY.DMP.
2. Експортуйте журнали подій навколо краху: System + Application, і журнали WHEA, якщо є.
3. Зафіксуйте контекст сховища + пам’яті + прошивки: стан диска, помилки контролера, версії BIOS/UEFI, останні зміни конфігурації.

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

Третє: ізолюйте ймовірну доменну область (драйвери проти апаратури проти шляху сховища)

1. Запустіть швидкий аналіз дампа для модуля «ймовірно спричинив» і параметрів bugcheck.
2. Перевірте сигнали сховища та файлової системи: помилки диска, скидання контролера, попередження NTFS, таймаути StorPort.
3. Проведіть стрес-тест або валідацію апаратури: діагностику пам’яті, перевірте мікрокод/BIOS CPU, перегляньте деталі WHEA.

Рішення: Якщо сховище показує таймаути/скидання або NTFS скаржиться навколо краху, перемикайте увагу на контролер/прошивку/кабелі/шлях — навіть якщо код зупинки каже «управління пам’яттю». Неправильне I/O може проявлятися як симптоми корупції пам’яті, бо драйвери і кеші обробляють «брудні» дані.

Коди зупинки за категоріями: найшвидший спосіб класифікувати

Не треба заучувати 200 кодів зупинки. Розбивайте їх на корзини. Мета — не тривіа; це звуження радіусу ураження.

Корзина A: «Драйвер зробив щось незаконне»

Типові коди зупинки:

• IRQL_NOT_LESS_OR_EQUAL (0xA): драйвер торкнувся pageable-пам’яті на високому IRQL або звернувся до неправильного указівника.
• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1): схоже, але більш явно пов’язано з драйвером.
• SYSTEM_SERVICE_EXCEPTION (0x3B): виключення в системній службі; часто драйвер, графіка або інструменти безпеки, що підключаються до системних викликів.
• KMODE_EXCEPTION_NOT_HANDLED (0x1E): виняток в режимі ядра, який не був оброблений; часто баг драйвера.
• PAGE_FAULT_IN_NONPAGED_AREA (0x50): спроба доступу до недійсної пам’яті; може бути драйвер, ОЗП або корупція підкачки на диску.

Швидка думка: Якщо дамп вказує на сторонній драйвер і крахи почалися після оновлення — у вас є головний підозрюваний. Не ускладнюйте просте.

Корзина B: «Пошкодження пам’яті та пулу»

Типові коди зупинки:

• MEMORY_MANAGEMENT (0x1A)
• PFN_LIST_CORRUPT (0x4E)
• BAD_POOL_CALLER (0xC2)
• DRIVER_CORRUPTED_EXPOOL (0xC5)

Швидка думка: Пошкодження пам’яті — це категорія, а не причина. Це може бути баг драйверів, несправна ОЗП, нестабільні розгони (так, і в корпоративних десктопах), або проблеми DMA/PCIe.

Корзина C: «Шлях сховища та файлова система незадоволені»

Типові коди зупинки:

• INACCESSIBLE_BOOT_DEVICE (0x7B): пристрій завантаження недоступний. Часто драйвер контролера сховища, зміна режиму BIOS, BitLocker або відмова диска.
• UNEXPECTED_STORE_EXCEPTION (0x154): звучить як проблема сховища, тому такою й є; часто стек сховища, диск або фільтруючі драйвери.
• KERNEL_DATA_INPAGE_ERROR (0x7A): помилка читання сторінки. Таймаути сховища, погані сектори, помилки контролера, іноді ОЗП.
• NTFS_FILE_SYSTEM (0x24): NTFS натрапив на корупцію або отримав недійсні дані; часто пов’язано з диском або фільтруючим драйвером.
• FAT_FILE_SYSTEM (0x23): та сама ідея для томів FAT (менш поширено на сучасних системах, але трапляється з переносними носіями).

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

Корзина D: «Апаратне забезпечення/прошивка крикнули»

Типові коди зупинки:

• WHEA_UNCORRECTABLE_ERROR (0x124): апаратна помилка, зафіксована через WHEA. Кеш CPU, контролер пам’яті, PCIe, іноді NVMe.
• CLOCK_WATCHDOG_TIMEOUT (0x101): ядро процесора не відповіло на переривання; може бути проблемою BIOS, мікрокоду, живлення, розгону чи віртуалізаційних нюансів.
• MACHINE_CHECK_EXCEPTION (0x9C): старіший варіант звітування машинної перевірки апаратури.

Швидка думка: Якщо ви бачите 0x124, припиняйте перевстановлювати Windows. Ви лікуєте отруєння диму новим шпалером.

Корзина E: «Безпека/віртуалізація і глибокі функції ядра»

Типові коди зупинки:

• HYPERVISOR_ERROR (0x20001) або суміжні: стек віртуалізації незадоволений; можуть бути проблеми хоста або баги в функціях віртуалізації.
• SECURE_KERNEL_ERROR: проблеми VBS / HVCI / secure kernel; часто несумісність драйверів.
• CRITICAL_PROCESS_DIED (0xEF): критичний процес у користувацькому режимі завершився; це може бути корупція сховища, шкідливе ПЗ, пошкоджене оновлення або драйвери, що руйнують пам’ять.

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

Докази, які потрібні перед тим, як «щось виправляти»

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

Що ви мусите зафіксувати

• Код зупинки + будь-яке відображене на екрані ім’я драйвера (іноді показується).
• Дампи: minidump(и) та/або MEMORY.DMP.
• Журнали подій навколо часу краху: System, Application, Setup і журнали WHEA, якщо є.
• Знімок інвентарю апаратури: версія BIOS, модель/драйвер контролера сховища, прошивка NVMe, конфігурація ОЗП.
• Журнал змін: оновлення, нові драйвери, нові фільтри драйверів, нові пристрої, зміни політик.

Ще одна річ: налаштуйте дампи як слід

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

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

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

Завдання 1: Підтвердити останній bugcheck-код і параметри (Event Viewer через CLI)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=1001)]]" /f:text /c:3
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WER-SystemErrorReporting
  Date: 2026-02-05T02:14:22.0000000Z
  Event ID: 1001
  Task: None
  Level: Error
  Keyword: Classic
  User: N/A
  Computer: WS-ACCT-014
  Description:
The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000124 (0x0000000000000000, 0xffffb10f7f3f1028, 0x00000000b2000000, 0x0000000000000031). A dump was saved in: C:\Windows\MEMORY.DMP.

Що це значить: У вас є код bugcheck (0x124) і параметри, плюс місце збереження дампа.

Рішення: 0x124 → пріоритет апаратури/прошивки/PCIe/шляху сховища перед марафонами перевстановлення драйверів.

Завдання 2: Перевірити, чи Windows створив дамп-файл

cr0x@server:~$ dir C:\Windows\Minidump
 Volume in drive C has no label.
 Directory of C:\Windows\Minidump

02/05/2026  02:14 AM           1,024,512 020526-13281-01.dmp
               1 File(s)      1,024,512 bytes

Що це значить: Існує minidump для мітки часу краху.

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

Завдання 3: Перевірити конфігурацію дампів (щоб майбутні крахи були корисними)

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    CrashDumpEnabled    REG_DWORD    0x2

Що це значить: 0x2 зазвичай означає kernel memory dump. Це добре для більшості продакшн-діагностик.

Рішення: Тримайте kernel dumps, якщо тільки обмеження дискового простору або приватності не змушують використовувати minidumps; уникайте «none», якщо вам подобається налагодження в сліпу.

Завдання 4: Підтвердити наявність і розмір pagefile (дампи залежать від нього)

cr0x@server:~$ wmic pagefile list /format:list
AllocatedBaseSize=16384
CurrentUsage=512
Description=C:\pagefile.sys
InstallDate=20260101000000.000000+000

Що це значить: Існує pagefile. Створення дампів часто залежить від конфігурації pagefile, особливо для kernel/complete дампів.

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

Завдання 5: Витягнути останні записи про несподівані вимкнення (контекст Kernel-Power 41)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=41)]]" /f:text /c:2
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-Kernel-Power
  Date: 2026-02-05T02:14:20.0000000Z
  Event ID: 41
  Level: Critical
  Description:
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Що це значить: Підтверджує, що було нечисте вимкнення; але не пояснює причини.

Рішення: Використайте це як часову мітку; не зупиняйтеся на цьому і не оголошуйте перемогу.

Завдання 6: Перевірити події WHEA для деталей апаратної помилки

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /f:text /c:3
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WHEA-Logger
  Date: 2026-02-05T02:13:58.0000000Z
  Event ID: 18
  Level: Error
  Description:
A fatal hardware error has occurred.
Reported by component: Processor Core
Error Source: Machine Check Exception
Error Type: Cache Hierarchy Error
Processor APIC ID: 6

Що це значить: Це узгоджується з 0x124 і вказує на помилку ієрархії кешу CPU на певному ядрі.

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

Завдання 7: Перевірити попередження/помилки, пов’язані зі сховищем, навколо часу краху

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129 or EventID=153 or EventID=7 or EventID=11)]]" /f:text /c:5
Event[0]:
  Log Name: System
  Source: storahci
  Date: 2026-02-05T02:12:44.0000000Z
  Event ID: 129
  Level: Warning
  Description:
Reset to device, \Device\RaidPort0, was issued.

Що це значить: Скидання StorPort — класичний знак таймаутів сховища, проблем контролера, кабелювання або проблем прошивки.

Рішення: Якщо ви бачите сплески 129/153 біля краху, вважайте шлях сховища підозрілим. Оновіть прошивку контролера/NVMe, перевірте SMART і перегляньте налаштування енергозбереження.

Завдання 8: Швидко переглянути SMART-диска

cr0x@server:~$ wmic diskdrive get model,status
Model                            Status
NVMe SAMSUNG MZVL21T0HCLR-00B00   OK
ST2000DM008-2FR102                Pred Fail

Що це значить: Один диск повідомляє «Pred Fail». Це не натяк.

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

Завдання 9: Перевірити цілісність файлової системи (онлайн-скан)

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
  512000 file records processed.
Stage 2: Examining file name linkage ...
  640000 index entries processed.
Windows has scanned the file system and found no problems.
No further action is required.

Що це значить: Метадані NTFS виглядають цілісними на високому рівні.

Рішення: Якщо журнали сховища показують скидання, але CHKDSK чистий, підозрюйте переривисті I/O або скидання контролера, а не статичну корупцію.

Завдання 10: Перевірити цілісність системних файлів (SFC), коли підозрюють корупцію ПЗ

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.

Що це значить: Файли ОС цілісні.

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

Завдання 11: Перевірити стан образу Windows (DISM) після невдалих оновлень

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.4046

No component store corruption detected.
The operation completed successfully.

Що це значить: Сховище компонентів у порядку.

Рішення: Не робіть «nuke-and-pave», щоб «полагодити Windows», якщо стан обслуговування добрий. Використовуйте дамп, щоб знайти реального винуватця.

Завдання 12: Перелічити нещодавно інстальовані драйвери (швидка кореляція змін)

cr0x@server:~$ pnputil /enum-drivers | findstr /i "Published Name Provider Class Date"
Published Name : oem42.inf
Driver package provider : Contoso Security
Class : System
Driver date and version : 01/28/2026 4.2.19.0
Published Name : oem17.inf
Driver package provider : Intel
Class : Net
Driver date and version : 01/10/2026 12.19.2.45

Що це значить: Ви можете помітити нові компоненти рівня ядра — агенти безпеки та фільтри сховища часто спричиняють крахи.

Рішення: Якщо крахи почалися після встановлення конкретного драйвера, протестуйте відкат або оновлення. Не «оновлюйте все» одразу; ви знищите причинно-наслідкові зв’язки.

Завдання 13: Перевірити завантажені драйвери в рантаймі (виявити фільтри)

cr0x@server:~$ driverquery /v /fo table | findstr /i "flt stor nvme av"
WdFilter           File System    0x00000000  Running  Microsoft Corporation
storahci           SCSIAdapter     0x00000000  Running  Microsoft Corporation
stornvme           SCSIAdapter     0x00000000  Running  Microsoft Corporation
ContosoEDR         Kernel          0x00000000  Running  Contoso Security

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

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

Завдання 14: Швидко зібрати системну інформацію для ескалації

cr0x@server:~$ systeminfo | findstr /i "OS Name OS Version System Type BIOS Version"
OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19045 N/A Build 19045
System Type:               x64-based PC
BIOS Version:              American Megatrends Inc. 1.22, 11/14/2025

Що це значить: Ви можете зіставити вік BIOS з відомими виправленнями стабільності (мікрокод, PCIe, NVMe нюанси).

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

Завдання 15: Запустити Windows Memory Diagnostic (коли запахне корупцією пам’яті)

cr0x@server:~$ mdsched.exe
Windows Memory Diagnostic has been started. Please save your work and reboot.

Що це значить: Це планує тест пам’яті під час наступного перезавантаження.

Рішення: Використовуйте як базовий тест. Для наполегливих проблем робіть розширене тестування і розгляньте заміну модулів ОЗП або тестування по одному DIMM.

Завдання 16: Увімкнути Driver Verifier вибірково (щоб зловити погані драйвери)

cr0x@server:~$ verifier /standard /driver ContosoEDR.sys
Verifier was started.

Що це значить: Driver Verifier навантажить цей драйвер, і він раніше впаде, якщо порушує правила.

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

Другий короткий жарт, також дозовано: Driver Verifier — це як увімкнути світло о 2 ранку — вам може не сподобатися те, що побачите, але воно пояснить шум.

Три корпоративні міні-історії (що насправді відбувається)

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

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

Новий SRE зайшов і поставив нудне питання: «Чи є у нас скидання StorPort у системному журналі?» Виявилося, що так — Event ID 129, зібрані перед кожним крахом. Ніхто не пов’язував це, бо коди зупинки не кричали «сховище», а сервери чисто перезавантажувалися.

Вони зняли SMART-дані. Там не було явних сигналів відмови, що дало помилкове відчуття безпеки. Але прошивка контролера сховища була двохрічної давності, і існували відомі проблеми з таймаутами під високою чергою. Середовище тихо змінилося: резервні копії були оптимізовані для швидшої роботи, що спричинило більшу I/O-паралельність ночами.

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

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

Інженерна команда десктопів захотіла швидшого завантаження і меншого зношування диска на ноутбуках. Вони впровадили політику: вимкнути pagefile на машинах зі SSD, бо «в нас достатньо ОЗП». Це виглядало добре в дашборді: менше дискової активності, трохи швидше відновлення і краща батарея.

Але потім почалися сині екрани. Не на всіх машинах — лише на тих, що запускали важкі додатки, віртуалізацію або активний агент захисту. Коди зупинки були різні: PAGE_FAULT_IN_NONPAGED_AREA, SYSTEM_SERVICE_EXCEPTION і іноді KERNEL_DATA_INPAGE_ERROR. Команда ганялася за драйверами і оновленнями тижнями.

Корінь проблеми був механічно болючий: без pagefile (або з недостатнім) генерація дампів стала ненадійною, і поведінка при тиску пам’яті змінилася. Системи, що потрапляли в певні шляхи відмов, не могли записати корисний дамп. Інженери оптимізували власний реєстратор чорних скриньок.

Відновлення системного керованого pagefile і встановлення kernel dumps одразу стабілізували спостережуваність. Це не вирішило конфлікти драйверів, але перетворило «випадкові BSOD» на дієвий аналіз аварій. Оптимізація не була злою; вона була необмеженою. Правило для продакшну: не оптимізуйте діагностичні інструменти з системи.

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

Фінансовий відділ мав кластер серверів додатків Windows зі суворим контролем змін. Нічого гламурного. Кожне оновлення драйвера проходило етапи. Оновлення прошивки мали календар. Налаштування дампів ядра були стандартизовані. Хтось навіть задокументував точні кроки експорту журналів подій і копіювання дампів після краху.

Одної п’ятниці вночі вузол перезавантажився з BSOD. Інженер на виклику не імпровізував. Він пройшов чекліст: скопіювати MEMORY.DMP, експортувати системний журнал навколо мітки часу, записати останні зміни. До приходу старшого інженера докази вже були в тікеті.

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

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

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

Цей розділ навмисно конкретний. Узагальнені поради спричиняють узагальнені відмови.

1) Симптом: «Kernel-Power 41 повторюється»

Корінь проблеми: Ця подія лише фіксує нечисте вимкнення. Це може бути BSOD, втрата живлення, watchdog reset або жорстка зависання.

Виправлення: Зіставте з Event ID 1001 bugcheck-записами, шукайте дампи і перевіряйте WHEA/StorPort події навколо того самого часу.

2) Симптом: Minidumps відсутні, хоча машина злітала в BSOD

Корінь проблеми: Дампи відключені, pagefile відсутній/занадто малий, диск заповнений або інструменти очищення видаляють дампи.

Виправлення: Налаштуйте kernel dumps, переконайтеся, що pagefile на завантажувальному томі, перевірте вільне місце й виключіть директорії дампів з політик очищення.

3) Симптом: PAGE_FAULT_IN_NONPAGED_AREA після оновлення драйвера

Корінь проблеми: Драйвер звертається до недійсної пам’яті або фільтр-конфлікт між драйверами (AV/EDR/backup/шифрування).

Виправлення: Відкотіть або оновіть драйвер; використайте Driver Verifier вибірково, щоб змусити детермінований крах з іменем підозрюваного.

4) Симптом: WHEA_UNCORRECTABLE_ERROR із подіями «Processor Core»

Корінь проблеми: Машинна перевірка CPU: температури, баги мікрокоду/BIOS, нестабільне живлення або несправне кремнієве ядро.

Виправлення: Оновіть BIOS/UEFI та драйвери чіпсета, перевірте охолодження і подачу живлення, вимкніть розгін/недовольтаження та замініть апарат, якщо повторюється.

5) Симптом: KERNEL_DATA_INPAGE_ERROR або NTFS_FILE_SYSTEM під час інтенсивного I/O

Корінь проблеми: Таймаути сховища, погані сектори, скидання контролера, проблеми кабелів/бекплейну або баги фільтруючих драйверів сховища.

Виправлення: Шукайте патерни Event ID 129/153/7/11, перевірте SMART, оновіть прошивку/драйвери сховища і видаліть або оновіть фільтри.

6) Симптом: INACCESSIBLE_BOOT_DEVICE після зміни BIOS або «швидкої правки»

Корінь проблеми: Змінився режим SATA (AHCI/RAID), стан BitLocker, відсутні драйвери контролера або пошкоджене відображення завантажувального тому.

Виправлення: Поверніть режим сховища в BIOS до попереднього; переконайтеся в коректних драйверах; перевірте ключі відновлення BitLocker і конфігурацію завантаження.

7) Симптом: SYSTEM_SERVICE_EXCEPTION після ввімкнення функцій безпеки віртуалізації

Корінь проблеми: Несумісні драйвери ядра з VBS/HVCI; драйвери виконують непідтримувані операції з пам’яттю.

Виправлення: Оновіть або замініть несумісні драйвери; тестуйте розгортання функцій безпеки в кількох кільцях, а не одразу всюди.

8) Симптом: «Ми замінили ОЗП, і проблема лишається»

Корінь проблеми: Пошкодження пам’яті не завжди в ОЗП. PCIe DMA, сховище, що повертає корумповані сторінки, або драйвер, що «писав» пам’ять, можуть виглядати однаково.

Виправлення: Використайте стек-аналіз дампа + Driver Verifier + кореляцію помилок сховища. Замінюйте деталі на основі доказів, а не фрустрації.

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

Чекліст A: Перші 15 хвилин після BSOD (окрема машина)

1. Зафіксуйте код зупинки і час краху (фото або запис у тікеті).
2. Підтвердіть наявність дампів у C:\Windows\Minidump та/або C:\Windows\MEMORY.DMP.
3. Скопіюйте дампи в безпечне місце, перш ніж перезавантаження/очищення їх перезапишуть.
4. Експортуйте системний журнал подій навколо краху (±30 хвилин).
5. Перевірте WHEA-Logger і події скидання сховища (129/153/7/11).
6. Зберіть зміни інвентарю драйверів (останні інсталяції/оновлення).
7. Вирішіть у яку корзину віднести: драйвер, сховище, WHEA/апаратура чи безпека/віртуалізація.

Чекліст B: Якщо код зупинки «пахне» сховищем

1. Шукайте скидання StorPort і помилки диска поблизу краху.
2. Перевірте SMART і інструменти вендора для стану носія, якщо доступні.
3. Перевірте кабель/бекплейн на фізичному сервері; перевірте налаштування енергозбереження лінку на ноутбуці.
4. Перегляньте фільтруючі драйвери сховища (бекап, AV/EDR, шифрування, інструменти снапшоту).
5. Оновлюйте драйвер контролера сховища і прошивку свідомо (по одному зміненню).
6. Якщо це файловий сервер: перевірте, чи збігаються крахи з роботами бекапу, антивірусу або дедуплікації.

Чекліст C: Якщо це WHEA/апарат

1. Витягніть деталі подій WHEA (компонент, тип помилки, APIC ID).
2. Перевірте версії BIOS/UEFI та драйверів чіпсета і відомі нотатки про стабільність.
3. Валідуйте термальні умови і живлення (вентилятори, пил, температури VRM, батарея/блок живлення).
4. Вимкніть розгін/недовольтаження і будь-які профілі «прискорення продуктивності».
5. Запустіть діагностику пам’яті; при необхідності пересадіть модулі ОЗП у серверах.
6. Якщо повторюється з тією ж підпискою: плануйте заміну апаратури замість нескінченного софтверного шуму.

Чекліст D: Якщо ймовірно драйвер

1. Синхронізуйте час початку краху з інсталяціями драйверів і оновленнями Windows.
2. Ідентифікуйте сторонні драйвери ядра в стеку (EDR, VPN, сховище, GPU).
3. Відкотіть найбільш підозрілий драйвер (контрольований тест, не на всіх машинах одразу).
4. Увімкніть Driver Verifier вибірково для підозрюваних драйверів (вікно обслуговування).
5. Коли Verifier виявить винуватця: видаліть/оновіть його, потім вимкніть Verifier.
6. Документуйте точні поєднання версій, які стабільні.

Часті питання

1) Чи достатньо коду зупинки, щоб виправити проблему?

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

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

Корупція пам’яті та таймаути I/O можуть каскадувати. Перша помилка псує стан; пізніший код ловить пошкодження і видає інший bugcheck. Зосередьтеся на ранніх попередженнях (скидання сховища, події WHEA) і на стеку дампа.

3) У чому різниця між WHEA_UNCORRECTABLE_ERROR і крахом драйвера?

WHEA (0x124) — це повідомлення Windows про апаратну помилку, що виявлена платформою (CPU/PCIe/контролер пам’яті/NVMe). Краші драйверів (0xD1/0xA/0x3B) зазвичай означають, що програмне забезпечення порушило правила ядра. Обидва можуть перетинатися, але WHEA — це сирена «спочатку підозрюйте апаратне».

4) Де зберігаються minidump-и?

Зазвичай у C:\Windows\Minidump. Kernel/complete дампи зазвичай у C:\Windows\MEMORY.DMP. Якщо їх немає — перевірте налаштування дампів і конфігурацію pagefile.

5) Чи варто вимкнути автоматичне перезавантаження при BSOD?

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

6) Чи може несправний диск спричинити «пам’ятні» коди зупинки?

Абсолютно. Підкачка залежить від сховища; стеки сховища і фільтри працюють у просторі ядра; корумповані читання можуть отруїти кеші. Якщо ви бачите скидання/таймаути диска поруч із крахом, вважайте сховище частиною аналізу кореня проблеми, навіть якщо код зупинки каже «пам’ять».

7) Чи безпечний Driver Verifier?

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

8) Чому CHKDSK не показує проблем, але я все одно отримую BSOD, пов’язані з NTFS?

Тому що переривисті таймаути I/O і скидання контролера не обов’язково залишають сталу корупцію на диску. NTFS може падати, коли отримує несподівані помилки або неконсистентні дані під час операції, навіть якщо метадані здаються чистими при скануванні.

9) Коли підозрювати прошивку?

Коли у вас є події WHEA, скидання сховища, помилки NVMe або крахи, що корелюють зі специфічними станами живлення (сон/відновлення) або високою чергою I/O. BIOS, прошивка NVMe і прошивка контролера часто виправляють реальні баги — іноді непомітно, іноді драматично.

10) Який найшвидший шлях довести, що це агент безпеки на кінцевій точці?

Синхронізуйте дату/версію встановлення драйвера з початком краху, ідентифікуйте драйвер ядра в переліку завантажених модулів і використайте Verifier (або контрольований тест деінсталяції) на невеликому кільці. Не виривайте його звідусіль без доказів; зберіть докази швидко.

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

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

Зробіть це далі

1. Стандартизувати налаштування дампів (kernel dumps, надійний pagefile, збереження дампів).
2. Побудувати 15-хвилинний рутин тріажу: код зупинки + дамп + експорт системного журналу + скан WHEA/сховища.
3. Розподілити код зупинки по корзинах (драйвер проти сховища проти апаратури/WHEA проти безпеки/віртуалізації).
4. Зробити одну контрольовану зміну на основі доказів: відкат драйвера, оновлення прошивки, заміна диска або ізоляція фільтруючого драйвера.
5. Закрити цикл: задокументувати підпис (bugcheck + проблемний модуль + тригер), щоб наступний on-call не винаходив те саме о 3 ранку.

Якщо ви нічого не візьмете з цього: ставтеся до кожного BSOD як до інциденту з судовою експертизою. Код зупинки — це заголовок; дамп — історія; журнали — чеки. Збирайте чеки.