Event Viewer для людей: знайдіть реальні помилки за 5 хвилин

П’ятихвилинне мислення (те, що ви насправді шукаєте)

Ваше завдання в Event Viewer — не читати логи. Ваше завдання — прийняти рішення в умовах невизначеності. Конкретно, ви намагаєтесь відповісти на чотири питання:

1. Що змінилось? (оновлення, драйвер, сертифікат, політика, шлях зберігання, синхронізація часу, права облікового запису.)
2. Коли це почалось? (корелюйте з розгортанням/перезавантаженням/вікном бекапу/патчуванням.)
3. Який компонент впав першим? (помилки сховища часто передують краху додатку; відмови автентифікації передують зупинці сервісів.)
4. Це реальна помилка чи фонове скарження? (деякі «помилки» — просто драматична поведінка Windows.)

Event Viewer підводить людей, бо вони вважають усі червоні іконки однаково важливими. Не робіть так. Ставте пріоритет на сигнали, які:

• Корелюються за часом з початком інциденту.
• Повторюються (однаковий Event ID + джерело знову і знову).
• Збігаються між журналами (System + Application + конкретний операційний журнал дають однакову картину).
• Дієві (вказують на пристрій, файл, обліковий запис, сертифікат або ім’я сервісу).

І ще: перестаньте скріншотити Event Viewer, ніби це рідкісна пташка. Експортуйте події. Запитуйте їх. Порівнюйте. Це 2026, а не 2006.

Жарт №1: Event Viewer — це місце, куди попередження йдуть на пенсію — комфортно, голосно і ніколи не платять за житло.

Одна цитата, щоб тримати себе в кутах:

Парафразована ідея — В. Едвардс Демінг: без даних ви просто ще одна людина з думкою.

План швидкої діагностики: перші/другі/треті перевірки

0–1 хвилина: визначте вікно відмови

• Який найраніший часовий штамп симптомів, видимих для користувача?
• Відбулося перезавантаження? Патч? Ротація сертифіката? Відмова сховища?
• Виберіть вікно: 15 хвилин до початку симптомів до 15 хвилин після.

Рішення: якщо ви не можете обмежити час — не зможете обмежити і реальність. Спочатку визначте час.

1–2 хвилина: журнал System за правду на рівні платформи

Розпочніть у Журнали Windows → Система. Чому? Бо коли підлога провалюється, меблі (додатки) скаржаться пізніше.

Фільтруйте за рівнями: Критичні, Помилки. Сортуйте за датою й часом. Звертайте увагу на джерела, як‑от:

• Kernel-Power (неочікувані перезавантаження)
• Disk / storahci / nvme / iaStorAC (шлях зберігання)
• Ntfs (файлова система)
• Service Control Manager (сервіси не вдається запустити)
• WHEA-Logger (помилки апаратури)
• Schannel (TLS/сертифікатний рукостиск)

Рішення: якщо журнал System показує скидання диска, таймаути контролера, WHEA або події живлення — припиніть звинувачувати додаток. Спочатку виправляйте платформу.

2–3 хвилина: журнал Application щоб зрозуміти «хто помер першим»

Перейдіть у Журнали Windows → Application і теж відфільтруйте. Шукайте:

• Application Error (Event ID 1000)
• .NET Runtime (Event ID 1026)
• SQL Server, IIS, VSS, MSExchange*, сторонні провайдери
• SideBySide (проблеми з маніфестом/CRT)

Рішення: визначте перший крах у вікні, потім корелюйте назад: що йому передувало в System?

3–4 хвилина: операційні журнали для підсистеми, яку підозрюєте

Більшість реальних відповідей не в «Application» чи «System». Вони в:

• Журнали програм і служб → Microsoft → Windows → (компонент) → Operational
• Приклади: WindowsUpdateClient/Operational, TaskScheduler/Operational, WinRM/Operational, GroupPolicy/Operational, Security‑Kerberos/Operational

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

4–5 хвилина: доведіть запитом, потім експортуйте

Кліки в Event Viewer підходять для орієнтування. Для доказу використовуйте Get-WinEvent або wevtutil і експортуйте щільний пакет.

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

Основи журналів подій для дорослих

Event Viewer — це браузер бази даних, а не панель стану

Система подій Windows — це структурована система логування з каналами, провайдерами, ID, рівнями, завданнями, опкодами, ключовими словами і XML‑повідомленнями. Event Viewer показує вам спрощений вигляд. Це корисно, але приховує найкращі частини: структуровані поля, за якими можна робити запити.

Думайте в термінах «каналів» і «провайдерів»

Канал — це місце, де живуть події (System, Application, Security і сотні операційних каналів). Провайдер — це хто записав подію (Service Control Manager, Disk, Schannel, WindowsUpdateClient).

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

Рівні — це політика

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

Довіряйте шаблонам, а не кольорам.

Кореляція важливіша за інтерпретацію

Той самий корінь часто проявляється ланцюжком:

• Збій сховища (Disk/Ntfs)
• Таймаут сервісу (Service Control Manager)
• Крах додатку (.NET Runtime/Application Error)
• Скарга користувача («Працює повільно»)

Якщо ви починаєте з краху додатку, ви вже запізнились.

Журнал безпеки особливий (і часто не стосується)

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

Цікаві факти та історія (те, що важливо)

• Windows NT ввів службу журналу подій у 1990‑х як центральний механізм аудиту; тому розділення «System/Application/Security» досі визначає робочі процеси.
• Event Tracing for Windows (ETW) став високопродуктивним фундаментом сучасної телеметрії Windows; багато «Operational» журналів базуються на ETW.
• Event ID є scoped до провайдера, а не універсальні. Два різні провайдери можуть використовувати той самий ID з зовсім різним значенням.
• Зміни епохи Vista значно розширили канали (Applications and Services Logs), тому найкорисніші журнали часто заховані під Microsoft → Windows.
• Сhannel Schannel став канаркою для збоїв TLS/сертифікатів, коли підприємства посилювали крипто‑налаштування і відключали старі протоколи.
• WHEA (Windows Hardware Error Architecture) стандартизував повідомлення про машинні перевірки та скоректовані помилки апаратури, тому WHEA‑Logger — ваш джерело «апаратура невдоволена».
• Windows Update перейшов до компонентизації (CBS, servicing stack), тому відмови оновлень часто потребують перевірки кількох каналів понад базовими повідомленнями WindowsUpdateClient.
• VSS (Volume Shadow Copy Service) старший за багато рішень резервного копіювання; коли він падає, ваші бекапи «успішні», поки не спробуєте відновлення. Журнали говорять правду першими.
• За замовчуванням утримання журналів часто малі на серверах, що тихо руйнує вашу здатність відповісти на питання «коли це почалось?».

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

Нижче — практичні задачі, які можна виконати негайно. Кожна включає: команду, що означає типовий вивід, і рішення, яке ви приймаєте. Команди показані так, ніби ви на Windows‑хості з доступним PowerShell; промпт — просто промпт.

Задача 1 — Перелічити найбільші журнали (знайти, хто «з’їдає» історію)

cr0x@server:~$ wevtutil el
Application
Security
System
Microsoft-Windows-WindowsUpdateClient/Operational
Microsoft-Windows-GroupPolicy/Operational
...

cr0x@server:~$ wevtutil gl System
name: System
enabled: true
type: Admin
owningPublisher:
isolation: Application
channelAccess: O:BAG:SYD:(A;;0x5;;;SY)(A;;0x1;;;BA)(A;;0x1;;;SO)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\System.evtx
  retention: false
  autoBackup: false
  maxSize: 20971520

Що це означає: Максимальний розмір журналу System ≈ 20 МБ. На навантажених серверах це може бути година або дні історії, але не тижні.

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

Задача 2 — Витягнути останні 50 помилок System швидко (без GUI і прокрутки)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 50 | Format-Table TimeCreated,Id,ProviderName,Message -AutoSize"
TimeCreated            Id ProviderName           Message
-----------            -- ------------           -------
02/05/2026 02:11:03    7 Disk                   The device, \Device\Harddisk2\DR2, has a bad block.
02/05/2026 02:11:07 129 storahci                Reset to device, \Device\RaidPort0, was issued.
02/05/2026 02:11:15 7000 Service Control Manager The SQLSERVERAGENT service failed to start due to the following error: ...
...

Що це означає: Погані блоки диска і скидання контролера — upstream. Відмова SQL Agent — колатеральна проблема.

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

Задача 3 — Обмежити вікно часу (трюк «п’яти хвилин»)

cr0x@server:~$ powershell -NoProfile -Command "$start=(Get-Date).AddMinutes(-30); $end=Get-Date; Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start; EndTime=$end; Level=1,2} | Sort-Object TimeCreated | Select-Object TimeCreated,Id,ProviderName -First 20"
TimeCreated            Id ProviderName
-----------            -- ------------
02/05/2026 01:49:52  6006 EventLog
02/05/2026 01:50:10    2 Kernel-General
02/05/2026 02:11:03    7 Disk
02/05/2026 02:11:07  129 storahci

Що це означає: За останні 30 хвилин перші серйозні події з’являються о 02:11. Це ваш початок інциденту, навіть якщо користувачі помітили проблему о 02:15.

Рішення: Вирівняйте всі інші журнали по 02:11 і працюйте назовні. Не переслідуйте старі не пов’язані шуми.

Задача 4 — Перевірити неочікуване перезавантаження проти «хтось його перезавантажив»

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:49:51
Message     : The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Що це означає: Kernel‑Power 41 — «нечисте завершення роботи». Воно не каже чому; каже лише, що ОС не встигла попрощатись.

Рішення: Поєднайте з BugCheck подіями, WHEA, скиданнями диска або подіями гіпервізора. Розглядайте 41 як підказку, а не діагноз.

Задача 5 — Знайти відмови запуску сервісів (бо зламані залежності виглядають як «апка впала»)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:15 7000 The SQLSERVERAGENT service failed to start due to the following error: The service did not start due to a logon failure.
02/05/2026 02:11:16 7009 A timeout was reached (30000 milliseconds) while waiting for the SQLSERVERAGENT service to connect.

Що це означає: Помилка логіну вказує на проблему з обліковим записом (зміна пароля, gMSA, втрата прав), а не на CPU чи пам’ять.

Рішення: Перевірте обліковий запис сервісу, нещодавні зміни паролів та право «Log on as a service». Не перезапускайте його 20 разів і не називайте це «виправлено».

Задача 6 — Визначити підписи краху (Event ID 1000) і модуль, що впав

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'; Id=1000} -MaxEvents 10 | Select-Object TimeCreated,Message | Format-Table -Wrap"
TimeCreated            Message
-----------            -------
02/05/2026 02:12:02  Faulting application name: w3wp.exe, version: ...
                       Faulting module name: ntdll.dll, version: ...
                       Exception code: 0xc0000374
                       Fault offset: ...

Що це означає: Відбувся крах з кодом виключення. «Faulting module» не завжди винуватець (ntdll часто просто повідомляє про крах).

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

Задача 7 — Винятки .NET Runtime (часто читабельніші за логи вендора)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='.NET Runtime'; Id=1026} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 02:12:01
Message     : Application: MyService.exe
              Framework Version: v4.0.30319
              Description: The process was terminated due to an unhandled exception.
              Exception Info: System.IO.IOException: The network path was not found.

Що це означає: Виняток містить конкретну помилку (мережева доріжка не знайдена). Це вказує на SMB, DNS, брандмауер або відсутню шару, а не на «.NET поламався».

Рішення: Перевірте розв’язання імен і доступність шар. Перевірте System на мережеві помилки навколо того ж часу.

Задача 8 — Помилки сховища та файлової системи: Disk, Ntfs і «запитання: SAN?»

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Ntfs'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:10   55 The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume.

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

Рішення: Якщо ви в VM — перевірте здоров’я хостового сховища і ланцюжок снапшотів. Якщо фізично — перевірте стан диска й логи контролера. Плануйте контрольне виконання chkdsk; не запускайте його без оцінки впливу на критичний том бази даних.

Задача 9 — Події WHEA апаратури (навіть скоректовані помилки — це все ще помилка)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:10:58   17 Warning          A corrected hardware error has occurred. Component: PCI Express Root Port...

Що це означає: Скоректовані помилки означають, що система відновилась, але апаратура деградує або шина не в порядку (часто NIC/HBA/PCIe).

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

Задача 10 — Помилки TLS і сертифікатів через Schannel (коли «API впало», а насправді крипто)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Level=2} -MaxEvents 10 | Format-Table TimeCreated,Id,Message -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:08:44 36874 An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server.

Що це означає: Налаштування криптографії клієнта і сервера не перетинаються. Часто після посилення політик або через старі клієнтські бібліотеки.

Рішення: Ідентифікуйте клієнта (часто в логах додатка або мережевих трасах) і виправте перетин шифрів/протоколів. Уникайте «вмикати TLS 1.0», якщо ваш ризик‑апетит — це історична реконструкція.

Задача 11 — Відмови Windows Update з операційними деталями (перестаньте покладання на GUI)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 01:40:12   20 Installation Failure: Windows failed to install the following update with error 0x800f081f: ...
02/05/2026 01:40:13   25 Windows Update failed to download an update. Error: 0x8024401c

Що це означає: Маєте реальні коди помилок. 0x800f081f часто пов’язаний з компонентним сховищем/відсутніми файлами джерела; 0x8024401c часто стосується підключення/WSUS/проксі.

Рішення: Розділіть проблеми «servicing stack/component store» від «мережі/WSUS». Різні власники — різні виправлення.

Задача 12 — Запит за провайдером + ID через XPath (точність має значення)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Provider[@Name='Disk'] and (EventID=7))]]" /f:text /c:3
Event[0]:
  Log Name: System
  Source: Disk
  Date: 2026-02-05T02:11:03.0000000Z
  Event ID: 7
  Task: N/A
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: server01
  Description:
  The device, \Device\Harddisk2\DR2, has a bad block.

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

Рішення: Використовуйте XPath‑запити, коли потрібні повторювані докази й менше неоднозначності GUI.

Задача 13 — Експортувати щільний пакет доказів (для ескалації або постмортему)

cr0x@server:~$ wevtutil epl System C:\Temp\System.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Application C:\Temp\Application.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Microsoft-Windows-WindowsUpdateClient/Operational C:\Temp\WindowsUpdate-Operational.evtx
The operation completed successfully.

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

Рішення: Завжди експортуйте EVTX, а не CSV, коли хочете, щоб інженери робили реальну фільтрацію і кореляцію пізніше.

Задача 14 — Знайти події «журнал очищено» (бо інколи таємниця — саботаж або паніка)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:10:22
Message     : The audit log was cleared.

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

Рішення: Розглядайте це як подію безпеки й управління. Перевірте записи змін, привілейований доступ і чому це відбулося. Очищення логів — не діагностика; це знищення доказів.

Задача 15 — Виявити проблеми синхронізації часу (коли автентифікація і TLS падають «без причини»)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Level=2,3} -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:05:01   36 Warning          The time service has not synchronized the system time for 86400 seconds because no time data was available.

Що це означає: Зсув часу може ламати Kerberos, сертифікати, планувальник задач і спричиняти «випадкову» поведінку додатків.

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

Три корпоративні міні‑історії (бо реальність дивніша)

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

У тікеті було написано: «База даних стала повільною після патчу». DBA наполягав, що це регресія плану запитів. Windows‑команда наполягала, що це налаштування SQL. Усі були впевнені. Ніхто не був правий.

На постраждалому сервері System журнал показував періодичні storahci скидання і попередження Disk. Час збігався ідеально з вікном «повільно», але команда відкинула це, бо панель управління масиву сховища була зеленою та хост VM не показував тривог.

Хибне припущення було тонким: «Якщо SAN здоровий, Windows не буде логувати скидання диска». Насправді Windows логують те, що бачить гість. Транзиторна проблема шляху, невірний драйвер HBA або неправильно налаштований multipath можуть спричиняти таймаути на гості, тоді як масив залишається «зеленим». Зелені дашборди — не доказ здорового I/O.

Виправлення не було налаштуванням бази даних. Це була синхронізація драйвера/прошивки на шляху зберігання хоста. Коли шлях стабілізувався, затримка запитів повернулась до норми без торкання SQL.

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

Історія 2: Оптимізація, що зіграла злий жарт

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

Три тижні потому контролер домену почав показувати спорадичні помилки автентифікації. Користувачі скаржилися дні: «Іноді працює, іноді ні». Класичний переривчастий інцидент: максимум болю, мінімум доказів.

Коли команда нарешті подивилась у Event Viewer, журнали Security і System містили лише кілька годин історії. Відмови сталися «вчора», але вчора вже не існувало. Центральна агрегація була на папері; сервіс конектору тиша падав, і, звісно, його власні журнали теж були перезаписані.

Вони відновили таймлайн іншими доказами (логи клієнтів, логи брандмауера і те, що залишилось на DC). Корінь виявився у зсуві часу на NTP‑шляху одного сайту, що спричинювало Kerberos‑збої в певні вікна. Виправлення синхронізації часу вирішило проблему. Але час вирішення був витрачений на лікування самозавданої рани з утриманням логів.

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

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

Сервіс, пов’язаний з платежами, почав відмовляти TLS‑рукостискання після рутинного посилення базової політики. Команда додатку клялася, що нічого не змінювала в розгортанні. Команда безпеки клялась, що політика безпечна. Сервіс був недоступний, і всі вже готували улюблені історії про відповідальність.

Один SRE зробив щось болісно нудне: експортував релевантні логи (System, Application і Schannel‑пов’язані події) за двогодинне вікно, потім порівняв їх з відомим‑добрим вікном попереднього тижня з того ж хоста.

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

Виправлення було точковим: оновити клієнтську бібліотеку і зберегти посилену політику. Ніякого rollback, ніякого вмикання старих протоколів, ніяких нічних суперечок про «просто зробити, щоб працювало».

Нудна практика перемагає: зберігайте достатньо історії логів, експортуйте структурований EVTX‑доказ і порівнюйте з відомою доброю базою. Це не гламурно, але саме так ви зберігаєте свої вихідні дні.

Жарт №2: Найшвидший спосіб покращити MTTR — перестати робити «ще одне перезавантаження» вашим основним діагностичним інструментом.

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

1) «У Event Viewer все червоне»

Симптом: Сотні помилок; ви не знаєте, з чого почати.

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

Виправлення: Визначте 30‑хвилинне вікно навколо початку симптомів. Фільтруйте на Критичні+Помилки. Сортуйте за часом. Знайдіть першу повторювану пару провайдер/ID.

2) Kernel‑Power 41 і паніка

Симптом: З’явився Kernel‑Power Event ID 41; люди роблять висновок «блок живлення» або «баг Windows».

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

Виправлення: Поєднайте з BugCheck подіями, WHEA‑попередженнями, скиданнями диска і логами гіпервізора. Розглядайте 41 як крихту, а не діагноз.

3) Application Error 1000 звинувачується в ntdll.dll

Симптом: Крах показує ntdll.dll; команди звинувачують Windows.

Корінь: ntdll часто просто повідомляє; реальна причина зазвичай — корупція пам’яті, несумісний модуль, ін’єкція інструменту безпеки або upstream I/O збій.

Виправлення: Корелюйте з .NET Runtime (1026), вендорськими логами і недавніми змінами. Збирайте дампи, якщо повторюється. Перевірте на помилки сховища/мережі перед крахом.

4) Ігнорування Service Control Manager 7000/7009

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

Корінь: Помилка логіну облікового запису сервісу, відмова залежності або повільний I/O, що спричиняє таймаути.

Виправлення: Прочитайте точне повідомлення SCM. Перевірте облікові дані/права. Якщо це таймаути — досліджуйте затримки диска і ланцюжок залежностей, а не бінарник сервісу.

5) Schannel помилки «виправлені» ввімкненням старих протоколів

Симптом: TLS‑рукостискання падає; хтось пропонує вмикнути TLS 1.0/слабкі шифри.

Корінь: Клієнтська бібліотека не підтримує сучасний TLS/набори шифрів; посилення видалило спадкові опції.

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

6) Відмови оновлень трактуються як «Windows як Windows»

Симптом: Оновлення періодично падають; команди відкладають патчування назавжди.

Корінь: Проблеми з компонентним сховищем, проксі/WSUS або несумісність servicing stack; деталі в операційних журналах, а не в GUI.

Виправлення: Використовуйте WindowsUpdateClient/Operational події і коди помилок. Розділіть мережеві проблеми від проблем компонентного сховища і призначте відповідальних.

7) Відсутні журнали в найгірший момент

Симптом: Ви не можете знайти події з минулого тижня, коли почалась проблема.

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

Виправлення: Збільшіть розміри журналів; моніторьте здоров’я форвардингу логів; сповіщайте про події очищення журналів; експортуйте докази під час інцидентів.

8) Зсув часу спричиняє «випадкові» відмови автентифікації і TLS

Симптом: Kerberos‑помилки, помилки сертифікатів, заплановані задачі не спрацьовують.

Корінь: Неправильна конфігурація ієрархії часу NTP, заблоковане джерело часу або плутанина синхронізації часу в хості VM.

Виправлення: Перевірте події служби часу Windows; виправте джерела часу; забезпечте дотримання доменної ієрархії часу.

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

Чекліст A — П’ятихвилинний триаж Event Viewer (людська швидкість)

1. Запишіть вікно відмови (оцінка часу початку, уражені сервіси, остання відома хороша точка).
2. Спочатку журнал System: фільтруйте Критичні+Помилки, звертайте увагу на Disk/Ntfs/stor*; WHEA; Kernel‑Power; SCM; Schannel.
3. Визначте першу «нову» повторювану помилку у вікні. Нова важливіша за голосну.
4. Потім журнал Application: знайдіть перший крах/виняток; зафіксуйте ім’я процесу і код помилки.
5. Третім — операційний журнал: оберіть канал підсистеми (WindowsUpdateClient, GroupPolicy, Kerberos, WinRM, TaskScheduler тощо).
6. Корелюйте часові мітки: побудуйте послідовність з 5–10 подій. Інциденти — це оповідання.
7. Доведіть через запит (Get‑WinEvent/wevtutil) і експортуйте EVTX‑докази.
8. Прийміть рішення: проблема платформи проти додатку, чи це ідентичність/політика, чи оновлення/регресія.

Чекліст B — Якщо підозрюєте сховище або файлову систему

1. Шукайте в System події Disk, storahci/nvme/iaStor*, Ntfs, volsnap у вікні.
2. Шукайте шаблони: скидання (129), погані блоки (7), корупція NTFS (55), відмови відкладеного запису.
3. Перевірте, чи збігаються відмови з бекапами, снапшотами або важкими роботами.
4. Прийміть рішення: проблема на рівні гостя, чи шлях хоста/SAN, чи невідповідність драйвера/прошивки.
5. Ескалюйте з експортованими логами і точним часовим вікном, а не «він був повільний».

Чекліст C — Якщо підозрюєте ідентичність/автентифікацію/політику

1. System: попередження Time‑Service, проблеми Netlogon, Kerberos operational журнали.
2. SCM помилки: «logon failure» при запуску сервісу зазвичай — це ідентичність/політика.
3. Security журнал — лише коли маєте цільовий ID/провайдера; інакше це болото.
4. Підтвердіть нещодавні зміни GPO і чи вони співпадають із часом початку подій.

Чекліст D — Якщо підозрюєте оновлення

1. WindowsUpdateClient/Operational: зафіксуйте коди помилок і точний контекст оновлення.
2. System/Application: подивіться на помилки servicing stack і component‑пов’язані помилки того самого часу.
3. Прийміть рішення: мережа/WSUS/проксі проти component store.
4. Документуйте точні коди помилок в записі інциденту. Вони важливі.

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

1) Чому я бачу «Помилки» на здорових серверах?

Бо деякі провайдери логують транзиторні, відновлювані стани як помилки (особливо мережеві та таймаути сервісів). Оцінюйте за кореляцією: чи одночасно з початком симптомів, чи повторюється, чи підтверджується в кількох журналах.

2) Який найкращий журнал, з якого почати?

System. Він фіксує апаратні події, драйвери, сховище, живлення і запуск сервісів — речі, що змушують додатки виходити з ладу пізніше.

3) На чому зосередитись: Event ID чи джерело?

І на тому, і на іншому, але почніть з провайдера/джерела плюс Event ID. Самі по собі ID неоднозначні між провайдерами. «Event ID 41» означає Kernel‑Power; «Event ID 41» в іншому місці може бути іншим.

4) Як довго зберігати журнали?

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

5) Чи завжди Kernel‑Power 41 означає апаратне?

Ні. Це маркер нечистого завершення роботи. Це може бути втрата живлення, bugcheck, зависання, скидання гіпервізора або хтось, хто тримав кнопку живлення (таке буває). Поєднуйте з іншими подіями.

6) Як зрозуміти, чи крах спричинений проблемами зі сховищем?

Шукайте скидання диска/контролера, помилки NTFS, відкладені записи або volsnap перед крахом. Якщо помилки сховища передують падінням додатків у тому самому вікні — вважайте сховище підозрілим.

7) Чому Event Viewer інколи «зависає», коли я клікаю журнал?

Великі журнали + дорогий рендеринг + віддалений доступ можуть бути повільними. Використовуйте Get-WinEvent, щоб витягнути обмежене часове вікно або невелику кількість подій. Запити масштабується краще, ніж кліки.

8) Коли експортувати EVTX, а коли копіювати/вставляти текст?

Експортуйте EVTX, коли потрібна структурована фільтрація, кореляція або передача іншому інженеру. Копіювання/вставка тексту підходить для однієї події в таймлайні інциденту, але втрачає структуру.

9) Чи безпечно очищати журнали як «обслуговування»?

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

10) Що робити, якщо я нічого не знаходжу в System або Application?

Тоді, ймовірно, проблема в операційному каналі (WindowsUpdateClient, GroupPolicy, Kerberos, TaskScheduler, Defender, WinRM) або проблема зовнішня (мережевий пристрій, upstream‑залежність). Перейдіть до журналів підсистеми і перевірте часове вікно.

Наступні кроки (що робити після того, як «знайшли» проблему)

Знайти помилку — це ще не означає виправити систему. Професійний крок — перетворити ваше п’ятихвилинне виявлення на довготривалу надійність:

1. Експортуйте докази (EVTX) для System, Application і релевантного операційного каналу за вікно інциденту.
2. Напишіть короткий таймлайн інциденту з 5–10 ключовими подіями у порядку. Включіть провайдера, Event ID і часову мітку.
3. Класифікуйте відмову: платформа/сховище, ідентичність/політика, оновлення/регресія, баг додатку або зовнішня залежність.
4. Виправляйте upstream‑причину першою. Скидання сховища спричиняють «таємничі» відмови додатків; зсув часу — «випадкові» помилки автентифікації.
5. Зробіть журнали вцілілими: збільшіть утримання, моніторте форвардинг логів і сповіщайте про події очищення журналів.
6. Автоматизуйте запит, який ви сьогодні використали. Якщо він одного разу врятував — він врятує знову, найімовірніше о 02:17.

Якщо нічого не взяти інше: перестаньте читати Event Viewer як роман. Запитуйте його як систему. Ваш час доступності вам подякує.