Windows Update Event IDs in Event Viewer: Common Error Messages and What They Mean

If you are troubleshooting Windows patching in Event Viewer, the log that matters most is Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational. That log shows the sequence Windows Update followed: it found updates, started downloading, started installing, required a restart, or failed with a specific error code.

The fastest workflow is to read the sequence, not just one event in isolation. In practice, admins usually pivot around Event ID 25 for scan failures, 31 for download failures, 20 for install failures, and 21 for restart-required states.

Official resource: Microsoft Learn: Windows Update log files

Open Event Viewer, then browse to the Windows Update client operational channel:

Applications and Services Logs
  Microsoft
    Windows
      WindowsUpdateClient
        Operational

When you are triaging one machine, sort by time and read the update session as a timeline. A normal flow often looks like 26 found updates, 44 started download, 41 download completed, 43 install started, then 19 install succeeded or 20 install failed.

PS> Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 |
>>   Select-Object TimeCreated, Id, LevelDisplayName, Message

If you need the broader log-location view, use where are Windows Update logs. That page covers Event Viewer, Get-WindowsUpdateLog, and update-related files together.

The event names above are paraphrased from the Windows provider metadata. On the local system used for authoring, the Microsoft-Windows-WindowsUpdateClient provider exposes these IDs directly through Get-WinEvent -ListProvider.

The two message patterns that matter most in practice are install failure and scan failure. Event ID 20 usually says Windows failed to install a specific update and includes an error code, while Event ID 25 usually says Windows failed to check for updates and includes a scan-layer error code.

That distinction matters operationally:

• If you see 25, solve scan, policy, or connectivity first.
• If you see 31, solve download path, proxy, BITS, or content-access issues first.
• If you see 20 after 43, solve install blockers such as pending reboot, low disk space, servicing corruption, or prerequisite issues.

PS> Get-WinEvent -FilterHashtable @{
>>   LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
>>   Id = 20, 25, 31
>> } -MaxEvents 30 |
>>   Select-Object TimeCreated, Id, Message

When Event ID 21 is part of the pattern, pivot to update requires restart. When Event ID 20 or 31 repeats, continue to Windows Update fails to install common fixes.

If you need to collect evidence quickly, filter the operational log by the high-signal IDs rather than dumping everything.

PS> Get-WinEvent -FilterHashtable @{
>>   LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
>>   StartTime = (Get-Date).AddDays(-7)
>>   Id = 19, 20, 21, 25, 31, 43, 44
>> } |
>>   Sort-Object TimeCreated |
>>   Format-Table TimeCreated, Id, LevelDisplayName, Message -Auto

Inference from Windows patch operations: this filtered view is usually enough to tell whether the machine never scanned correctly, never downloaded correctly, or reached the install phase and failed there.

Event Viewer is the fast triage surface, but it is not always the deepest source. If you need more detail for an HRESULT or servicing failure, pivot next to Get-WindowsUpdateLog, CBS logs, DISM results, and the underlying service state for wuauserv, BITS, and cryptsvc.

Microsoft's Windows Update log documentation is the right reference when you need to understand what Event Viewer can tell you quickly versus what the full log path can confirm.

PS> Get-WindowsUpdateLog
PS> Get-Service wuauserv, bits, cryptsvc, trustedinstaller | Select-Object Name, Status, StartType
PS> DISM /Online /Cleanup-Image /ScanHealth

Use this sequence when Event ID 20 or 31 tells you the phase that failed, but not enough about the root cause to remediate safely.

If the failing event references a specific update, match it with what is a KB number in Windows Update. If the real issue is that Windows will not even scan, use how to check for Windows updates for the first branch.

• Looking at one event in isolation instead of reading the update timeline around it.
• Treating Event ID 20 and Event ID 25 like the same problem branch.
• Ignoring restart-required state when Event ID 21 appears.
• Stopping at Event Viewer when you still need WindowsUpdate.log or service health checks.
• Skipping the update identity and KB context when a specific patch keeps failing.