Системные журналы Windows накапливают огромный массив сведений о работе операционной системы, приложений и подсистем безопасности, однако графическая оснастка «Просмотр событий» не всегда удобна: на сервере без графического интерфейса, в сеансе удаленного терминала при плохом канале связи или внутри автоматизированного сценария обслуживания нужен инструмент командной строки. Таким инструментом является встроенная утилита wevtutil, присутствующая в каждой установленной системе начиная с Windows Vista. Она позволяет запрашивать записи из любых журналов, экспортировать и очищать архивы, смотреть статистику и настраивать журналы без графической оболочки. Данная статья представляет собой практический инструктаж администратора: от структуры журналов и синтаксиса запросов XPath до готовых приемов поиска сбоев питания, отслеживания перезагрузок и построения простого мониторинга на планировщике задач.
Структура журналов событий Windows
Классическая тройка журналов известна каждому администратору: Application хранит события прикладных программ, System фиксирует работу драйверов, служб и компонентов ядра, Security содержит записи аудита входа, доступа к объектам и изменений политик. Эти журналы существуют десятилетиями и до сих пор остаются основным источником оперативной диагностики. Рядом с ними располагаются журналы Setup, где отмечаются установки компонентов и обновлений, и ForwardedEvents, предназначенный для событий, собранных с удаленных машин через подписки.
Начиная с Vista появился целый кластер так называемых современных журналов службы, именование которых устроено по иерархическому принципу Microsoft-Windows-<Компонент>/<Тип>. Например, Microsoft-Windows-Kernel-Power/Thermal-Operational, Microsoft-Windows-TaskScheduler/Operational, Microsoft-Windows-WindowsUpdateClient/Operational. Слэш здесь является частью имени журнала, а не разделителем пути в файловом смысле. Тип Operational означает рабочий журнал текущей активности компонента, Admin хранит события для администратора, Analytic и Debug содержат подробную трассировку и по умолчанию отключены. Файлы журналов физически размещаются в каталоге C:\Windows\System32\winevt\Logs с расширением evtx.
Полный перечень журналов, зарегистрированных в системе, выдает команда wevtutil el. Она выводит сотни имен, поэтому на практике список удобно перенаправить в файл или профильтровать через findstr: wevtutil el | findstr /I "Power". Утилита wevtutil gl System показывает конфигурацию конкретного журнала: путь к файлу, максимальный размер, политику перезаписи, включен или отключен журнал. Команда wevtutil gli System выдает статистику: количество записей, время создания файла, время первого и последнего события. Эти три команды образуют базовый набор разведки перед любыми запросами: сначала понять, какие журналы есть и насколько они полны, а уже потом извлекать данные.
Запросы к журналам с фильтрацией XPath
Центральная команда утилиты - wevtutil qe, выполняющая выборку событий. Классическая задача «вытащить все ошибки из системного журнала за последние сутки» решается одной строкой:
wevtutil qe System /q:"*[System[(Level=2) and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
Разберем ее по частям. Атрибут /q принимает XPath-выражение. Звездочка соответствует любому событию, а внутри квадратных скобок указаны условия на узел System, в котором живут служебные поля записи. Level=2 означает уровень «Ошибка» (1 - критическое, 2 - ошибка, 3 - предупреждение, 4 - сведения). Конструкция TimeCreated[timediff(@SystemTime) <= 86400000] сравнивает разницу между текущим моментом и временем создания события с количеством миллисекунд в сутках. Вместо timediff(@SystemTime) можно взять фиксированную форму @SystemTime с датой в формате ISO, но для относительных окон timediff удобнее.
Важно понимать границы: движок запросов Windows реализует лишь подмножество XPath 1.0. В нем нет функций starts-with, contains или substring, нельзя свободно сравнивать произвольные строки и строить сложные вычисления. Доступны сравнения равенства, неравенства и порядка, логические операторы and и or внутри одного фильтра, обращение к стандартным полям узла Event и оператор position для выбора первой или последней записи. Если нужен поиск подстроки в поле EventData, приходится выгружать данные шире и фильтровать уже на стороне конвейера, например через findstr. Исторически для старых форматов существовал также синтаксис /q с упрощенными выражениями, но на современных системах смысла в нем нет.
Полезные управляющие параметры команды qe: /c:50 ограничивает число возвращаемых записей, /rd:true меняет направление чтения, и события идут от новых к старым (удобно в паре с /c, чтобы получить последние N записей). Параметры /f:text, /f:xml и /f:renderedxml определяют формат вывода. Текстовый формат читается человеком, XML полезен для дальнейшей машинной обработки, а renderedxml добавляет локализованные подписи сообщений, которые зависят от языка системы. Для журналов, доступных только с повышенными правами, консоль следует запускать от имени администратора; журнал Security к тому же требует привилегии чтения контролируемых событий.
Экспорт архивов и очистка журналов
Для долговременного хранения и передачи журналов на анализ служит команда wevtutil epl, которая экспортирует журнал целиком в файл evtx: wevtutil epl System "D:\archives\System-2024-backup.evtx". Такой файл открывается оснасткой «Просмотра событий» на любой машине, при этом локализованные сообщения могут отличаться, если язык отличается; для полной переносимости сообщения копируются вместе с экспортом на той же языковой системе.
Очистка выполняется командой wevtutil cl System. Она необратимо удаляет все записи, поэтому в регламентных сценариях ее применяют с опцией резервного копирования: wevtutil cl System /bu:"D:\archives\System-before-clear.evtx". Сначала содержимое сохраняется в указанный файл, затем журнал очищается. Такой прием полезен перед масштабными изменениями конфигурации, при начале длительного наблюдения за новой инцидентной историей или при освобождении места на маленьком системном томе. Операция очистки Security обычно требует особого согласования внутри организации, поскольку журнал безопасности относится к средствам аудита.
Специальный разговор - сам журнал Security. Его размер и политика удержания напрямую влияют на полноту картины расследования: если журнал заполняется за часы, старые записи перезаписываются, и следы действий просто исчезают. Правило хорошей гигиены состоит в том, чтобы ёмкость Security была в несколько раз больше среднего объёма событий за период между выгрузками, политика аудита настраивалась осознанно через политикиивание в secpol или групповых политиках, а сам факт чтения и очистки журнала фиксировался. Просмотреть текущие параметры помогают wevtutil gl Security и wevtutil gli Security, а отключенные модули трассировки Microsoft-Windows-Eventlog/Admin подскажут, что собирает сама служба журналов.
Скриптовый мониторинг на планировщике задач
Когда нет корпоративной системы мониторинга, wevtutil в паре со schtasks превращается в простой оповещающий механизм. Идея такова: пакетный файл раз в интервал времени выполняет запрос на новые ошибки за окно интервала, сохраняет результат в файл и при непустом результате шлет уведомление - записью в общий сетевой журнал, вызовом sendmail-утилиты или фиксацией отметки в приложение Service Desk.
Последовательность настройки выглядит следующим образом:
- Создать каталог сценария, например C:\Scripts\EvtMonitor, и положить туда файл check-errors.cmd с телом: wevtutil qe System /q:"*[System[(Level=2) and TimeCreated[timediff(@SystemTime) <= 900000]]]" /f:text /rd:true /c:20 > "C:\Scripts\EvtMonitor\last-errors.txt"
- Дописать проверку размера файла: if not %%~zA==0 - условие на непустой вывод, после которого выполняется действие оповещения, например копирование файла в сетевую папку наблюдения.
- Зарегистрировать задачу: schtasks /Create /TN "EvtMonitor-Errors" /TR "C:\Scripts\EvtMonitor\check-errors.cmd" /SC MINUTE /MO 15 /RU SYSTEM - задача запускается каждые 15 минут от системной учетной записи, которой доступны локальные журналы.
- Проверить выполнение: schtasks /Query /TN "EvtMonitor-Errors" /V просмотр состояния, а wevtutil gli System позволят убедиться, что последнее событие попадает в окно запроса.
Окно фильтра в 900000 миллисекунд с запасом покрывает пятнадцатиминутный интервал. Схема примитивна, но работает на любой машине без агентов и лицензий, а её легко распространить через групповую политику или софтовую рассылку.
Get-WinEvent против wevtutil
В среде PowerShell аналогом служит командлет Get-WinEvent. Разница принципиальна: Get-WinEvent возвращает объекты EventLogRecord со структурированными свойствами - TimeCreated, Id, LevelDisplayName, Message, Properties, по которым можно удобно сортировать, группировать и фильтровать через Where-Object, тогда как wevtutil выдает текст, который приходится разбирать внешними средствами. Фильтр теперь задается через -FilterHashtable @{ LogName='System'; Level=2; StartTime=(Get-Date).AddDays(-1) }, что читается проще, чем строковый XPath.
При этом у wevtutil остаются ниши: утилита есть везде, работает без загрузки среды PowerShell, одинаково ведет себя в пакетных файлах и из-под schtasks, напрямую умеет экспорт и очистку журналов. На серверных ядрах и в минимальных образах, где PowerShell урезан, wevtutil часто единственный вариант. Разумная практика - в интерактивном анализе использовать Get-WinEvent, а в регламентных заданиях и в минимальных средах - wevtutil.
Типовые сценарии диагностики на практике
Поиск неожиданных завершений работы и синих экранов. Событие Kernel-Power с идентификатором 41 фиксирует ситуацию, когда система завершила работу без корректного выключения: wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and (EventID=41)]]" /rd:true /c:10 /f:text. Поле BugcheckCode в данных события указывает код критической ошибки, ненулевое значение означает проверку дампов памяти в каталоге C:\Windows\Minidump.
Отслеживание перезагрузок. Служба журнала событий отмечает запуск идентификатором 6005 и остановку идентификатором 6006: wevtutil qe System /q:"*[System[(EventID=6005 or EventID=6006) and TimeCreated[timediff(@SystemTime) <= 604800000]]]" /f:text. Выборка за неделю показывает, когда сервер уходил в перезагрузку и как часто это происходило; в паре с событием 6008 (некорректное завершение) картина по аварийным остановам становится полной.
След запуска служб. Остановки и запуски служб фиксирует поставщик Service Control Manager: событие 7036 сообщает о переходах службы между состояниями, 7040 - об изменении типа запуска, а установка новой службы отражается событием 7045: wevtutil qe System /q:"*[System[(EventID=7045)]]" /rd:true /f:renderedxml. Появление неизвестной службы с таким событием - повод немедленно разбираться, кто и когда её установил.
Статистика журнала перед расследованием. Пара команд wevtutil gl Security и wevtutil gli Security покажет путь к файлу, размер и глубину истории; если первый зафиксированный журнал свежий, а надо смотреть старые события, придется поднимать резервные копии evtx из архива: wevtutil qe можно направить и на файл через параметр /lf:true с указанием пути вместо имени журнала.
Сводная ежесменная справка. Быстрый обзор здоровья машины дает одна команда wevtutil qe System /q:"*[System[(Level=1 or Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" /rd:true /c:30 /f:text - критические события, ошибки и предупреждения за сутки в читабельном виде. Такой отчет удобно прикладывать к сменному журналу дежурной смены.
Заключение
Утилита wevtutil закрывает основной круг задач работы с журналами событий Windows без единого щелчка мыши: разведку доступных журналов, точечные выборки по XPath-фильтрам, экспорт и регламентную очистку с резервным копированием. В сочетании с планировщиком задач она строит простейший мониторинг ошибок, а знание идентификаторов Kernel-Power 41, 6005, 6006 и 7045 превращает сырые журналы в рабочий диагностический инструмент. Администратору достаточно освоить структуру современных журналов, ограничения XPath-подмножества и несколько проверенных команд, чтобы на любой машине - от домашнего ноутбука до серверного ядра - за минуты ответить на вопрос, что происходило с системой и когда именно это случилось.