How to Collect Windows Update Failure Logs with PowerShell

When Windows Update fails, the first instinct is often to run every repair command found online. That can make the situation worse because the original error evidence gets buried under later changes. A better first step is to collect a clean log packet: Windows Update activity, CBS servicing logs, DISM logs, event logs, update history, and a short system summary. Once the evidence is saved, troubleshooting becomes less guesswork and more pattern matching.

This guide gives you a PowerShell collector you can run before deeper repair work. It does not fix Windows Update by itself. It creates a timestamped folder on the desktop, gathers the most useful local evidence, and compresses it into a zip file that can be reviewed later. Use it before resetting update components, uninstalling packages, deleting caches, or reinstalling Windows.

What the collector gathers

Modern Windows Update logging is spread across more than one location. Microsoft documents `Get-WindowsUpdateLog` as a way to merge Windows Update trace logs into a readable `WindowsUpdate.log`. That file helps with detection, download, and scan behavior. The CBS log under `C:\Windows\Logs\CBS` helps with servicing stack and component store activity. The DISM log under `C:\Windows\Logs\DISM` matters when repair commands or image servicing operations are involved.

Event logs fill in the timeline. The WindowsUpdateClient operational log can show update detection, download, and installation events. The System and Setup logs can show restarts, service failures, driver issues, and installer events around the same time. None of these files tells the whole story alone, but together they usually give a support technician a much better starting point.

Logs can contain device names, usernames, domain names, tenant hints, file paths, update IDs, and software names. Treat the zip as sensitive. If you need to share it, review it first and remove anything that should not leave your machine or organization.

Copy the PowerShell collector

Save the following script as `Collect-WindowsUpdateEvidence.ps1`. Run it in Windows PowerShell or PowerShell as an administrator when possible. Administrator rights help with event log export and protected log paths, but the script still attempts to collect what it can if a command fails.

# Collect-WindowsUpdateEvidence.ps1
$stamp = Get-Date -Format "yyyyMMdd-HHmmss"
$outRoot = Join-Path $env:USERPROFILE "Desktop\WU-Evidence-$stamp"
New-Item -ItemType Directory -Path $outRoot -Force | Out-Null

function Write-Section {
    param([string]$Name, [scriptblock]$Script)
    $path = Join-Path $outRoot $Name
    try {
        & $Script | Out-File -FilePath $path -Encoding UTF8 -Width 240
    } catch {
        "FAILED: $($_.Exception.Message)" | Out-File -FilePath $path -Encoding UTF8
    }
}

function Copy-IfExists {
    param([string]$Path, [string]$Name)
    if (Test-Path -LiteralPath $Path) {
        Copy-Item -LiteralPath $Path -Destination (Join-Path $outRoot $Name) -Force -ErrorAction SilentlyContinue
    }
}

Write-Section "system-summary.txt" {
    Get-ComputerInfo |
        Select-Object OsName, OsVersion, WindowsVersion, OsBuildNumber, CsManufacturer, CsModel, CsSystemType
}

Write-Section "recent-hotfixes.txt" {
    Get-HotFix |
        Sort-Object InstalledOn -Descending |
        Select-Object -First 80 HotFixID, Description, InstalledBy, InstalledOn
}

Write-Section "pending-reboot.txt" {
    [pscustomobject]@{
        ComponentBasedServicing = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
        WindowsUpdateAutoUpdate = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
        PendingFileRename       = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -ErrorAction SilentlyContinue).PendingFileRenameOperations -ne $null
    }
}

try {
    Get-WindowsUpdateLog -LogPath (Join-Path $outRoot "WindowsUpdate.log") -ErrorAction Stop
} catch {
    "Get-WindowsUpdateLog failed: $($_.Exception.Message)" |
        Out-File (Join-Path $outRoot "WindowsUpdateLog-error.txt") -Encoding UTF8
}

Copy-IfExists "$env:windir\Logs\CBS\CBS.log" "CBS.log"
Copy-IfExists "$env:windir\Logs\DISM\dism.log" "DISM.log"
Copy-IfExists "$env:windir\SoftwareDistribution\ReportingEvents.log" "ReportingEvents.log"

$eventLogs = @(
    @{ Name = "Microsoft-Windows-WindowsUpdateClient/Operational"; File = "WindowsUpdateClient-Operational.evtx" },
    @{ Name = "System"; File = "System.evtx" },
    @{ Name = "Setup"; File = "Setup.evtx" }
)

foreach ($log in $eventLogs) {
    $target = Join-Path $outRoot $log.File
    try {
        wevtutil epl $log.Name $target /ow:true
    } catch {
        "FAILED exporting $($log.Name): $($_.Exception.Message)" |
            Out-File (Join-Path $outRoot "$($log.File).txt") -Encoding UTF8
    }
}

$zipPath = "$outRoot.zip"
Compress-Archive -Path (Join-Path $outRoot "*") -DestinationPath $zipPath -Force
"Created evidence folder: $outRoot"
"Created zip package: $zipPath"

Run it before changing the system

The best time to run the collector is immediately after the update failure, before applying broad fixes. If Windows shows an error code, copy it into a note in the evidence folder. If the failure happened during reboot, sign in, run the collector, and record the approximate time of the failure. Timelines matter because event logs can contain many unrelated warnings.

Open PowerShell as administrator.
Temporarily allow the local script only if your execution policy blocks it: `Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass`.
Run `.\Collect-WindowsUpdateEvidence.ps1` from the folder where you saved it.
Wait for the desktop folder and zip file to be created.
Review the zip before sharing it outside your device or organization.

If `Get-WindowsUpdateLog` fails, keep the error file. That failure is still useful evidence. On some systems, symbols or trace conversion may behave differently, and a support person may ask for the original event logs or additional traces later.

How to read the first clues

Start with `recent-hotfixes.txt` to confirm what was installed and when. Then check `pending-reboot.txt`. A machine stuck between servicing phases can behave differently from a machine that cleanly failed before download. Next, open the WindowsUpdateClient event log in Event Viewer and filter around the failure time. Look for repeated error codes, failed downloads, failed installations, or rollback events.

Use `WindowsUpdate.log` for scan and download clues, `CBS.log` for component servicing clues, and `DISM.log` if you already ran image repair commands. Microsoft documentation for Windows Update failures often points to CBS and DISM logs because many installation problems are really servicing problems. Do not delete the SoftwareDistribution folder or component store caches until you have saved the evidence and know why you are doing it.

What to send to support

A useful support packet is not just a zip. Include a short plain-language summary with the Windows version, update KB if known, exact error code, failure time, device model, and what repair steps were already attempted. If the machine is managed by work or school, include whether it receives updates through Intune, Configuration Manager, WSUS, or ordinary Windows Update.

Before sharing the zip, inspect text files for usernames, internal domains, tenant details, paths, or software names that should be redacted. For public forums, summarize the relevant error lines instead of posting the entire archive. For internal IT, the full archive may be appropriate if your organization has a secure ticket system.

The main rule is evidence first, repair second. A clean log packet gives you a better chance of choosing the right fix instead of stacking random commands on top of the original failure.

Sources

Disclaimer: "All content is for educational use only. Always backup your data before fixing errors."