Как создать log файл в windows 10
Обновлено: 03.07.2024
Эта статья предназначена для ИТ-специалистов. В ней описывается изучение файла Windowsupdate.log для устранения неполадок Центра обновления Windows. Пользователям домашних компьютеров рекомендуется статья Средство устранения неполадок Центра обновления Windows.
Аннотация
Начиная с Windows 8.1 (в том числе и в Windows 10), клиент Центра обновления Windows создает журналы диагностики с помощью трассировки событий для Windows (ETW). Данный способ повышает эффективность и сокращает использование дискового пространства. Однако журналы доступны для чтения не сразу после записи. Чтобы читать журналы как текстовые файлы, их нужно сначала расшифровать.
Темы, рассматриваемые в этой статье
Создание файла WindowsUpdate.log
Чтобы объединить и преобразовать файлы трассировки WU (ETL-файлы) в единый читаемый файл WindowsUpdate.log, см. командлет Get-WindowsUpdateLog.
Примечание. При запуске командлета Get-WindowsUpdateLog создается копияфайла WindowsUpdate.log в виде статического файла журнала. В отличие от прежнего файла WindowsUpdate.log, такой файл не обновляется автоматически: чтобы получить актуальные данные, нужно запустить командлет Get-WindowsUpdateLog еще раз.
Компоненты журнала Центра обновления Windows
У модуля WU есть различные имена компонентов. Ниже описаны самые популярные компоненты, отображаемые в файле WindowsUpdate.log:
AGENT — агент Центра обновления Windows
AU — эту задачу выполняет служба автоматических обновлений
AUCLNT — взаимодействие между AU и вошедшим в систему пользователем
CDM — диспетчер устройств
CMPRESS — агент сжатия
COMAPI — API Центра обновления Windows
DRIVER — сведения о драйвере устройства
DTASTOR — обработка транзакций базы данных
EEHNDLER — обработчик выражений, используемый для оценки пригодности обновлений
HANDLER — управляет установщиками обновлений
MISC — общая служебная информация
OFFLSNC — обнаружение доступных обновлений без подключения к сети
PARSER — анализирует сведения выражений
PT — синхронизирует сведения об обновлениях с локальным хранилищем данных
REPORT — сбор сведений отчетов
SERVICE — запуск/выключение службы автоматических обновлений
SETUP — устанавливает новые версии клиента Центра обновления Windows по мере их выхода
SHUTDWN — функция установки при выключении
WUREDIR — файлы перенаправителя Центра обновления Windows
WUWEB — элемент управления ActiveX Центра обновления Windows
ProtocolTalker — синхронизация клиент/сервер
DownloadManager — создает и отслеживает скачивание полезной нагрузки
Handler, Setup — установка обработчиков (CBS и др.)
EEHandler — оценка правил применимости обновлений
DataStore — локальное кэширование данных обновлений
IdleTimer — отслеживание активных вызовов,остановка службы
Структура журнала Центра обновления Windows
В структуре журнала Центра обновления Windows выделяется четыре основных обозначения:
Идентификаторы процесса и потока
Идентификатор обновления и номер редакции
Структура файла WindowsUpdate.log обсуждается в следующих разделах.
Метка времени указывает время записи в журнал.
Пауза в ходе синхронизации может свидетельствовать о проблеме с сетью, даже если проверка успешно завершилась.
Длинная пауза перед окончанием проверки может указывать на проблему в цепочке замены.
Идентификаторы процесса и потока — произвольные величины, которые могут отличаться в разных журналах и даже сеансах обслуживания в рамках одного журнала.
Первые четыре шестнадцатеричных цифры — идентификатор процесса.
Следующие четыре шестнадцатеричных цифры — идентификатор потока.
У каждого из компонентов, включая USO, модули WU, вызывающие API COM, и обработчики установщиков WU, есть свои идентификаторы процессов.
Поиск и определение компонентов, связанных с идентификаторами. Различным частям модуля WU соответствуют различные имена компонентов. Некоторые из них приводятся ниже.
ProtocolTalker — синхронизация клиент/сервер
DownloadManager — создает и отслеживает скачивание полезной нагрузки
Handler, Setup — установка обработчиков (CBS и др.)
EEHandler — оценка правил применимости обновлений
DataStore — локальное кэширование данных обновлений
IdleTimer — отслеживание активных вызовов,остановка службы
Идентификатор обновления и номер редакции
У одного обновления в разных контекстах существуют различные идентификаторы. Важно знать схемы назначения идентификаторов.
«Идентификатор обновления»: GUID (указанный на предыдущем снимке экрана), который назначается тому или иному обновлению в момент публикации
«Номер редакции»: номер увеличивается каждый раз, когда то или иное обновление (с заданным идентификатором обновления) изменяется или повторно публикуется в службе
Номера редакций повторно используются для различных обновлений (не считаются уникальными идентификаторами).
Идентификатор обновления и номер редакции обычно отображаются вместе как «.редакция».
Идентификатор редакции (не путать с «номером редакции») — серийный номер, присваиваемый обновлению при первоначальной публикации или изменении в той или иной службе.
После изменения существующее обновление сохраняет свой идентификатор обновления (GUID), при этом его номер редакции увеличивается на единицу (например, со 100 до 101), а идентификатор редакции изменяется полностью и никак не соотносится с предыдущим идентификатором.
Идентификаторы редакций уникальны только в рамках одного источника обновления.
У одной и той же редакции обновления могут быть совершенно разные идентификаторы редакций в службах WU и WSUS.
При этом одинаковые идентификаторы редакций могут соответствовать разным обновлениям в службах WU и WSUS.
«Локальный идентификатор» — серийный номер, присваиваемый обновлению при получении от службы тем или иным клиентом WU.
Обычно отображается в журналах отладки, особенно с участием локального кэша для сведений об обновлениях (хранилище данных).
Различные клиентские компьютеры могут назначать одному и тому же обновлению различные локальные идентификаторы.
Чтобы узнать локальные идентификаторы, используемые клиентом, обратитесь к файлу %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb.
Иногда в журналах термины используются непоследовательно. К примеру, список «InstalledNonLeafUpdateIDs» на самом деле содержит идентификаторы редакций, а не обновлений.
Идентификаторы можно распознать по форме и контексту:
GUID — идентификаторы обновлений
Небольшие целые числа рядом с идентификаторами обновлений — номера редакций
Большие числа — это обычно идентификаторы редакций
Небольшие целые числа (особенно в хранилище данных) могут быть локальными идентификаторами
Как работает проверка Центра обновления Windows
В процессе проверки Центр обновления Windows выполняет следующий набор действий.
Когда пользователи начинают проверку в Центре обновления Windows через панель настроек, наблюдается следующее поведение:
Обновления определяются различными идентификаторами («Id = 10», «Id = 11») и различными номерами идентификаторов потока.
Чтобы сосредоточиться на конкретной задаче, WU фильтрует эти идентификаторы потока.
После начала проверки агент Центра обновления Windows создает идентификаторы службы:
они указывают, какой источник обновления проверяется.
Примечание. На следующем снимке экрана показан Центр обновления Microsoft и службы фокус-тестирования.
Модуль WU рассматривает каждую службу как отдельный объект, несмотря на то что несколько служб могут содержать одинаковые обновления.
Типовые идентификаторы служб
: файлы, устанавливаемые пользователем в беспроводном режиме
: служба по умолчанию. Обычно это службы WSUS или SCCM (если они настроены) либо Центр обновления Microsoft, если выбран параметр Центр обновления Microsoft, в противном случае — Центр обновления Windows.
Часто сбой обновления происходит из-за проблем с сетью. Чтобы найти причину проблемы:
На сайтах, где используются только службы WSUS/SCCM, служба SLS может блокироваться на брандмауэре. В этом случае произойдет сбой запроса SLS и проверка не будет выполнена для WU/MU и др., зато будет поддерживаться для служб WSUS/SCCM благодаря локальной настройке.
Вопрос. Почему не предлагается «обновление X»?
Запишите идентификатор отсутствующего обновления (GUID).
Найдите нужное обновление с помощью поиска.
Щелкните по его названию, чтобы открыть окно информации об обновлении.
Запишите идентификатор updateid, отображаемый в строке адреса.
Откройте файл журнала и поищите нужный идентификатор. Если этот номер найден, перейдите к «идентификаторам дочернего обновления». Если идентификатор не найден, возможны два варианта:
Обновление не одобрено (даже для проверки) на сервере Windows Server Update Service (WSUS).
Предварительное требование не выполнено.
Примечание. Эти условия могут возникать в WU или MU только в том случае, если обновление выдается с учетом географического положения. Для WSUS и System Center Configuration Manager данное условие требует расследования на стороне сервера.
О предварительных требованиях
У большинства обновлений бывает одно или несколько предварительных требований. Если они не выполнены, обычно служба не сообщает клиенту об обновлении. Поэтому обновление не будет указано в журнале. Узнав идентификатор обновления для предварительных требований, поищите эти идентификаторы в журнале, чтобы установить, почему они определены как «неприменимые».
Если идентификатор предварительного требования не указан в журнале, значит у него есть свой набор требований, которые не были выполнены. В этой ситуации двигайтесь вверх по цепочке, пока не найдете предварительные требования, оцениваемые клиентом.
Также изучите XML-файл публикации. В нем содержится идентификатор обновления и вся остальная информация, которая необходима для дальнейшего расследования этой ситуации.
Компания Microsoft в ходе обновления своих операционных систем часто меняет способы активации функций, к которым все пользователи привыкли. Зачастую даже опытным пользователям Windows сложно разобраться, где в Windows 10 включить лог загрузки операционной системы, чтобы после его можно было посмотреть и проанализировать. В рамках данной статьи рассмотрим, как в Windows 10 включить лог загрузки.
Зачем нужен лог загрузки
Многие пользователи вовсе не знают, что такое лог (или журнал) загрузки, и зачем он нужен. Если не вдаваться в детали, то лог загрузки — это простой текстовый файл, который содержит в себе информацию для анализа процесса старта компьютера и операционной системы.
Чаще всего лог загрузки необходим системным администраторам, чтобы понять, какие проблемы препятствуют загрузке операционной системы, вызывают те или иные ошибки при запуске программ или в процессе работы Windows. В логе загрузки отображается полный список загружаемых при старте компьютера драйверов и библиотек.
Где находится лог загрузки в Windows 10
В операционной системе Windows 10 лог загрузки располагается на системном диске в папке Windows. Файл называется ntbtlog.txt.
Обратите внимание: Как можно видеть, это обычный текстовый файл. Его можно открыть при помощи стандартного приложения “Блокнот” или других сторонних программ, которые позволяют работать с txt файлами.
Как включить лог загрузки в Windows 10
Чтобы текстовый файл ntbtlog.txt появился в папке Windows, нужно его сгенерировать. По умолчанию в Windows 10 отключен процесс создания данного файла при загрузке компьютера.
Включить создание файла журнала загрузки можно двумя способами:
-
Через настройки конфигурации системы. Чтобы это сделать, необходимо запустить утилиту “Конфигурация системы”. Для запуска этой утилиты нажмите на клавиатуре сочетание Win+R, чтобы открылось окошко “Выполнить”. В нем пропишите команду для запуска утилиты — msconfig.
Если на компьютере установлена одна операционная система Windows 10 (как на примере на скриншоте), тогда будет отображаться два списка элементов — диспетчер загрузки и загрузка Windows. Необходимо обратиться к загрузке Windows, у которой имеется идентификатор current. Пропишите в командной строке следующее:
Важно: Если у вас идентификатор отличный от , необходимо заменить на него часть команды, используемой выше.
После выполнения этой команды необходимо перезагрузить компьютер, чтобы лог загрузки был создан в папке Windows.
Как читать лог загрузки Windows 10
Несмотря на то что лог загрузки — это текстовый документ исключительно для системных администраторов, что-то полезное из него может вынести и обычный пользователь.
В журнале загрузки указывается перед каждым из компонентов — был он исполнен или нет:
- BOOTLOG_LOADED — означает, что драйвер был загружен без ошибок.
- BOOTLOG_NOT_LOADED — указывает, что во время загрузки операционной системы старт данного драйвера был пропущен.
На основании этой информации можно сделать выводы о том, с какими драйверами на компьютере могут быть проблемы.
В десятой версии Виндоуз предусмотрен журнал событий. Этот компонент присутствует в системе уже очень давно, но очень немногие о нем знают. Хотя нужен он каждому для того, чтобы понимать, что происходит с системой вашего компьютера, найти причину сбоев, определив некорректно работающие софт или устройства.
Не один, а много разных журналов
Выглядит он как небольшая подборка логов, которые система записывает в ходе работы компьютера. Эти журналы являются обычными текстовыми файлами, записанными в формате XML.
Неправильно считать, что речь только об одном файле. Их несколько - администрирования, операционный, аналитический и отладки, не говоря уже о лог-файлах отдельных приложений. Их также называют еще и файлами регистрации.
Какие события записываются в системном журнале?
Каждый осуществляемый доступ, изменения конфигурации безопасности, сбой операционной системы, аппаратных компонентов или драйверов оставляет след в том или ином логе событий.
Интерфейс
Таким образом, окно журнала событий является просто предназначенным для вас интерфейсом, в котором собраны данные из различных текстовых файлов регистрации. Правильнее всего рассматривать Журнал событий в качестве программы управления базами данных, в удобной форме показывающей вам информацию, накапливаемую в файлах, просматривать которые при помощи текстового редактора или просмотрщика текстов вам было бы некомфортно.
Как в него войти?
Щелкните правой кнопкой мыши по значку главного системного меню. Второй вариант, предназначенный преимущественно для сенсорных экранов, тапните по нему и некоторое время удерживайте до появления на дисплее контекстного меню. Отсюда предстоит перейти к просмотру событий.
Когда журнал откроется, вы увидите в левой верхней части окна строку меню и панель. Слева располагается вложенное окошко, в котором вы сможете выбирать, какие именно события хотите просмотреть. В их числе - относящиеся к определенными приложениям, системе в целом и ее безопасности.
Что означают записи лога различных типов?
На большинство событий не надо обращать внимания
В событиях приложений софт отмечает возникшие в его работе проблемы. События безопасности рассматривают определенные действия, произведенные на компьютере, результат которых был или не был успешен. В качестве примера можно привести попытку входа пользователя. На события установки пользователю в большинстве случаев не следует никак реагировать. Ведь касаются они преимущественно управления контроллерами.
В системных событиях собраны поступившие от файлов Виндовз уведомления и касаются они тех сбоев, которые возникли в ходе функционирования системы. Почти все они исправляются усилиями самой системы и в вашем вмешательстве не нуждаются.
Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.
В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.
До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:
Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.
Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:
Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:
Смотрим за ходом обновления Windows.
Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:
Смотрим, кто пытается пролезть на наш дедик.
При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:
Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:
Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.
Для получения списка доступных системных журналов можно выполнить следующую команду:
Вывод доступных журналов и информации о них.
Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:
Последние записи в журнале System.
Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.
Для примера получим все события из журнала System с кодом события 1 и 6013.
В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:
- 0 ― всегда записывать;
- 1 ― критический;
- 2 ― ошибка;
- 3 ― предупреждение;
- 4 ― информация;
- 5 ― подробный (Verbose).
Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:
Ошибки и предупреждения журнала System.
Аналогичным образом можно собирать таблицу, фильтруя непосредственно по тексту события и по времени.
Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:
PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.
О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.
Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:
Посмотрим на результат:
Смотрим журнал Windows Firewall.
Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.
Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.
Работать будем с журналом TerminalServices-LocalSessionManager\Operational.
Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.
Данные будем получать таким запросом:
Смотрим, кто и когда подключался к нашему серверу терминалов.
Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.
В качестве примера посмотрим статистику количества писем по дням таким запросом:
Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.
Выполняем запрос и открываем получившуюся картинку…
Любуемся результатом.
Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.
Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.
Интерфейс Log Parser Studio.
Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.
Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.
В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:
Выборка наиболее активных ящиков.
При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.
Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.
Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.
Читайте также: