Где посмотреть лог обновления windows 10
Обновлено: 04.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-файл публикации. В нем содержится идентификатор обновления и вся остальная информация, которая необходима для дальнейшего расследования этой ситуации.
Исторически для анализа работы агента и службы обновления Windows используется текстовый файл WindowsUpdate.log. Однако в Windows 10 (Windows Server 2016/2019) вместо привычного текстового файла логи Windows Update ведутся в формате Event Tracing for Windows (ETW). За счет этого увеличивается быстродействие подсистемы записи логов и экономится место на диске.
Таким образом, события Windows Update теперь больше не записываются в реальном времени в файл %windir%\WindowsUpdate.log. И хотя сам файл все еще присутствует в корне папки Windows, в нем лишь указано, что для сбора логов теперь применяется формат ETW.
Главное неудобство для администраторов – теперь вы не можете быстро проанализировать текстовый файл WindowsUpdate.log, найти ошибки в службе агента обновлений Windows (см. полный список ошибок Windows Update), проверить настройки WSUS и проанализировать историю установки обновлений.
Вы можете сконвертировать события ETW в привычный текстовый формат WindowsUpdate.log для более удобного анализа событий службы обновлений. Для этого используется командлет PowerShell — Get-WindowsUpdateLog. Данный командлет позволяет собрать информацию со всех .etl файлов (хранятся в каталоге C:\WINDOWS\Logs\WindowsUpdate) и сформировать один файл WindowsUpdate.log.
Чтобы сформировать файл WindowsUpdate.log и поместить его в каталог C:\PS\Logs, выполните следующую команду в консоли PowerShell:
Get-WindowsUpdateLog -logpath C:\PS\Logs\WindowsUpdate.log
Файл “C:\Program Files\Windows Defender\SymSrv.dll” обычно отсутствует, если на сервере не установлен антивирус Windows Defender.
В старых версиях Windows 10 при первом запуске командлет Get-WindowsUpdateLog скачает и установит сервер символов Microsoft (Microsoft Internet Symbol Store). В последних версиях Windows 10 выполняется онлайн доступ к серверу символов Microsoft в Azure. Затем командлет:
- Собирает данные из всех .etl файлов;
- Преобразует данные в CSV (по-умолчанию) или XML формат;
- Переконвертирует данные из промежуточных файлов и добавляет их в текстовый файл журнала, указанного в параметре LogPath (если параметр LogPath не задан, файл WindowsUpdate.log создается на рабочем столе пользователя, запустившего команду).
Это значит, что у вас не установлен сервер символов Windows Symbol (сейчас нельзя скачать отдельную программу установки Windows symbols, т.к. они автоматически загружаются из хранилища символов в Azure). Для изолированных сред вы можете использовать офлайн версию сервера символов согласно статье Offline Symbols for Windows Update.
Откройте файл журнала с помощью такой команды PowerShell:
Invoke-Item -Path C:\PS\Logs\WindowsUpdate.log
Анализировать получившийся файл WindowsUpdate.log довольно сложно, т.к. в нем собираются данные из множества источников:
- AGENT- события агента Windows Update;
- AU – автоматическое обновление;
- AUCLNT- взаимодействие с пользователем;
- HANDLER- управление установщиком обновлений;
- MISC- общая информация;
- PT- синхронизация обновлений с локальным хранилищем;
- REPORT- сбор отчетов;
- SERVICE- запуск/выключение службы wuauserv;
- SETUP- установка новых версий клиента Windows Update;
- DownloadManager – загрузка обновлений в локальных кэш;
- Handler, Setup – заголовки установщиков (CBS и т.п.);
- И т.д.
Вы можете выбрать последние 30 событий от агента обновления Windows (agent) с помощью простого регулярного выражения:
Select-String -Pattern '\sagent\s' -Path C:\PS\Logs\WindowsUpdate.log | Select-Object -Last 30
Можно отфильтровать события в логе по нескольким источникам:
Select-String -Pattern '\sagent\s|\smisc\s' -Path c:\PS\Logs\WindowsUpdate.log | Select-Object -Last 50
Аналогично вы можете искать события по номеру KB, ошибка (строки FAILED, Exit Code, FATAL).
Также вы можете сформировать файл WindowsUpdate.log для удаленного компьютера/сервера:
Get-WindowsUpdateLog -ETLPath \\PC221\C$\windows\Logs\WindowsUpdate -LogPath C:\PS\Logs\windowsupdatePC221.log
Также для анализа работы службы обновлений Windows может быть полезны журналы Event Viewer в разделе Applications and Services Logs -> Microsoft -> Windows –> WindowsUpdateClient -> Operational.
Точно неизвестно, какое количество пользователей и системных администраторов сталкиваются с проблемами обновления на компьютерах Windows постоянно или периодически.
Проблемы обновления могут быть крайне раздражительными, особенно если система переходит в циклические состояния постоянной загрузки, установки, перезагрузки и отката изменений.
Ранее Microsoft выпустила несколько некорректных обновлений, которые вызвали проблемы на машинах Windows 10. Самыми известными, пожалуй, являются KB3081424 и KB3194496, который вызвали ошибки на компьютерах по всему миру.
На сайте Microsoft Technet доступна утилита Reset Windows Update Agent, разработанная специально для исправления распространенных проблем обновления. Инструмент успешно справляется с проблемами работы центра обновления Windows, но не сможет помочь, если проблема вызвана на стороне Microsoft.
Быстрая проверка ошибок обновления Windows
Windows сохраняет журнал обновлений, который содержит все события, связанные с обновлением. Эти журналы можно найти по пути C:\Windows\Logs\WindowsUpdate. Логи имеют формат ETW (Event Trace for Windows) и могут быть проанализированы с помощью специализированных инструментов.
Пользователь может также использовать простую команду PowerShell, чтобы преобразовать файлы Event Trace в простой текст, который можно исследовать на предмет ошибок и проблем, связанных с обновлением Windows.
Преобразование журнала обновления:
- Нажмите клавишу Windows, введите cmd.exe, зажмите Shift и Ctrl и нажмите Enter. Можно также щелкнуть правой кнопкой мыши по значку меню Пуск и выбрать опцию “Командная строка (администратор)”.
- Введите powershell
- Запустите команду get-WindowsUpdateLog -verbose
Затем начнется парсинг файлов Event Trace, который может занять некоторое время, зависящее от количества и размеров файлов журналов.
После этого на рабочем столе появится файл WindowsUpdate.log. Размер файла может достигать нескольких мегабайт. Файл можно открыть в любом текстовом редакторе, например, в Notepad++.
Можно исследовать файл по строкам, а можно немного ускорить процесс:
Несмотря на то, что анализ журнала обновления Windows может занять приличное время, то может быть один из самых лучших способов определить причину сбоя обновления. К тому же, компания Microsoft представила руководство по исправлению ошибок обновления Windows 10, которое также может помочь в решении найденных проблем.
Вариант 1: Списки обновлений
Существует несколько способов получить перечень установленных на ПК обновлений. Самым простым из них является классическая «Панель управления».
-
Открываем системный поиск, нажав на значок с изображением лупы на «Панели задач». В поле начинаем вводить «Панель управления» и кликаем по появившемуся пункту в выдаче.
Следующим инструментом является «Командная строка», запущенная от имени администратора.
Первая команда выводит список обновлений с указанием их назначения (обычное или для обеспечения безопасности), идентификатора (KBXXXXXXX), пользователя, от чьего имени производилась установка, а также даты.
wmic qfe list brief /format:table
Если не использовать параметры «brief» и «/format:table», то кроме прочего, можно увидеть адрес страницы с описанием пакета на сайте Майкрософт.
Еще одна команда, позволяющая получить некоторую информацию об апдейтах
Искомое находится в разделе «Исправления».
Вариант 2: Логи обновлений
Логи отличаются от списков тем, что в них также содержатся данные обо всех попытках выполнить апдейт и их успешности. В сжатом виде такая информация хранится непосредственно в журнале обновлений Windows 10.
-
Жмем сочетание клавиш Windows+I, открыв «Параметры», а затем переходим в раздел обновления и безопасности.
Более подробную информацию можно получить с помощью «PowerShell». Данный прием в основном используется для «отлова» ошибок при обновлении.
-
Запускаем «PowerShell» от имени администратора. Для этого жмем ПКМ по кнопке «Пуск» и выбираем нужный пункт в контекстном меню или, при условии отсутствия такового, пользуемся поиском.
Она конвертирует файлы журнала в удобочитаемый текстовый формат, создав на рабочем столе файл с названием «WindowsUpdate.log», который можно открыть в обычном блокноте.
«Простому смертному» прочитать данный файл будет весьма тяжело, но сайте Майкрософт есть статья, дающая некоторое представление о том, что содержат строки документа.
Применительно к домашнему ПК эту информацию можно использовать для выявления ошибок на всех стадиях операции.
Заключение
Как видите, просмотреть журнал обновлений Windows 10 можно несколькими способами. Система дает нам достаточно инструментов для получения сведений. Классическую «Панель управления» и раздел в «Параметрах» удобно использовать на домашнем компьютере, а «Командную строку» и «PowerShell» можно применять для администрирования машин в локальной сети.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Читайте также: