Просмотр «Журнала ошибок» в Windows 10

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

«Журнал ошибок» в Виндовс 10

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

Включение логирования

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

1. Нажмите в любом пустом месте «Панели задач» правой кнопкой мышки. Из контекстного меню выберите пункт «Диспетчер задач».

В открывшемся окне перейдите во вкладку «Службы», а затем на самой странице в самом низу нажмите кнопку «Открыть службы».

Далее в перечне служб нужно найти «Журнал событий Windows». Убедитесь, что она запущена и работает в автоматическом режиме. Об этом должны свидетельствовать надписи в графах «Состояние» и «Тип запуска».

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

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

С включением логирования разобрались. Теперь двигаемся дальше.

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

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

1. Нажмите на клавиатуре одновременно клавишу «Windows» и «R».
2. В строку открывшегося окна введите eventvwr.msc и нажмите «Enter» либо же кнопку «OK» ниже.

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

Анализ журнала ошибок

После того как «Просмотр событий» будет запущен, вы увидите на экране следующее окно.

В левой его части находится древовидная система с разделами. Нас интересует вкладка «Журналы Windows». Нажмите на ее названии один раз ЛКМ. В результате вы увидите список вложенных подразделов и общую статистику в центральной части окна.

Для дальнейшего анализа необходимо зайти в подраздел «Система». В нем находится большой список событий, которые ранее происходили на компьютере. Всего можно выделить четыре типа событий: критическое, ошибка, предупреждение и сведения. Мы вкратце расскажем вам о каждом из них. Обратите внимание, что описать все возможные ошибки мы не можем просто физически. Их много и все они зависят от различных факторов. Поэтому если у вас не получится что-то решить самостоятельно, можете описать проблему в комментариях.

Критическое событие

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

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

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

Ошибка

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

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

Предупреждение

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

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

Сведения

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

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

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

Как получить файлы журнала Windows?

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

1. Откройте программу Просмотр событий (Event Viewer).

В Windows 10 нажмите на значок «Поиск» в панели задач, введите в поисковой строке eventvwr и запустите первую найденную программу (щелкнув на ней мышью или нажав Enter).

Если вы используете Windows 8 или 8.1, то проделайте следующие действия.

Перейдите в меню Поиск:

Введите в поисковой строке eventvwr и запустите первую найденную программу (щелкнув на ней мышью или нажав Enter).

Если вы используете Windows 7 или Vista, нажмите на Пуск, введите в строке поиска eventvwr, и нажмите Enter.

1. Сохраните журналы приложений и системы в отдельные файлы

Окно программы Просмотр событий выглядит как показано ниже на картинке.

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

2.1. Откройте журнал «Приложение» («Просмотр событий (Локальный)» -> «Журналы Windows» -> «Приложение»)

2.2. Щёлкните правой кнопкой мыши по пункту списка «Приложение» и в выпадающем меню выберите «Сохранить все события как . «

2.3. Выберите место сохранения, введите название, нажмите «Сохранить». Выберите «Отображать сведения для следующих языков:». Напротив пункта «Русский» должен быть установлен флажок. Нажмите «Ок».

2.4. Откройте журнал «Система» («Просмотр событий (Локальный)» -> «Журналы Windows» -> «Система»).

2.5. Щёлкните правой кнопкой мыши по пункту меню «Система» и в выпадающем меню выберите «Сохранить все события как . «

2.6. Выберите место сохранения, введите название, нажмите «Сохранить». Выберите «Отображать сведения для следующих языков:». Напротив пункта «Русский» должен быть установлен флажок. Нажмите «Ок».

Полученные два файла пришлите, пожалуйста, службе технической поддержки.

Как установить Windows 10

• Просмотров: 11 948
• Автор: admin
• Дата: 6-01-2018

Как в Windows 10 получить и просмотреть логи службы обновления

Как в Windows 10 получить и просмотреть логи службы обновления

Тут же начнётся чтение и преобразование данных,

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

В открывшемся журнале перейдите по цепочке Журналы приложений и служб → Microsoft → Windows → WindowsUрdateClient → Operational. При этом в центральной колонке Журнала вы получите отсортированный список событий, связанных с работой функции обновления.

Ознакомиться с содержимым интересующих вас записей можно непосредственно в штатном приложении Windows, но также можно сохранить в файлы EVTX, TХT, CSV и XML для последующего их изучения или отправки по сети.

Централизованый сбор Windows event логов, без установки агента, с последующей визуазизацией средствами ELK

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

Соответственно для реализации такой системы перед администратором ставятся задачи: во-первых, каким образом эти логи собирать, во-вторых, каким образом с ними удобно и централизованно работать. Благодаря достаточно развитой связке ELK (Elasticsearch + Logstash + Kibana), уже не раз описанной на Хабре, у администратора имеются инструменты для удобного поиска и отображения всей присутствующей в логах информации. Поэтому ответ на вторую задачу имеется изначально, и остается лишь решить задачу по сбору логов.

Так как в моем случае требованием к системе было отсутствие клиента на серверах, и то, что логи требовалось вытаскивать с Windows-серверов, то в качестве инструмента сбора был выбран родной для Windows — powershell.
Исходя из этого была составлена следующая модель сбора и отображения информации из логов: логи удаленно собираются с серверов powershell-скриптом, после чего складываются в виде файлов на хранилище, далее средствами ELK (Elasticsearch + Logstash + Kibana) происходит их обработка и отображение.

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

Упреждая критику, опишу, что данная система не ставит задачи сбора логов в реалтайме, целью является лишь статистика, которая собирается за определенный промежуток времени, а затем отображается на dashboard-е. Применяется она с целью прийти с утра, посмотреть как себя вели сервера ночью, и сравнить с результатами, полученными, допустим, на прошлой неделе. В предлагаемой системе логи собираются раз в час, соответственно, отставание между текущими логами и тем, что выводятся (если быть точным, отображаются и выводятся по запросу) на dashboard-е может составлять порядка часа.

В настоящий момент в powershell имеется два способа получения логов с удаленного компьютера:

• родная команда powershell: Get-EventLog -ComputerName $computer –LogName System
• получение логов через WMI-запрос: Get-WmiObject -Class win32_NTLogEvent -filter «logfile = ‘System’» -ComputerName $computer

Но в первом случае происходит полное перекачивание файла с event-логами системы и лишь затем осуществляется их обработка на компьютере, где выполняется скрипт. Как следствие, такие запросы обрабатываются неоправданно долго. Возможность выборки логов (например, лишь за последние сутки) здесь не особо отрабатывает, так как изначально вытаскивается весь файл и лишь затем с ним ведется какая-то работа.

Во втором случае серверу отсылается WMI запрос, обработка происходит на стороне сервера и ключевой момент здесь в том, что появляется возможность ограничить промежуток интересующих нас логов уже на этапе запроса (в приведенном ниже примере промежуток выставлен в 1 час). Так как данная комманда отрабатывает намного быстрее первой, а время выполнения запроса напрямую зависит от запрашиваемого промежутка логов, то выбар пал на Get-WmiObject.

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

По завершении действия скрипта на выходе получаются файлы вида: ComputerName-JournalName.json.
Формат json несколько не соответствует стандарту (отсутствуют открывающие и закрывающие скобки), но парсер Logstash его нормально переваривает и обрабатывает. Для каждого из серверов создается по три файла: ComputerName-System.json ComputerName-Application.json ComputerName-Security.json Так как файлы имеют одинаковый формат, их обработка идеентична.

Ограничить сбор логов определенным журналом можно простым редактированием строчки: $logjournals = «System», «Application», «Security»

Далее в дело вступает Logstash со следующей конфигурацией:

Данные заносятся в Elasticsearch, откуда в дальнейшем отображаются с помощью Kibana.

В результате на экран выводится информация (в моем случае за последние 2 суток): о самых проблемных серверах, о самых проблемных сервисах; рисуется график, по которому сразу можно увидеть увеличение количества логов или ошибок в определенный момент времени. Всегда можно выполнить поиск по тексту ошибки или имени пользователя, либо произвести сортировку по уровню или id ошибки.