Анализ критических ошибок Windows по логам

Друзья, сегодня мы поговорим о том, что заставляет даже опытных администраторов внутренне сжиматься — о «синем экране смерти» (BSOD), внезапных перезагрузках и падениях критических сервисов. Windows — система сложная, и когда она падает, просто перезагрузить компьютер недостаточно. Нужно понять почему.

И ответ на это «почему» всегда лежит в логах.

Что такое критическая ошибка в терминах Windows

Для начала договоримся о терминах. Windows делит все события на четыре уровня серьезности :

  • Информация (Information) — просто уведомление, всё хорошо
  • Предупреждение (Warning) — что-то пошло не так, но не смертельно
  • Ошибка (Error) — проблема, требующая внимания
  • Критическое (Critical) — система потеряла стабильность, возможен сбой

Критические ошибки — это те, которые мы разбираем сегодня. Они появляются, когда система неожиданно перезагружается, зависает или показывает «синий экран» .

Где искать: Просмотр событий (Event Viewer)

Главный инструмент для анализа логов в Windows — это Просмотр событий (Event Viewer). Открыть его можно несколькими способами : - Нажать Win + R, ввести eventvwr.msc и нажать Enter - Нажать Win + X и выбрать «Просмотр событий» из меню - Просто найти через поиск в меню «Пуск»

После открытия нас интересует раздел Журналы Windows (Windows Logs) . Там три основных подраздела: - Application — логи приложений - Security — события безопасности (входы, выходы, попытки доступа) - System — системные события, драйверы, службы

Большинство критических ошибок мы будем искать именно в System и Application .

Три кита анализа: Event ID, Source, Level

Каждое событие в Windows имеет три ключевых характеристики, по которым мы его ищем :

  • Event ID — уникальный номер типа события (например, 41, 1001, 6008)
  • Source — компонент, вызвавший событие (Kernel-Power, BugCheck, Service Control Manager)
  • Level — уровень серьезности (Critical, Error, Warning)

Запомните эти три параметра. Именно они будут нашими поисковыми запросами.

Главные Event ID критических ошибок

За годы практики я выделил несколько Event ID, которые нужно знать наизусть.

Event ID 41: Kernel-Power

Это, пожалуй, самый частый гость при проблемах с железом. Событие с ID 41 и источником Kernel-Power означает, что система перезагрузилась без корректного завершения работы .

Типичное описание: The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Что это значит: Система не инициировала корректное завершение — либо пропало питание, либо сработал сброс, либо произошёл сбой на уровне ниже того, куда Windows успела бы записать нормальный лог.

Куда копать: Проверяем блок питания, перегрев, проблемы с электросетью. Если событие 41 появляется вместе с BSOD — смотрим следующий пункт.

Event ID 1001: BugCheck

А вот это уже прямое указание на «синий экран». Event ID 1001 с источником BugCheck или Windows Error Reporting появляется после того, как система перезагрузилась после BSOD .

В описании вы увидите заветный bug check code — код остановки. Например: The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e (0xffffffffc0000005, 0xfffff80002e5c5c3, 0xfffff88007f0f368, 0xfffff88007f0ebc0)

Здесь 0x0000007e — это код ошибки (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED), а параметры в скобках — дополнительные данные для отладки .

Event ID 6008: Unexpected Shutdown

Event ID 6008 появляется при следующем запуске системы и говорит: «Предыдущее завершение работы было неожиданным» .

Пример: The previous system shutdown at 11:45:32 AM on 1/15/2024 was unexpected.

Это событие часто сопровождает Event ID 41, но даёт дополнительную информацию — точное время, когда система "умерла".

Event ID 1074: Shutdown Initiated

Интересно, что для полноты картины полезно смотреть и Event ID 1074 — он фиксирует корректные завершения работы . Если вы ищете причину внезапных перезагрузок, наличие Event ID 1074 между двумя 41-ми показывает, что система хотя бы раз выключилась нормально.

Дополнительные Event ID для глубокого анализа

Для более полной картины специалисты рекомендуют обращать внимание и на другие ID :

| Event ID | Источник | Что означает | |----------|----------|--------------| | 101 | Windows Error Reporting | Дополнительная информация о краше | | 1003 | Windows Error Reporting | Ошибка приложения, может предшествовать BSOD | | 7000 | Service Control Manager | Служба не смогла запуститься | | 7034 | Service Control Manager | Служба неожиданно завершилась |

Как быстро найти все критические ошибки

Просматривать сотни событий вручную — занятие для терпеливых. Я покажу два способа отсеять лишнее.

Способ 1: Фильтр в Event Viewer

В Event Viewer можно создать фильтр, который покажет только нужное :

  1. Выберите журнал System или Application
  2. В правой панели нажмите Filter Current Log
  3. Отметьте галочками Critical и Error
  4. В поле Event IDs можно перечислить через запятую нужные ID: 41, 1001, 6008, 1074
  5. Нажмите OK

Теперь вы видите только то, что действительно важно.

Способ 2: PowerShell (для автоматизации)

Если нужно собрать логи с нескольких машин или просто хочется почувствовать себя хакером, используйте PowerShell :

```powershell

Последние 10 критических ошибок в системном журнале

Get-EventLog -LogName System -EntryType Error -Newest 10 | Out-GridView

Использование Get-WinEvent для более тонкой фильтрации

Get-WinEvent -FilterHashtable @{ LogName='System'; Level=1,2; # 1 - Critical, 2 - Error StartTime=(Get-Date).AddDays(-1) } | Select-Object TimeCreated, Id, LevelDisplayName, Message

Поиск конкретных Event ID

Get-WinEvent -FilterHashtable @{ LogName='System'; Id=41,1001,6008 } | Format-Table TimeCreated, Id, Message -AutoSize ```

Способ 3: Команда wevtutil

Для быстрого экспорта логов из командной строки можно использовать wevtutil :

bash wevtutil qe System /f:text /c:20 /q:"*[System[(Level=1 or Level=2)]]"

Эта команда покажет последние 20 критических ошибок и ошибок из системного журнала.

Анализ дампов памяти (когда логов недостаточно)

Информация из Event Viewer хороша, но часто она лишь указывает направление. Самый точный диагноз можно поставить, проанализировав дамп памяти (dump file) — снимок оперативной памяти в момент краха .

Дампы лежат в двух местах : - C:\Windows\Minidump\ — маленькие дампы (обычно по одному на каждый BSOD) - C:\Windows\MEMORY.DMP — полный дамп (может быть огромным)

Для анализа дампов нужны специальные инструменты.

WinDbg (Windows Debugger)

Это профессиональный инструмент от Microsoft. Используется так :

  1. Скачайте и установите WinDbg (входит в Windows SDK)
  2. Откройте программу, нажмите File → Open Crash Dump
  3. Выберите файл дампа (например, из Minidump)
  4. После загрузки введите команду !analyze -v
  5. Изучите вывод — там будет указан вероятный виновник (например, dam.sys или nvlddmkm.sys)

В сообществе Microsoft эксперты часто просят прислать именно дампы, а не скриншоты синего экрана — в них гораздо больше информации .

BlueScreenView (для простых смертных)

Если WinDbg кажется сложным, есть утилита BlueScreenView от NirSoft. Она показывает все минидампы в удобной таблице, выделяет драйверы, которые могли вызвать проблему, и даже подсвечивает их цветом.

Практический разбор: что означают коды остановки

Коды остановки (bug check codes) — это ключ к пониманию проблемы. Вот самые частые :

| Код | Название | Что обычно означает | |-----|----------|---------------------| | 0x0000007E | SYSTEM_THREAD_EXCEPTION_NOT_HANDLED | Проблемный драйвер или нехватка памяти | | 0x0000007F | UNEXPECTED_KERNEL_MODE_TRAP | Ошибка аппаратуры (обычно процессор или память) | | 0x000000D1 | DRIVER_IRQL_NOT_LESS_OR_EQUAL | Драйвер обратился к памяти, к которой не имел права | | 0x0000000A | IRQL_NOT_LESS_OR_EQUAL | Проблемный драйвер или несовместимое ПО | | 0x0000001A | MEMORY_MANAGEMENT | Проблемы с оперативной памятью | | 0x00000050 | PAGE_FAULT_IN_NONPAGED_AREA | Драйвер или программа обратились к уже освобождённой памяти | | 0x0000003B | SYSTEM_SERVICE_EXCEPTION | Часто связано с графическими драйверами |

Реальные сценарии и их расшифровка

Сценарий 1: Компьютер перезагружается без предупреждения

В логах: Event ID 41 (Kernel-Power), иногда в паре с 6008.

Что делать: 1. Проверить блок питания (возможно, не хватает мощности) 2. Проверить температуры (SpeedFan, HWMonitor) 3. Отключить функцию "Автоматическая перезагрузка при сбое" в настройках системы, чтобы увидеть синий экран 4. Если появляется синий экран — искать дамп

Сценарий 2: Синий экран с кодом 0x0000007E

В логах: Event ID 1001 с кодом 0x0000007E.

Что делать: 1. Открыть дамп в WinDbg, выполнить !analyze -v 2. Посмотреть, какой драйвер указан как вероятный виновник (обычно в секции IMAGE_NAME) 3. Обновить или откатить этот драйвер

Сценарий 3: Система не загружается после установки обновления

В логах: Не посмотреть, так как система не грузится, но можно загрузиться с установочного диска и посмотреть логи офлайн.

Что делать: 1. Загрузиться в безопасном режиме (F8 при старте) 2. Удалить последние обновления 3. Если безопасный режим не грузится — использовать среду восстановления Windows

Сценарий 4: Служба постоянно падает

В логах: Event ID 7034 в журнале System.

Что делать: 1. Посмотреть, какая служба падает (в описании события) 2. Проверить зависимости службы 3. Посмотреть логи самой службы (если есть) — часто они лежат в папке программы 4. Переустановить службу или связанное с ней ПО

Что делать, если логов слишком много

Обилие ошибок и предупреждений в Event Viewer — норма для Windows, особенно если система работает долго без переустановки . Опытные специалисты советуют:

Не пытайтесь исправить все ошибки подряд . Многие предупреждения носят информационный характер и не влияют на работу. Сосредоточьтесь на критических ошибках, которые коррелируют с падениями системы.

Microsoft MVP Rob отмечает: "Вы можете потратить дни и дни, пытаясь исправить неважные ошибки, и никогда никуда не прийти" .

Профилактика: как не допускать критических ошибок

На основе анализа тысяч логов можно выделить основные причины и способы их предотвращения:

1. Драйверы

Самая частая причина BSOD — проблемы с драйверами . Регулярно: - Обновляйте драйверы через сайты производителей (не через Центр обновления Windows) - Не ставьте драйверы из непроверенных источников - Если после обновления драйвера появились проблемы — откатите его

2. Оперативная память

Вторая по частоте причина — битая память . Запускайте встроенное средство диагностики памяти Windows (mdsched.exe) раз в полгода или при подозрениях.

3. Перегрев

События Kernel-Power 41 часто связаны с перегревом. Следите за: - Температурой процессора (не выше 80-85°C под нагрузкой) - Работой вентиляторов - Чистотой системного блока

4. Жесткий диск

Ошибки диска могут проявляться как зависания и синие экраны . Регулярно: - Запускайте chkdsk C: /f (для системного диска) - Следите за SMART-атрибутами через CrystalDiskInfo

Инструменты профи: когда стандартных средств мало

Если вы администрируете несколько машин, встроенных средств может не хватать. Для централизованного сбора и анализа логов используют:

  • ManageEngine EventLog Analyzer — собирает логи со всех машин в одном месте, строит отчёты по критическим событиям, умеет оповещать о проблемах
  • TeamViewer — для удалённого доступа к Event Viewer на клиентских машинах
  • PowerShell скрипты — для автоматического сбора логов с нескольких серверов

Чек-лист диагностики критической ошибки

Когда случается очередной "синий экран", действуйте по порядку:

  1. Запишите код ошибки — сфотографируйте экран или найдите Event ID 1001 в логах после перезагрузки
  2. Проверьте дампы — загляните в C:\Windows\Minidump\, есть ли там свежие файлы
  3. Проанализируйте дамп — используйте BlueScreenView или WinDbg
  4. Проверьте железо — температуры, память, диск
  5. Проверьте драйверы — особенно те, что указаны в анализе дампа
  6. Проверьте обновления — возможно, последнее обновление сломало систему
  7. Гуглите — вбейте код ошибки и имя проблемного драйвера в поиск

Вместо заключения

Критические ошибки Windows — это не приговор, а просто сигнал о том, что где-то есть проблема. И как любой сигнал, его нужно правильно интерпретировать.

Event Viewer и анализ дампов — это те инструменты, которые превращают мистический "синий экран" в понятную техническую проблему: "сбой драйвера видеокарты", "ошибка оперативной памяти" или "перегрев процессора".

Не бойтесь логов. В них нет магии — есть только факты. Научитесь их читать, и диагностика Windows перестанет быть шаманством с бубном, превратившись в рутинную инженерную работу. А система скажет вам спасибо стабильной работой.