Исправление ошибок журнала событий windows

В операционных системах семейства Windows реализована довольно неплохая система журналирования событий безопасности. О ней в различных публикациях и обзорах написано много чего хорошего, но эта статья будет про другое. Здесь мы поговорим о проблемах и недоработках в этой системе. Некоторые из рассматриваемых проблем будут некритичными, лишь осложняющими процедуры анализа событий, другие же будут представлять весьма серьезные угрозы безопасности.

Выявленные проблемы проверялись на Windows 7 Максимальная (русская версия), Windows 7 Professional (английская версия), Windows 10 Pro (русская версия), Windows Server 2019 Datacenter (русская версия). Все операционные системы были полностью обновлены.

Проблема № 1. Неудачная система управления параметрами аудита

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

Возьмем Windows 7 и проинсталлируем ее с параметрами по умолчанию. Домен вводить не будем. Посмотрим настройки аудита событий безопасности. Для этого откроем оснастку «Локальные политики безопасности» (secpol.msc, или «Панель управления —> Администрирование —> Локальные политики безопасности») и посмотрим базовые настройки аудита («Параметры безопасности —> Локальные политики —> Политики аудита»).

Как видно, аудит не настроен. Теперь посмотрим расширенные политики аудита («Параметры безопасности —> Конфигурация расширенной политики аудита —> Политики аудита системы — Объект локальной групповой политики»).

Тут аудит тоже не настроен. Раз так, то по идее никаких событий безопасности в журналах быть не должно. Проверяем. Откроем журнал безопасности (eventvwr.exe, или «Панель управление —> Администрирование —> Просмотр событий»).

Вопрос: «Откуда в журнале безопасности события, если аудит вообще не настроен ?!»

Объяснение

Чтобы разобраться в причине подобного поведения, надо залезть «под капот» операционной системы. Начнем с того, что разберемся с базовыми и расширенными политиками аудита.

До Windows Vista были только одни политики аудита, которые сейчас принято называть базовыми. Проблема была в том, что гранулярность управления аудитом в то время была очень низкой. Так, если требовалось отследить доступ к файлам, то включали категорию базовой политики «Аудит доступа к объектам». В результате чего помимо файловых операций в журнал безопасности сыпалась еще куча других «шумовых» событий. Это сильно усложняло обработку журналов и нервировало пользователей.

Microsoft услышала эту «боль» и решила помочь. Проблема в том, что Windows строится по концепции обратной совместимости, и внесение изменений в действующий механизм управления аудитом эту совместимость бы убило. Поэтому вендор пошел другим путем. Он создал новый инструмент и назвал его расширенными политиками аудита.

Суть инструмента заключается в том, что из категорий базовых политик аудита сделали категории расширенных политик, а те, в свою очередь, разделили на подкатегории, которые можно отдельно включать и отключать. Теперь при необходимости отслеживания доступа к файлам в расширенных политиках аудита необходимо активировать только подкатегорию «Файловая система», входящую в категорию «Доступ к объектам». При этом «шумовые» события, связанные с доступом к реестру или фильтрацией сетевого трафика, в журнал безопасности попадать не будут.

Гигантскую путаницу во всю эту схему вносит то, что наименования категорий базовых политик аудита и расширенных не совпадают, и по началу может показаться, что это абсолютно разные вещи, однако это не так.

Приведем таблицу соответствия наименования базовых и расширенных категорий управления аудитом

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

Теперь настало время разобраться с тем, где хранятся настройки аудита. Для начала введем ряд понятий:

1. Эффективные политики аудита — информация, хранящаяся в оперативной памяти и определяющая текущие параметры работы модулей операционной системы, реализующих функции аудита.
2. Сохраненные политики аудита — информация, хранящаяся в реестре по адресу HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и используемая для определения эффективных политик аудита после перезагрузки системы.

Рассмотрим различные средства администрирования и укажем, какие параметры аудита они отображают, а какие устанавливают. Данные в таблице получены на основании экспериментов.

Поясним таблицу на примерах.

Пример 1

Если запустить утилиту auditpol на просмотр параметров аудита:
auditpol /get /category:*, то будут отображены сохраненные параметры аудита, то есть те, что хранятся в реестре по адресу HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv.

Пример 2

Если же запустить эту же утилиту, но уже на установку параметров:
auditpol /set /category:*, то будут изменены эффективные настройки аудита и сохраненные параметры аудита.

Отдельного комментария требует порядок отображения параметров аудита в «Базовых политиках аудита» оснастки «Локальные политики безопасности». Категория базовой политики аудита отображается как установленная, если установлены все подкатегории соответствующей ей расширенной политики аудита. Если хотя бы одна из них не установлена, то политика будет отображаться как не установленная.

Пример 3

Администратор с помощью команды auditpol /set /category:* установил все подкатегории аудита в режим «Аудит успехов». При этом если зайти в «Базовые политики аудита» оснастки «Локальные политики безопасности», то напротив каждой категории будет установлено «Аудит успеха».

Пример 4

Теперь администратор выполнил команду auditpol /clear и сбросил все настройки аудита. Затем он установил аудит файловой системы, выполнив команду auditpol /set /subcategory:"Файловая система". Теперь, если зайти в «Базовые политики аудита» оснастки «Локальные политики безопасности», то все категории будут определены в состояние «Нет аудита», так как ни одна категория расширенной политики аудита не определена полностью.

Сейчас, наконец-то, мы сможем ответить на вопрос, откуда логи в свежеустановленной операционной системе. Все дело в том, что после инсталляции аудит в Windows настроен и определен в сохраненных параметрах аудита. В этом можно убедиться, выполнив команду auditpol /get /category:*.

В «Базовых политиках аудита» оснастки «Локальные политики безопасности» эти сведения об аудите не отображаются, так как во всех категориях не определена одна или более подкатегорий. В «Расширенных политиках аудита» оснастки «Локальные политики безопасности» эти сведения не отображаются, так как оснастка работает только c параметрами аудита, хранящимися в файле %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv.

В чем суть проблемы?

По началу может показаться, что все это и не проблема вовсе, но это не так. То, что все инструменты показывают параметры аудита по разному, создает возможность к злонамеренному манипулированию политиками и, как следствие, результатами аудита.

Рассмотрим вероятный сценарий

Пусть в корпоративной сети работает технологическая рабочая станция на базе Windows 7.

Машина не включена в домен и выполняет функции робота, ежедневно отправляющего отчетность в контролирующие органы. Злоумышленники тем или иным образом получили на ней удаленный доступ с правами администратора. При этом основная цель злоумышлеников — шпионаж, а задача — оставаться в системе незамеченными. Злоумышленники решили скрытно, чтоб в журнале безопасности не было событий с кодом 4719 «Аудит изменения политики», отключить аудит доступа к файлам, но при этом чтобы все инструменты администрирования говорили, что аудит включен. Для достижения поставленной задачи они выполнили следующие действия:

1. На атакуемой рабочей станции предоставили себе права на запись к ключу реестра HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv и экспортировали этот ключ в файл c именем «+fs.reg».
2. На другом компьютере импортировали данный файл, перезагрузились, а затем с помощью auditpol отключили аудит файловой системы, после чего экспортировали указанный выше ключ реестра в файл «-fs.reg».
3. На атакуемой машине импортировали в реестр файл «-fs.reg».
4. Создали резервную копию файла %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv, расположенного на атакуемой машине, а затем удалили из него подкатегорию «Файловая система».
5. Перезагрузили атакуемую рабочую станцию, а затем подменили на ней файл %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv ранее сохраненной резервной копией, а также импортировали в реестр файл «+fs.reg»

В результате всех этих манипуляций в журнале безопасности нет записей об изменении политики, все инструменты показывают, что аудит включен, а по факту он не работает.

Проблема № 2. Неудачная реализация журналирования операций удаления файлов, каталогов и ключей реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

На одну операцию удаления файла, каталога или ключа реестра операционная система генерирует последовательность событий с кодами 4663 и 4660. Проблема в том, что из всего потока событий данную парочку не так уж просто связать друг с другом. Для того чтобы это сделать, анализируемые события должны обладать следующими параметрами:

Событие 1. Код 4663 «Выполнена попытка получения доступа к объекту». Параметры события:
«ObjectType» = File.
«ObjectName» = имя удаляемого файла или каталога.
«HandleId» = дескриптор удаляемого файла.
«AcessMask» = 0x10000 (Данный код соответствует операции DELETE. С расшифровкой всех кодов операций можно ознакомиться на сайте Microsoft).

Событие 2. Код 4660 «Объект удален».
Параметры события:

«HandleId» = «HandleId события 1»
«System\EventRecordID» = «System\EventRecordID из события 1» + 1.

С удалением ключа (key) реестра всё то же самое, только в первом событии с кодом 4663 параметр «ObjectType» = Key.

Отметим, что удаление значений (values) в реестре описывается другим событием (код 4657) и подобных проблем не вызывает.

Особенности удаления файлов в Windows 10 и Server 2019

В Windows 10 / Server 2019 процедура удаления файла описывается двумя способами.

1. Если файл удаляется в корзину, то как и раньше — последовательностью событий 4663 и 4660.
2. Если же файл удаляется безвозвратно (мимо корзины), то одиночным событием с кодом 4659.

Случилось странное. Если раньше для определения удаленных файлов нужно было мониторить совокупность событий 4663 и 4660, то сейчас Microsoft «пошла пользователям на встречу», и вместо двух событий теперь надо мониторить три. Также стоит отметить, что процедура удаления каталогов не поменялась, она как и раньше состоит из двух событий 4663 и 4660.

В чем суть проблемы?

Проблема заключается в том, что узнать кто удалил файл или каталог, становится нетривиальной задачей. Вместо банального поиска соответствующего события по журналу безопасности необходимо анализировать последовательности событий, что вручную делать довольно трудоемко. На хабре даже по этому поводу была статья: «Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell».

Проблема № 3 (критическая). Неудачная реализация журналирования операции переименования файлов, каталогов и ключей реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

Эта проблема состоит из двух подпроблем:

1. В событиях, генерируемых системой во время переименования, нигде не фиксируется новое имя объекта.
2. Процедура переименования очень похожа на удаление. Отличить ее можно только по тому, что за первым событием с кодом 4663, с параметром «AcessMask» = 0x10000 (DELETE) не идет событие 4660.

Стоит отметить, что применительно к реестру эта проблема распространяется только на ключи (keys). Переименование значений (value) в реестре описывается последовательностью событий 4657 и подобных нареканий не вызывает, хотя, конечно, было бы гораздо удобней, если бы было только одно событие.

В чем суть проблемы?

Помимо затруднения поиска операций переименования файлов подобная особенность журналирования не позволяет отследить полный жизненный цикл объектов файловой системы или ключей реестра. В результате чего на активно используемом файловом сервере становится крайне затруднительно определить историю файла, который многократно переименовывался.

Проблема № 4 (критическая). Невозможно отследить создание каталога и ключа реестра

Наличие проблемы подтверждено на Windows 7/10/Server 2019.

Описание проблемы

Windows не позволяет отследить создание каталога файловой системы и ключа реестра. Это заключается в том, что операционная система не генерирует событие, в котором содержалось бы имя создаваемого каталога или ключа реестра, и параметры которого указывали бы на то, что это именно операция создания.

Теоретически по косвенным признакам выявить факт создания каталога возможно. Например, если он создавался через «Проводник», то в процессе создания будут сгенерированы события опроса атрибутов нового каталога. Проблема в том, что если создать каталог через команду mkdir, то вообще никакие события не генерируются. Всё то же самое справедливо и для создания ключей в реестре.

В чем суть проблемы?

Эта проблема существенно затрудняет проведение расследований инцидентов информационной безопасности. Нет никаких разумных объяснений тому, что в журналах не фиксируется данная информация.

Проблема № 5 (критическая). Сбойные параметры аудита в русских версиях Windows

Наличие проблемы подтверждено на русских редакциях Windows 7/10/Server 2019.

Описание проблемы

В русских версиях Windows есть ошибка, приводящая систему управления аудитом безопасности в нерабочее состояние.

Симптомы

Изменение расширенных политик безопасности не оказывает никакого влияния на эффективные параметры аудита, или, другими словами, политики не применяются. Например, администратор активировал подкатегорию «Вход в систему», перезагрузил систему, запускает команду auditpol /get /category:*, а данная подкатегория остается не активной. Проблема актуальна как для доменных компьютеров, управляемых через групповые политики, так и для не доменных, управляемых с помощью локального объекта групповой политики, конфигурируемого через оснастку «Локальные политики безопасности».

Причины

Проблема возникает, если администратор активировал хотя бы одну из «сбойных» подкатегорий расширенных политик аудита. К подобным сбойным категориям, в частности, относятся:

1. Использование прав —> Аудит использования прав, затрагивающих конфиденциальные данные. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
2. Использование прав —> Аудит использования прав, не затрагивающих конфиденциальные данные. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
3. Доступ к объектам —> Аудит событий, создаваемых приложениями. GUID:{ 0cce9222-69ae-11d9-bed3-505054503030}.

Рекомендации по решению проблемы

Если проблема еще не произошла, то не активируйте указанные «сбойные» подкатегории. Если события этих подкатегорий очень нужны, то пользуйтесь утилитой auditpol для их активации или же управляйте аудитом с помощью базовых политик.

Если проблема произошла, то необходимо:

1. Из каталога доменной групповой политики удалить файл \Machine\microsoft\windows nt\Audit\audit.csv
2. Со всех компьютеров, на которых были выявлены проблемы с аудитом, удалить файлы: %SystemRoot%\security\audit\audit.csv, %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv

В чем суть проблемы?

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

Проблема № 6 (критическая). Будь проклят «Новый текстовый документ.txt…, а также Новый точечный рисунок.bmp»

Наличие проблемы подтверждено на Windows 7. Проблема отсутствует в Windows 10/Server 2019.

Описание проблемы

Это очень странная проблема, которая была обнаружена чисто случайно. Суть проблемы в том, что в операционной системе есть лазейка, позволяющая обойти аудит создания файлов.

Подготовительная часть:

1. Возьмем свежеустановленную Windows 7.
2. Сбросим все настройки аудита с помощью команды auditpol /clear. Данный пункт необязательный и служит только для удобства анализа журналов.
3. Установим аудит файловой системы, выполнив команду auditpol /set /subcategory:"Файловая система".
4. Создадим каталог C:\TEST и назначим ему параметры аудита для учетной записи «Все»: «Создание файлов / Запись данных», «Создание папок / Дозапись данных», «Запись атрибутов», «Запись дополнительных атрибутов», «Удаление вложенных папок и файлов», «Удаление», «Смена разрешений», «Смена владельца», то есть все, что связано с записью данных в файловую систему.

Для наглядности перед каждым экспериментом будем очищать журнал безопасности операционной системы.

Эксперимент 1.
Делаем:

Из командной строки выполним команду: echo > "c:\test\Новый текстовый документ.txt"
Наблюдаем:

По факту создания файла в журнале безопасности появилось событие с кодом 4663, содержащее в поле «ObjectName» имя создаваемого файла, в поле «AccessMask» значение 0x2 («Запись данных или добавление файла»).

Для выполнения следующих экспериментов очистим папку и журнал событий.

Эксперимент 2.
Делаем:

Через «Проводник» откроем папку C:\TEST и с помощью контекстного меню «Создать —> Текстовый документ», вызываемому по клику правой кнопки мыши, создаем файл «Новый текстовый документ.txt».

Наблюдаем:

В журнале событий данное действие никак не отразилось!!! Также никаких записей не будет, если с помощью того же контекстного меню создать «Точечный рисунок».

Эксперимент 3.
Делаем:

Через «Проводник» откроем папку C:\TEST и с помощью контекстного меню «Создать —> Документ в формате RTF», вызываемому по клику правой кнопки мыши, создаем файл «Новый документ в формате RTF.rtf».

Наблюдаем:

Как и в случае с созданием файла через командную строку в журнале появилось событие с кодом 4663 и соответствующим наполнением.

В чем суть проблемы?

Конечно создание текстовых документов или картинок особого вреда не представляет. Однако, если «Проводник» умеет обходить журналирование файловых операций, то это смогут сделать и вредоносы.

Данная проблема является, пожалуй, наиболее значимой из всех рассмотренных, поскольку серьезно подрывает доверие к результатам работы аудита файловых операций.

Заключение

Приведенный перечень проблем не исчерпывающий. В процессе работы удалось споткнуться о еще довольно большое количество различных мелких недоработок, к которым можно отнести использование локализованных констант в качестве значений параметров ряда событий, что заставляет писать свои анализирующие скрипты под каждую локализацию операционной системы, нелогичное разделение кодов событий на близкие по смыслу операции, например, удаление ключа реестра — это последовательность событий 4663 и 4660, а удаление значения в реестре — 4657, ну и еще по мелочи…

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

MAKE WINDOWS SECURITY EVENT LOGGING GREAT AGAIN!

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

Зачастую люди, нечистые на руку, пользуются Журналом событий Windows для обмана пользователей – вредоносное ПО, проникшее в ПК, отсылает в журнал предостережение об ошибке в работе ОС. Далее, информационный преступник, звонит выбранному для обманных действий пользователю. Он просит открыть Просмотр событий, представившись перед тем сотрудником Майкрософт, чтобы жертва увидела уведомление об серьезной ошибке в системе. Обманщик просит информацию по кредитной карте (номер, срок действия и 3 защитные цифры на обороте) для предполагаемого исправления ошибки, которая якобы наносит вред компьютеру. Эта схема обмана достаточно стара, но она до сих пор работает.

Если ваше компьютерное устройство работает нормально, можно не обращать внимание на временами появляющиеся ошибки в Журнале событий в Windows 10. Однако, если в системе возникли сбои, то тогда при помощи Журнала событий можно провести диагностику и узнать от чего они появились.

Как запустить программу Просмотра событий

Чтобы осуществить запуск программы Просмотр событий нужно:

1. Открыть меню Пуск.
2. Ввести в строке поиска «Просмотр событий».
3. Нажать Ввод.

Также данная программа открывается через папку Администрирование в меню Пуск.

Важно знать, что все события распределены по категориям – к примеру, в категории Приложения размещены события приложений, в категории Система находятся системные новости. Если же на ПК настроен анализ событий безопасности (аудит событий входа в систему), то сообщения аудита поступают в категорию Безопасность.

Исправление ошибок в журнале событий

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

Просмотр событий создан для того, чтобы облегчить наблюдение за девайсом Системному администратору, а также помочь в устранении ошибок. Если ПК не сбоит, то ошибка, зарегистрированная в Журнале событий, не несет большой опасности.

Даже извещения, предупреждающие об ошибке, для обычного пользователя компьютера не серьезны. Если у вас есть права Системного администратора, то Журнал событий в Windows 10 поможет вам устранить ошибку на сервере. Если же у вас нет полномочий админа, то этот информационный компонент системы мало чем пригодится.

Просмотр событий: пользовательская инструкция

Пока ваше ПК нормально функционирует, то Журнал событий не сильно нужен. Однако, он очень помогает, когда появляются различные проблемы с компьютерным устройством — самопроизвольная перезагрузка или возникновение экранов смерти. Журнал событий детально информирует о причинах сбоев. Например, регистрация об ошибке в категории Система сообщает про неудачный запуск системной службы или другой сбой.

Журнал событий также можно использовать для мониторинга включения/выключения вашего компьютера. При наличии сервера, который нельзя выключать, можно настроить проверку событий выключения ПК, что дает возможность быстро включать сервер.

Также можно использовать Журнал событий в Windows 10 вместе с Планировщиком задач. Для этого нужно нажать на любое событие правой кнопкой мышки. Далее откроется контекстное меню, где нужно выбрать «Привязать задачу к событию». Когда появится такое событие, система автоматически запустит исполнение созданной задачи.

Похожие записи

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

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

Как правило, если ваш компьютер работает без нареканий, можно сильно не переживать, если иногда появляются ошибки в журнале событий Windows. Но если система сбоит, тогда журнал событий может вам сильно помочь с диагностикой проблемы.

Запуск программы Просмотр событий

Для запуска программы Просмотр событий, откройте меню Пуск, в строке поиска введите «Просмотр событий» и нажмите Ввод. Также программу Просмотр событий можно открыть через папку Администрирование в меню Пуск.

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

Ошибки в журнале — не повод впадать в депрессию

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

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

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

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

Как пользоваться программаой Просмотр событий

Если у вас возник вопрос: а зачем мне вообще нужен какой-то Журнал событий? Действительно, пока ваш компьютер работает как часы — вам журнал событий не нужен, но он может пригодиться, если у вас возникли проблемы с компьютером, например тот стал самопроизвольно перезагружаться, или стали появляться синие экраны смерти. В журнале событий вы сможете найти более детальную информацию о причинах. Например, запись об ошибке, в журнале Система может сообщать про неудачную попытку запуска системной службы, или другую ошибку. В интернет можно найти информацию по каждому из ID ошибки (Код события).

В поисковике введите Event ID: ID_ОШИБКИ, и ві получите предостаточно информации по данной ошибке.

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

Запуск задач, в ответ на события в журнале событий Windows

Вы можете использовать Журнал событий WIndows в паре с Планировщиком заданий — нажмите правой кнопкой мыши на любом событии и в открывшемся контекстном меню выберите пункт Привязать задачу к событию. В следующий раз, когда произойдет такое событие, Windows автоматически запустит выполнение соданного задания.

Learn how to check, understand, and filter error logs on your PC

by Kazim Ali Alvi

Kazim has always been fond of technology, be it scrolling through the settings on his iPhone, Android device, or Windows. And at times, unscrewing the device to take… read more

Updated on August 18, 2023

Whenever you encounter an error in Windows, it certainly is a cause for concern. But, we often do not bother discovering what caused it or don’t know how to

Error logs, as the name suggests, are the log files that store all the information as to why the error happened, the program or process that lead to it, along the exact date and time of it.

But it’s certainly not easy to decipher the information listed there. Therefore, we have dedicated this guide to help you understand how to check the error logs in Windows 11, the various types, add filters, and clear them.

Why do I need to check Windows 11 error logs?

Checking error logs on Windows 11 allows you to find the underlying cause of an issue.

For example, if Windows 11 is unstable and crashes frequently or encounters a BSOD (Blue Screen of Death) error, you can go to the event logs, check for the one created at the time of the crash, and find out what caused it.

Though do remember that you are likely to come across a lot of errors and warnings here, and there’s nothing to panic about. If you don’t notice any problem with the system, simply ignore these.

Where can I find error logs?

Error logs on Windows 11 can be found in the event log in Event Viewer. This feature contains the unexpected issues your PC encounters, the exact date and time, and the cause.

Does Windows Keep an error log?

One of the advantages of the Windows operating system is that it keeps a log of the important happenings on your PC. This includes a log of the errors that occur.

As mentioned earlier, this can be found in the Event Viewer.

How do I check error logs in Windows 11?

In this article

• Why do I need to check Windows 11 error logs?
• How do I check error logs in Windows 11?
• How to understand Windows 11 error logs?
• What are the different types of error logs?
• How can I filter error logs?
• How to create a custom view to check a particular category and level of logs in Windows 11?
• How can I clear error logs in Windows 11?
• How do I create my own log file in Windows 11?

It’s pretty simple and quick to access the error logs on your Windows 11 OS, but in case you didn’t used before, the steps below will surely help you find them.

1. Press Windows + S to launch the Search menu, enter Event Viewer in the text field at the top, and click on the relevant search result.

2. Double-click on Windows Logs in the navigation pane on the left.

3. You will now find the five different categories. Select any of these, and all the error logs under it will be listed on the right.

4. Now, click on any of the error logs to view all the relevant information about them.

You now know how to check the Windows 11 error logs, but just knowing that won’t suffice. There’s still a lot out there to understand before you can actually make some sense out of these logs, and use them to your advantage.

How to understand Windows 11 error logs?

When you view a log, the general details and the Event ID is critical in identifying and eliminating the error. Apart from that, there’s an Event Log Online Help link at the bottom, which may provide some valuable insights.

For instance, here’s a Windows 11 error log when the relevant driver for a device failed to load.

The 219 Event ID helped find out a lot of information along with the relevant fixes for the problem.

We just did a Google search for this Event ID and there were a plethora of results. But this requires a proper understanding of Windows 11 error logs.

But, it’s important to mention here that not all error logs will be as descriptive. Some might have things that you wouldn’t be able to comprehend or use jargon excessively. No matter the case, a simple Google search would suffice.

What are the different types of error logs?

When you go through the Windows 11 error logs, there are basically three important categories, referred to as Event Level, under which these are placed. And, the categories define the severity of the event for which the log is created. The three categories are as follows:

• Information: These are created when an operation goes through successfully. For instance, when a driver is loaded or an application is launched without encountering any issues.
• Warning: These are created when the OS finds an issue with the system. These issues do not pose an imminent risk, but could be problematic in the future. For instance, if you are running low on disk space, a log will be created.
• Error: These indicate a major problem, though most of the time, Windows takes care of these as well. As an example, if a driver or service does not load, an error log will be created. But, these are the most critical ones of all.

If you are identifying problems with the PC, ignore the Information logs, go through the Warning logs, but pay special attention to the ones categorized as Error, since these are most likely to record the problem you are looking for.

When you open the Event Viewer in Windows 11, it will list out all three. The view will remain the same if you have not changed the Windows 11 Error Reporting logs location in the in the Group Policy.

But identifying all logs for one of these levels will take up a lot of your time. This is where filtering error logs comes to your aid. Check the next section to find out how you can do that.

How can I filter error logs?

1. Open the Event Viewer, navigate to the particular category of logs from the left, and then click on Filter Current Log on the right.
2. Next, click on the Logged dropdown menu to select the duration for which you want to check the logs.
3. Now, select a time duration from the list of options. You can also choose the last option to create a custom range.
4. Once done, tick the checkboxes for the Event Levels that you want to filter.
5. Finally, click on OK at the bottom to filter the error logs.
6. All the errors logs that fall under the choosen filters will now be listed.

We selected the duration as 24 hours, and level as Error, and filtered the logs. Event Viewer then listed the four Windows 11 error logs that were created during that time.

Read more about this topic

• How to Change the Hyper-V Display Resolution [Windows 11 Guide]
• How to Convert Dynamic Disk to Basic on Windows 11
• Set up Hyper-V USB Passthrough on Windows 11
• Fix: Keyboard Shortcuts are Not Working in Photoshop
• How to Setup RAID 1 on Windows 11

How to create a custom view to check a particular category and level of logs in Windows 11?

1. Open the Event Viewer and click on Create Custom View on the right.
2. Next, select the duration and Event Level, as you did earlier when creating a filter.
3. With the By logs option selected, click on the Event logs dropdown menu, double-click on the Windows Logs entry to expand and view the various categories, and tick the checkboxes for the desired ones.
4. Now, click on OK at the bottom to set filters for the new custom view.
5. Enter a Name and Description for the custom view and click on OK.
6. The new custom view will now be listed on the left, and all logs falling under it on the right.

How can I clear error logs in Windows 11?

1. Launch the Event Viewer, navigate to the relevant category, and click on Clear Log from the list of options on the right.
2. You now have two options, either Save and Clear the error logs or directly Clear them. Choose the desired option.
3. If you selected Save and clear, choose the location for the file, add a name for it and click on Save.
4. Once saved, they error logs will be cleared right away and there will be none listed under that particular category.
5. In case you saved the error logs before deleting them, these can be found under Saved Logs in the navigation pane on the left.

The OS creates thousands of logs for each type of event, be it the successful launch of a driver and service or the most fatal errors. Like any other file, these too consume space on your hard disk, no matter how small it is.

So, if you are running out of space, or just want a more organized Event Viewer, clearing the Windows 11 error logs may help.

How do I create my own log file in Windows 11?

1. Press Windows + S to launch the Search menu, enter Notepad in the text field at the top, and click on the relevant search result that appears.
2. Enter .LOG in the very first line of the Notepad.
3. Click on the File menu, and select Save from the list of options.
4. Next, choose the location and name for the file, and click on Save at the bottom. Now, close the Notepad.
5. Once the log file is created, the current date and time will be mentioned everytime you open it, and you can enter whatever you want to and hit Ctrl + S to save it.
6. Now, when you open the same log file the next time, the previously added entry will be listed under that date and time, and the current date and time will again be mentioned below the last entry.

A log file is used to basically record data. Windows uses it for errors, warnings, and information, while you can use it for other purposes.

Creating a log file is simple, and so is maintaining it. Say, you want to record the progress for a book that you are reading, just create a log file, and enter the number of pages you read each day, or as you may please.

That’s all you need to know about Windows 11 error logs. From now on, identifying the underlying cause and troubleshooting both trivial and intricate errors should not be a problem anymore.

Also, if you feel that Event Viewer does not meet all your requirements, check the best apps to view errors logs in Windows 11. And if Event Viewer is not working in Windows 10 and 11, rest assured that our detailed guide will help you.

Do not hesitate to drop a comment if you have any queries or would like us to add a related topic.