- 8 мин. чтения
- 16 мая 2026
- 3 просмотра
Event Viewer в Windows: как читать журнал событий и находить причины ошибок
Половина проблем Windows диагностируется через один инструмент, к которому редко обращаются обычные пользователи: Просмотр событий (Event Viewer, eventvwr.msc). Это встроенный журнал, в который операционная система пишет всё подряд: загрузку и завершение работы, ошибки служб, сбои приложений, события безопасности, причины BSOD. Когда «компьютер вдруг перезагрузился» или «программа закрылась без сообщений», ответ лежит именно здесь. Разбираемся, как пользоваться этим журналом, чтобы найти причину проблемы за пару минут вместо часов гадания.
Что такое Event Viewer и зачем он нужен
Просмотр событий — это центральная база логов Windows. Все системные компоненты (ядро, драйверы, службы, приложения) пишут сюда сообщения с разной степенью важности. Кто-то пишет каждое своё движение (например, служба активации Software Protection логирует каждую попытку проверки лицензии). Кто-то пишет только при ошибках (драйверы видеокарты упоминаются обычно только когда что-то пошло не так).
Журналы хранятся в файлах с расширением .evtx в папке C:\Windows\System32\winevt\Logs. Размер каждого журнала по умолчанию ограничен (обычно 20 МБ), старые записи затираются новыми по принципу циклического буфера. Это значит важно проверять Event Viewer относительно быстро после сбоя — через неделю запись о нём может уже исчезнуть, если система генерирует много событий.
Запускается просмотр событий тремя способами: Win + R → ввод eventvwr.msc, через меню Win + X → Просмотр событий, или через панель управления → Администрирование → Просмотр событий. Запуск от имени администратора нужен для просмотра системных журналов, иначе часть из них будет недоступна. Подробнее про админский запуск — в гайде по cmd и PowerShell от администратора.
Структура журналов
В левой панели Event Viewer два главных раздела. Журналы Windows — стандартные системные журналы, их пять штук:
Приложение — события от установленных программ, включая Office, Adobe, антивирусы. Здесь же логи установки приложений и работы Windows Installer (msi-пакеты).
Безопасность — события входа в систему, попытки доступа к защищённым ресурсам, изменения политик безопасности. Самый важный журнал для отслеживания подозрительной активности.
Установка — служба установки Windows и обновления Windows Update.
Система — события ядра ОС, драйверов, системных служб. Сюда пишутся почти все «системные» ошибки: BSOD, проблемы загрузки, сбои сетевых драйверов.
Перенаправленные события — для централизованного сбора логов в корпоративных сетях. На обычном ПК всегда пустой.
Второй раздел — Журналы приложений и служб. Сюда пишут специализированные компоненты: PowerShell, Hyper-V, Microsoft Office (есть свой подраздел), BitLocker, DNS-клиент. Журналов сотни, но в 90% случаев нужны Application и System.
Уровни событий: что важно, а что шум
У каждого события есть уровень важности (иконка слева от записи):
Критическое (красный круг) — система или важный компонент полностью отказали. Сюда падают BSOD (событие 41 Kernel-Power после неожиданной перезагрузки), отказы аппаратуры, критические повреждения файловой системы.
Ошибка (красный круг с крестом) — серьёзная проблема, но не катастрофа. Сбой службы, ошибка драйвера, проблема с обновлением.
Предупреждение (жёлтый треугольник) — что-то идёт не так, но компонент работает. Например, переполнение журнала, проблемы с сетью, конфликты драйверов.
Сведения (синий значок i) — обычная работа, никаких проблем. Старт служб, успешные обновления, штатные операции. В 95% случаев это шум, который можно отфильтровать.
Аудит успехов / отказов (ключик) — только в журнале Безопасности. Успешные и неудачные попытки входа, доступа к защищённым объектам.
Как найти причину конкретной проблемы
Главный приём: сначала отфильтровать по времени. Открываете журнал «Система» или «Приложение», правой кнопкой → Фильтр текущего журнала. В поле «Дата» ставите «Сегодня» или «Последние 24 часа». В поле «Уровни» снимаете галочки со «Сведений», оставляете только Критические, Ошибки и Предупреждения. После такого фильтра обычно остаётся 20-50 записей вместо тысяч.
Дальше смотрите события за минуту до момента, когда возникла проблема. У каждой записи есть точное время и идентификатор события (Event ID). По Event ID можно гуглить — Microsoft и сообщество хорошо документируют распространённые коды.
Если проблема была вчера, а сегодня нужно найти причину BSOD: ищите в журнале «Система» события с источником BugCheck или Kernel-Power. BugCheck расскажет конкретный код синего экрана (например, MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL), Kernel-Power 41 — что система была перезагружена не штатно (питание, BSOD, зависание).
Топ-10 важных Event ID, которые стоит знать
System / Kernel-Power, ID 41 — неожиданная перезагрузка. Если предыдущая запись BugCheck — был BSOD, ищите код. Если нет — питание (выключился UPS, упало напряжение, отключили кабель).
System / BugCheck, ID 1001 — Windows записала параметры BSOD. Подробности: код ошибки, файл драйвера, обычно адреса памяти. По коду гуглим причину.
System / disk, ID 7 или 51 — ошибка чтения/записи на диск. Часто предвестник того, что HDD/SSD скоро умрёт. Срочно проверять через chkdsk и смотреть SMART через CrystalDiskInfo.
System / volmgr, ID 161 — проблема создания дампа памяти при BSOD. Обычно связана с настройкой файла подкачки.
Application / Application Error, ID 1000 — программа аварийно завершилась. В деталях указан путь к exe и модуль, в котором произошла ошибка. Часто это сторонняя DLL или драйвер видеокарты.
Application / Windows Error Reporting, ID 1001 — отчёт об ошибке отправлен в Microsoft. Содержит классификацию проблемы.
Security / 4625 — неудачная попытка входа. Если их много за короткое время — кто-то пытается подобрать пароль (брутфорс).
Security / 4624 — успешный вход в систему. Логирует кто, когда, откуда. Полезно для проверки несанкционированных входов.
System / Service Control Manager, ID 7034 или 7031 — служба внезапно завершилась или была остановлена. Часто проблема с лицензированием (sppsvc), драйверами или антивирусом.
Application / MsiInstaller, ID 1024 или 1023 — ошибка установки или удаления программы. Содержит код возврата msiexec, по которому можно понять причину.
Поиск ошибок активации через Event Viewer
Когда не активируется Windows и slmgr выдаёт непонятный код, Event Viewer часто содержит точное объяснение причины. Открываете журнал «Приложение», фильтруете по источнику Software Protection Platform Service (это служба активации Windows). Все события этой службы — детальные логи попыток активации.
Что искать: записи с уровнем «Ошибка» с источником Microsoft-Windows-Security-SPP. В описании события будет код вроде 0xC004F074, hresult ошибки, иногда конкретный URL сервера активации, к которому не получилось подключиться. Это даёт намного больше информации, чем сообщение «Не удалось активировать» в Параметрах.
Если ищете причину конкретной ошибки активации — в нашем блоге есть разборы кодов, например 0xC004F050, 0xC0EA000A, 0x80072F8F. Полный справочник команд для исправления — в гайде по slmgr.
Custom Views: сохраняем фильтры на будущее
Если часто диагностируете одни и те же проблемы, создайте свой пользовательский вид. Правый клик на «Настраиваемые представления» → Создать настраиваемое представление. Указываете источник, уровни, период. Полезные пресеты:
«Все ошибки за сегодня» — Журналы Windows: Application, System; Уровни: Критический, Ошибка; Время: за последние 24 часа. Утром открыли, увидели всё что произошло.
«BSOD и перезагрузки» — Журнал System; Источники: BugCheck, Kernel-Power; Все уровни. История синих экранов и аварийных перезагрузок.
«Проблемы дисков» — Журнал System; Источники: disk, volmgr, NTFS, Ntfs; Уровни: Критический, Ошибка, Предупреждение. Ранние симптомы умирающего накопителя.
Сохранённые виды лежат в дереве слева и открываются одним кликом. Это сильно экономит время при регулярной диагностике.
Экспорт логов для пересылки в техподдержку
Если нужно показать события другому человеку (системному администратору, в саппорт), сохраните выборку:
Правый клик на нужном журнале → Сохранить все события как. Выберите формат: .evtx (родной, открывается только в Event Viewer на другом ПК с похожей версией Windows), .xml (универсальный, читается любым редактором, можно парсить скриптами), .csv (для Excel и анализа в таблицах), .txt (читаемый текст).
Для пересылки лучше использовать .xml или .csv. Файлы .evtx требуют тех же системных файлов локализации, что усложняет открытие на другой машине. Размер экспорта может быть большим (десятки мегабайт), архивируйте в zip перед отправкой.
Сборка дампов памяти для глубокого анализа
Когда Event Viewer показывает BugCheck 1001, но не объясняет суть проблемы, можно копнуть глубже через дамп памяти. Windows по умолчанию настроена сохранять минидамп при BSOD в C:\Windows\Minidump. Эти файлы (обычно 200-500 КБ каждый) содержат снимок памяти ядра на момент сбоя.
Открыть их можно через WinDbg (входит в Windows SDK) или более простой BlueScreenView от Nirsoft. BlueScreenView показывает понятный список последних BSOD с кодом, временем, файлом драйвера, который скорее всего стал причиной. Для системных администраторов это незаменимый инструмент.
Если минидампы не создаются: Параметры → Система → О системе → Дополнительные параметры системы → Загрузка и восстановление → Параметры. В поле «Запись отладочной информации» должно стоять «Малый дамп памяти (256 КБ)» или больше. После настройки следующий BSOD создаст файл.
Часто задаваемые вопросы
Можно ли посмотреть Event Viewer без прав администратора?
Часть журналов (например, Application) открывается под обычным пользователем, но системные (Security, часть System) требуют админских прав. Запуск через eventvwr.msc от админа решает вопрос полностью.
Что делать, если событий слишком много и фильтры не помогают?
Используйте PowerShell для поиска. Команда Get-EventLog -LogName System -Newest 100 -EntryType Error покажет последние 100 ошибок системного журнала. Можно фильтровать по источнику, времени, искать конкретный текст в описании через цепочку с Where-Object.
Можно ли увеличить размер журналов, чтобы записи хранились дольше?
Да. Правый клик на нужном журнале → Свойства → меняете «Максимальный размер журнала». Можно выставить хоть гигабайт. Это особенно полезно для журнала Security, который обычно переполняется быстро.
Безопасно ли очищать журналы вручную?
Технически да — никакие функции системы не сломаются. Но вы потеряете историю событий, что мешает диагностике. Лучше увеличить размер журналов, чем регулярно очищать. Если действительно нужно очистить (например, для приватности перед продажей ПК), это делается через Очистить журнал в контекстном меню нужного журнала.
Что значит «не удаётся открыть журнал событий»?
Обычно служба «Журнал событий Windows» (eventlog) остановлена или повреждена. Откройте services.msc, найдите эту службу, убедитесь что она запущена и стоит в автозагрузку. Если служба не запускается, поможет восстановление системы через DISM и SFC.
Записывает ли Event Viewer что-то лишнее, замедляющее систему?
Логирование само по себе очень лёгкая операция — пишутся текстовые записи в журналы, на производительность это влияет минимально. Замедление возможно только если включён детальный аудит безопасности (он отключен по умолчанию) и журнал заполняется тысячами событий в секунду. Для обычного пользователя такой риск исключён.
Полезная статья?
Ваша оценка
поможет нам стать лучше









