Быстрый анализ ошибок обновления Windows

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

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

Ранее Microsoft выпустила несколько некорректных обновлений, которые вызвали проблемы на машинах Windows 10. Самыми известными, пожалуй, являются KB3081424 и KB3194496, который вызвали ошибки на компьютерах по всему миру.

На сайте Microsoft Technet доступна утилита Reset Windows Update Agent, разработанная специально для исправления распространенных проблем обновления. Инструмент успешно справляется с проблемами работы центра обновления Windows, но не сможет помочь, если проблема вызвана на стороне Microsoft.

Быстрая проверка ошибок обновления Windows

Быстрая проверка ошибок обновления Windows»/>

Windows сохраняет журнал обновлений, который содержит все события, связанные с обновлением. Эти журналы можно найти по пути C:\Windows\Logs\WindowsUpdate. Логи имеют формат ETW (Event Trace for Windows) и могут быть проанализированы с помощью специализированных инструментов.

Пользователь может также использовать простую команду PowerShell, чтобы преобразовать файлы Event Trace в простой текст, который можно исследовать на предмет ошибок и проблем, связанных с обновлением Windows.

Преобразование журнала обновления:

1. Нажмите клавишу Windows, введите cmd.exe, зажмите Shift и Ctrl и нажмите Enter. Можно также щелкнуть правой кнопкой мыши по значку меню Пуск и выбрать опцию “Командная строка (администратор)”.
2. Введите powershell
3. Запустите команду get-WindowsUpdateLog -verbose

Затем начнется парсинг файлов Event Trace, который может занять некоторое время, зависящее от количества и размеров файлов журналов.

После этого на рабочем столе появится файл WindowsUpdate.log. Размер файла может достигать нескольких мегабайт. Файл можно открыть в любом текстовом редакторе, например, в Notepad++.

Быстрая проверка ошибок обновления Windows»/>

Можно исследовать файл по строкам, а можно немного ускорить процесс:

1. События в журнале отсортированы в хронологическом порядке, потому можно перейти к дате и времени, когда была обнаружена проблема.
2. Также можно нажать F3 для открытия окна поиска и ввести «error». Будут найдены строки, содержащие сообщения об ошибке. Эта информация позволит прояснить, почему обновление не смогло установиться на устройстве.

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

А что вы предпринимаете в случае сбоя обновления Windows?

Windows Update log files

The following table describes the log files created by Windows Update.

Log file	Location	Description	When to use
windowsupdate.log	C:\Windows\Logs\WindowsUpdate	Starting in Windows 8.1 and continuing in Windows 10, Windows Update client uses Event Tracing for Windows (ETW) to generate diagnostic logs.	If you receive an error message when you run Windows Update, you can use the information that is included in the Windowsupdate.log log file to troubleshoot the issue.
UpdateSessionOrchestration.etl	C:\ProgramData\USOShared\Logs	Starting Windows 10, the Update Orchestrator is responsible for sequence of downloading and installing various update types from Windows Update. And the events are logged to these .etl files.	When you see that the updates are available but download is not getting triggered. When Updates are downloaded but installation is not triggered. When Updates are installed but reboot is not triggered.
NotificationUxBroker.etl	C:\ProgramData\USOShared\Logs	Starting Windows 10, the notification toast or the banner is triggered by NotificationUxBroker.exe.	When you want to check whether the notification was triggered or not.
CBS.log	%systemroot%\Logs\CBS	This log provides insight on the update installation part in the servicing stack.	To troubleshoot the issues related to Windows Update installation.

Generating WindowsUpdate.log

To merge and convert Windows Update trace files (.etl files) into a single readable WindowsUpdate.log file, see Get-WindowsUpdateLog.

When you run the Get-WindowsUpdateLog cmdlet, an copy of WindowsUpdate.log file is created as a static log file. It does not update as the old WindowsUpdate.log unless you run Get-WindowsUpdateLog again.

Windows Update log components

The Windows Update engine has different component names. The following are some of the most common components that appear in the WindowsUpdate.log file:

• AGENT- Windows Update agent
• AU — Automatic Updates is performing this task
• AUCLNT- Interaction between AU and the logged-on user
• CDM- Device Manager
• CMPRESS- Compression agent
• COMAPI- Windows Update API
• DRIVER- Device driver information
• DTASTOR- Handles database transactions
• EEHNDLER- Expression handler that’s used to evaluate update applicability
• HANDLER- Manages the update installers
• MISC- General service information
• OFFLSNC- Detects available updates without network connection
• PARSER- Parses expression information
• PT- Synchronizes updates information to the local datastore
• REPORT- Collects reporting information
• SERVICE- Startup/shutdown of the Automatic Updates service
• SETUP- Installs new versions of the Windows Update client when it is available
• SHUTDWN- Install at shutdown feature
• WUREDIR- The Windows Update redirector files
• WUWEB- The Windows Update ActiveX control
• ProtocolTalker — Client-server sync
• DownloadManager — Creates and monitors payload downloads
• Handler, Setup — Installer handlers (CBS, and so on)
• EEHandler — Evaluating update applicability rules
• DataStore — Caching update data locally
• IdleTimer — Tracking active calls, stopping a service

Many component log messages are invaluable if you are looking for problems in that specific area. However, they can be useless if you don’t filter to exclude irrelevant components so that you can focus on what’s important.

Windows Update log structure

The Windows update log structure is separated into four main identities:

• Time Stamps
• Process ID and Thread ID
• Component Name
• Update Identifiers
  • Update ID and Revision Number
  • Revision ID
  • Local ID
  • Inconsistent terminology

The WindowsUpdate.log structure is discussed in the following sections.

Time stamps

The time stamp indicates the time at which the logging occurs.

• Messages are usually in chronological order, but there may be exceptions.
• A pause during a sync can indicate a network problem, even if the scan succeeds.
• A long pause near the end of a scan can indicate a supersedence chain issue.
  

Process ID and thread ID

The Process IDs and Thread IDs are random, and they can vary from log to log and even from service session to service session within the same log.

• The first four hex digits are the process ID.
• The next four hex digits are the thread ID.
• Each component, such as the USO, Windows Update engine, COM API callers, and Windows Update installer handlers, has its own process ID.
  

Component name

Search for and identify the components that are associated with the IDs. Different parts of the Windows Update engine have different component names. Some of them are as follows:

• ProtocolTalker — Client-server sync
• DownloadManager — Creates and monitors payload downloads
• Handler, Setup — Installer handlers (CBS, etc.)
• EEHandler — Evaluating update applicability rules
• DataStore — Caching update data locally
• IdleTimer — Tracking active calls, stopping service

Update identifiers

Update ID and revision number

There are different identifiers for the same update in different contexts. It’s important to know the identifier schemes.

• Update ID: A GUID (indicated in the previous screenshot) that’s assigned to a given update at publication time
• Revision number: A number incremented every time that a given update (that has a given update ID) is modified and republished on a service
• Revision numbers are reused from one update to another (not a unique identifier).
• The update ID and revision number are often shown together as «.revision.»

Revision ID

• A Revision ID (don’t confuse this value with «revision number») is a serial number that’s issued when an update is initially published or revised on a given service.
• An existing update that’s revised keeps the same update ID (GUID), has its revision number incremented (for example, from 100 to 101), but gets a new revision ID that is not related to the previous ID.
• Revision IDs are unique on a given update source, but not across multiple sources.
• The same update revision might have different revision IDs on Windows Update and WSUS.
• The same revision ID might represent different updates on Windows Update and WSUS.

Local ID

• Local ID is a serial number issued when an update is received from a service by a given Windows Update client
• Typically seen in debug logs, especially involving the local cache for update info (Datastore)
• Different client PCs will assign different Local IDs to the same update
• You can find the local IDs that a client is using by getting the client’s %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb file

Inconsistent terminology

Sometimes the logs use terms inconsistently. For example, the InstalledNonLeafUpdateIDs list actually contains revision IDs, not update IDs.

Recognize IDs by form and context:

• GUIDs are update IDs
• Small integers that appear alongside an update ID are revision numbers
• Large integers are typically revision IDs
• Small integers (especially in Datastore) can be local IDs

Windows Setup log files analysis using SetupDiag tool

SetupDiag is a diagnostic tool that can be used for analysis of logs related to installation of Windows Updates. For detailed information, see SetupDiag.

Просмотр журнала обновлений WindowsUpdate.log в Windows 10 / Windows Server 2016

Исторически для анализа работы агента и службы обновления 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.

Чтобы исправить ошибку, вы можете установить Defender, скопировать файл SymSrv.dll с другого Windows Server 2016/ Windows 10 или поиском найти его в каталоге “C:\Windows\WinSxS\” (у меня каталог назывался C:\Windows\WinSxS\amd64_windows-defender-service-cloudclean_…) и скопировать его в папку C:\Program Files\Windows Defender.

В старых версиях Windows 10 при первом запуске командлет Get-WindowsUpdateLog скачает и установит сервер символов Microsoft (Microsoft Internet Symbol Store). В последних версиях Windows 10 выполняется онлайн доступ к серверу символов Microsoft в Azure. Затем командлет:

1. Собирает данные из всех .etl файлов;
2. Преобразует данные в CSV (по-умолчанию) или XML формат;
3. Переконвертирует данные из промежуточных файлов и добавляет их в текстовый файл журнала, указанного в параметре 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.