Журнал событий Windows: где посмотреть логи и ошибки

Как посмотреть логи (журнал событий) в Windows

Ведущий системный администратор · Сетевая инфраструктура в облаке

9 мин чтения

Чтобы быстро открыть журнал, нажмите Win+R, введите eventvwr.msc и нажмите Enter. Откроется оснастка «Просмотр событий». В ней хранятся все логи Windows: системные события, ошибки приложений, входы пользователей. Далее разберём, какие коды событий соответствуют внезапной перезагрузке, синему экрану или падению службы. Покажем, как выбирать события из PowerShell и как проверить входы по RDP на сервере. Инструкция подходит для Windows 10, 11 и Windows Server.

Что понадобится и как устроены журналы Windows

Права доступа и версии Windows

Учётная запись с правами администратора. Без них журнал «Безопасность» и часть служебных каналов не откроются. Для чтения хватит членства в локальной группе «Читатели журнала событий» (Event Log Readers).
Поддерживаемая версия ОС: Windows 11, Windows Server 2019, 2022 или 2025. Windows 10 подойдёт, но её поддержка закончилась 14 октября 2025 года, и без ESU она не получает исправлений безопасности.
PowerShell: встроенный Windows PowerShell 5.1 или PowerShell 7.

Настройки размера журнала и политики аудита из шагов 3 и 4 лучше сначала проверить на отдельной машине. Подойдёт облачный сервер на Windows от Cloud4U. Его можно развернуть с нужной версией Windows Server и лицензией провайдера или своим ключом.

Журнал событий и «Просмотр событий»: файлы в winevt\Logs

Журнал событий Windows (Windows Event Log) — это служба EventLog и набор файлов, в которые она записывает события. «Просмотр событий» (Event Viewer, eventvwr.msc) — оснастка MMC, через которую эти файлы читают. Закрытие оснастки на запись не влияет, а остановка службы её прекращает.

Файлы хранятся в C:\Windows\System32\winevt\Logs, у каждого журнала свой .evtx: System.evtx, Application.evtx, Security.evtx и десятки журналов приложений и служб. Символ %4 в имени файла заменяет /. Активные файлы .evtx служба держит открытыми, поэтому журнал не копируют, а экспортируют, как в шаге 3.

Результат: вы знаете, где лежат журналы и под какой учётной записью их читать.

Шаг 1. Открытие «Просмотра событий»

Окно «Выполнить» и команда eventvwr.msc

Нажмите Win+R.
Введите eventvwr.msc (или просто eventvwr).
Нажмите Enter. Чтобы запустить оснастку с правами администратора, нажмите Ctrl+Shift+Enter.

С именем компьютера eventvwr подключается к журналам удалённой машины:

eventvwr srv-app01

Меню Win+X, поиск, «Инструменты Windows» и «Управление компьютером»

Меню Win+X: пункт «Просмотр событий».
Поиск на панели задач: «просмотр событий» или «event viewer».
«Инструменты Windows» в Windows 11 (в Windows 10 — «Средства администрирования Windows»).
«Диспетчер серверов» на Windows Server: «Средства → Просмотр событий».
«Управление компьютером» (compmgmt.msc): журналы рядом со службами и дисками.

Результат: оснастка открыта. Слева дерево журналов, в центре сводка административных событий за час, сутки и 7 дней.

Шаг 2. Поиск системных событий, ошибок и сбоев служб

Журналы «Система», «Приложение», «Безопасность» и «Установка»

Система: драйверы, службы, загрузка и выключение, питание, диски, сеть. Здесь ищут причину перезагрузок и BSOD.
Приложение: падения программ, ошибки СУБД, события антивируса. Сюда пишет только ПО, которое само сообщает о событиях.
Безопасность: входы пользователей, изменения учётных записей, доступ к объектам. Состав определяет политика аудита.
Установка: обновления, роли и компоненты.

У каждого события есть уровень: «Критический», «Ошибка», «Предупреждение», «Сведения». В журнале «Безопасность» вместо уровней используются «Аудит успеха» и «Аудит отказа». В карточке события на вкладке «Общие» видны текст, код (Event ID), источник и время, а на вкладке «Подробности» в режиме XML — все поля (IP-адрес, тип входа, код ошибки), по которым строят фильтры в PowerShell.

Фильтр по уровню, коду и времени, настраиваемые представления

Пример: сервер ночью перезагрузился.

Выберите журнал «Система» и нажмите «Фильтр текущего журнала».
В поле «Дата» укажите «Последние 24 часа».
Отметьте уровни «Критический», «Ошибка», «Предупреждение».
В поле кодов введите 41,1074,6005,6006,6008,1001. Поле понимает диапазоны (7000-7040) и исключения (-7036).

Фильтр сохраняют через «Действие → Создать настраиваемое представление» и экспортируют в XML для другого сервера. Начинать осмотр удобно со встроенного представления «Административные события».

Даже на исправной системе накапливаются сотни ошибок (DCOM 10016, тайм-ауты служб), поэтому мы смотрим на три признака:

совпадение по времени с симптомом: событие за 1–5 минут до сбоя важнее недельной давности;
повторяемость: ошибка при каждом сбое — главный кандидат в причины;
уровень «Критический»: такие события пишутся редко и почти всегда указывают на реальную проблему.

Общую картину по дням показывает Монитор стабильности (perfmon /rel).

Ключевые коды событий: от симптома к причине

Внезапное выключение:

41 (Kernel-Power). Загрузка без корректного завершения работы. BugcheckCode = 0 означает пропадание питания, сброс или зависание, ненулевое значение — синий экран.
6008 (EventLog). Неожиданное завершение работы, указано время сбоя.

Перезагрузка:

1074 (User32). Кто инициировал перезагрузку: процесс (например, TrustedInstaller.exe при обновлениях), учётная запись и причина.
6005 и 6006. Старт и остановка службы журнала: метки загрузки и штатного выключения.

Синий экран (BSOD):

1001 (BugCheck, «Система»). В событии указаны stop-код (например, 0x0000009f) и путь к дампу: C:\Windows\MEMORY.DMP или C:\Windows\Minidump. Одноимённое событие 1001 в журнале «Приложение» пишет Windows Error Reporting, к BSOD оно не относится.

Приложения и службы:

1000 (Application Error). Аварийное завершение процесса с указанием модуля, в котором произошёл сбой. Повторяющийся модуль обычно и есть причина.
7031 и 7034 (Service Control Manager). Служба аварийно завершилась.
7000 и 7009. Служба не запустилась или не ответила вовремя.

Результат: вы умеете отфильтровать журнал под конкретный симптом.

Шаг 3. Просмотр журналов через PowerShell и wevtutil

Get-WinEvent: выборка ошибок, сбоев служб и перезагрузок

Используйте Get-WinEvent. Устаревший Get-EventLog не видит журналы приложений и служб, а в PowerShell 7 его нет. -FilterHashtable фильтрует на стороне службы и работает в разы быстрее Where-Object.

Критические события и ошибки за сутки (Level: 1 — критический, 2 — ошибка, 3 — предупреждение):

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

История выключений и перезагрузок:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1074,6005,6006,6008} -MaxEvents 30

Падения приложений за неделю с выгрузкой в CSV:

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000; StartTime=(Get-Date).AddDays(-7)} `
    -ErrorAction SilentlyContinue | Export-Csv C:\Temp\app-crashes.csv -NoTypeInformation -Encoding UTF8

-ErrorAction SilentlyContinue нужен, потому что при отсутствии событий Get-WinEvent возвращает ошибку, а не пустой результат. В PowerShell 7 для корректной кириллицы в Excel укажите -Encoding utf8BOM.

wevtutil: запросы, экспорт и управление журналами

wevtutil работает в обычной командной строке:

wevtutil qe System /q:"*[System[(Level=1 or Level=2)]]" /c:20 /rd:true /f:text
wevtutil epl System C:\Temp\System-errors.evtx /q:"*[System[(Level=1 or Level=2)]]"

Команда el выводит список журналов, gl показывает настройки журнала, qe выбирает события по запросу XPath (/rd:true выводит от новых к старым), epl экспортирует события в .evtx. Команда wevtutil cl очищает журнал безвозвратно. Очистка журнала «Безопасность» оставляет событие 1102, которое вызовет вопросы на аудите.

Результат: вы выбираете события из консоли и сохраняете их в CSV или .evtx.

Шаг 4. Журналы на Windows Server: RDP, удалённый просмотр и хранение

Входы по RDP и перебор паролей: события 1149, 4624, 4625

1149 в TerminalServices-RemoteConnectionManager/Operational: учётные данные проверены, в событии указаны пользователь и IP клиента.
21, 24 и 25 в TerminalServices-LocalSessionManager/Operational: вход в сеанс, отключение и повторное подключение.
4624 и 4625 в журнале «Безопасность»: успешный и неудачный вход. Сеансу RDP соответствует тип входа 10, но при включённом NLA неудачные попытки пишутся с типом 3. Фильтр «только тип 10» пропустит почти весь перебор.
4740: учётная запись заблокирована.

Признак перебора — сотни событий 4625 с одного адреса под разными логинами. Скрипт группирует их за сутки по IP независимо от языка системы:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)} |
    ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' } |
    Group-Object '#text' | Sort-Object Count -Descending | Select-Object Count, Name -First 15

Если в верхних строках внешние адреса, закройте порт 3389 из интернета (VPN, RD Gateway или правило брандмауэра) и включите политику блокировки учётных записей.

Удалённое подключение к журналам другого сервера

В оснастке это пункт «Подключиться к другому компьютеру», в PowerShell:

Get-WinEvent -ComputerName srv-app01 -FilterHashtable @{LogName='System'; Level=1,2} -MaxEvents 50

На удалённой стороне нужны права администратора или членство в группе «Читатели журнала событий». Также должна быть включена группа правил брандмауэра «Удаленное управление журналом событий»: Get-WinEvent работает через RPC (порты 135 и 445), а не через WinRM. Если открыт только WinRM, используйте Invoke-Command.

Для парка серверов настраивают Windows Event Forwarding (wecutil qc на сборщике) или отправку событий в SIEM. Стандарты вроде ISO 27001 и PCI DSS требуют защищать журналы безопасности от изменения и хранить их заданный срок. Централизованный сбор помогает выполнить эти требования, одного локального журнала обычно недостаточно.

Размер журнала, перезапись и архивация событий

По умолчанию основные журналы обычно ограничены 20 МБ с перезаписью. На загруженном сервере журнал «Безопасность» такого размера покрывает считаные часы. Увеличьте размер и включите архивацию:

wevtutil sl Security /ms:2147483648
wevtutil sl Security /rt:true /ab:true

/rt:true запрещает перезапись, а /ab:true при заполнении сохраняет журнал в Archive-Security-<дата>.evtx. Архивы автоматически не удаляются — следите за местом на диске. Групповая политика домена перезапишет локальные настройки.

Результат: вы видите, кто подключался к серверу, читаете журналы соседних машин и не теряете события из-за перезаписи.

Разбор частых проблем: если что-то пошло не так

Даже при правильных настройках администраторы периодически сталкиваются с типовыми ошибками. Вот как их быстро диагностировать.

Ошибки доступа и сети

Если оснастка выдаёт «Доступ запрещён», убедитесь, что запускаете её от имени администратора, или добавьте свою учётную запись в локальную группу «Читатели журнала событий». Если видите «RPC-сервер недоступен», проблема на уровне сети: на целевой машине не включены правила брандмауэра или трафик режет промежуточный фаервол. Быстро проверить порт поможет команда:

Test-NetConnection srv-app01 -Port 135

Пустые журналы и потеря событий

Если в журнале «Безопасность» тишина, скорее всего, на уровне политик не включён аудит входа. Если же старые события регулярно исчезают, значит, журнал переполняется и перезаписывается. В обоих случаях возвращайтесь к Шагу 4: увеличивайте размер .evtx, включайте архивацию или настраивайте централизованный сбор (WEF/SIEM).

Специфика виртуальных машин

Если вы видите событие 41 (Kernel-Power) на виртуальной машине, но при этом не было синего экрана (BSOD), не ищите причину внутри гостевой ОС. Гостевая Windows не видит событий гипервизора или сбои физического хоста. Причину внезапной перезагрузки ищите в журнале задач панели управления облаком или запросите логи у провайдера, отталкиваясь от времени из события 6008.
После того как вы убедились, что логи пишутся корректно, сохраните созданные настраиваемые представления в XML и раздайте их коллегам — это сэкономит часы работы при расследовании инцидентов.

Итоги: зачем системному администратору дружить с журналами событий

Журналы Windows — это не просто «читалка логов», а главный инструмент для расследования инцидентов, от поиска причин BSOD до отслеживания действий злоумышленников.
Подведём главные выводы:

Для быстрого поиска используйте «Просмотр событий» (eventvwr.msc) и настраиваемые представления с фильтрами по ключевым кодам (41, 1074, 4625).
Для автоматизации и анализа переходите в PowerShell. Командлет Get-WinEvent позволяет за секунды выгружать статистику сбоев, перебора паролей или падений служб в CSV для дальнейшего разбора.
Для серверной инфраструктуры критично не только читать логи, но и управлять ими: увеличивать размер хранилища, включать архивацию и настраивать централизованный сбор событий, чтобы соответствовать стандартам ИБ и не терять данные при перезаписи.

Ведение и мониторинг журналов — это фундамент стабильной и безопасной инфраструктуры. Если вы хотите быть уверены, что ваши серверы работают прозрачно, а логи надёжно хранятся, используйте выделенные серверы или облачные мощности с предустановленной и настроенной Windows Server.