Type to search 97 articles.

    Practical engineering guidance

    Windows Update keeps failing: repair the component store with evidence, not resets

    Repeated update failure can be scan, download, servicing-stack, component-store or pending-action trouble. DISM health state and CBS evidence decide the repair path.

    Series: Microsoft troubleshooting field guides

    • Windows Server
    • Windows Update
    • DISM
    • Troubleshooting

    Troubleshooting flow for Windows Update keeps failing: repair the component store with evidence, not resets.

    Repeated update failure can be scan, download, servicing-stack, component-store or pending-action trouble. DISM health state and CBS evidence decide the repair path.

    The fastest safe repair is rarely the first setting that makes the error disappear. Start by identifying the failed layer, preserve the evidence, change one cause and repeat the same test.

    Recognise the failure

    • The same cumulative update fails repeatedly.
    • DISM reports that source files could not be found.
    • SFC finds corruption it cannot repair.
    • A server remains in a pending-reboot or servicing state.

    Write down the affected identity or resource, UTC time, client, source network and correlation or request ID before retrying. Nearby successful events are useful comparisons, but they are not the failed transaction.

    Collect evidence before changing configuration

    The following commands are read-only unless a comment explicitly says otherwise. Replace every placeholder and use the least-privileged administrative role that can read the required data.

    Get-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"
    
    DISM.exe /Online /Cleanup-Image /CheckHealth
    DISM.exe /Online /Cleanup-Image /ScanHealth
    
    Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'} `
      -MaxEvents 50 | Select-Object TimeCreated,Id,LevelDisplayName,Message
    
    Get-Content 'C:WindowsLogsCBSCBS.log' -Tail 300
    Evidence What it proves
    Update error code The same HRESULT can appear at different stages; record package and time.
    DISM health state CheckHealth is quick; ScanHealth proves whether the component store is repairable.
    CBS log Find the first component or manifest failure around the attempt.
    Repair-source version The source must match edition, language, architecture and patch level closely enough to supply components.
    Pending operations Reboot state and servicing transactions can block further repair.

    Work through the likely causes

    1. Component-store corruption is repairable online

    Run RestoreHealth during a maintenance window, then SFC. Preserve logs before and after.

    2. Windows Update cannot provide repair content

    Use a known-good matching Windows source with /Source and, when required, /LimitAccess.

    3. The failure is package-specific, not general corruption

    Use CBS and setup event logs to identify prerequisites, servicing stack, language pack or compatibility blocks.

    4. A pending action is stuck

    Prefer a supported reboot and normal servicing completion. Use offline RevertPendingActions only for documented recovery scenarios with a backup.

    Make the fix controlled and reversible

    Before changing production, capture the current configuration, name the owner of the affected service and define the rollback trigger. Prefer the narrowest change that corrects the proven cause. Do not disable a tenant-wide security control, remove a protection policy or broaden a role simply to see whether the symptom changes.

    Where a change affects identity, mail flow, security telemetry or network routing, use a test object or limited scope first. Record the exact command or portal setting, the operator, timestamp and the evidence that justified it.

    Validate the repair

    • Run DISM ScanHealth again and confirm no corruption.
    • Run sfc /scannow and record its final state.
    • Install the original failed update and confirm success.
    • Check servicing and update events after the reboot.

    A successful portal message is not the end of validation. Confirm the user or workload outcome, the relevant audit or health record and the absence of a weaker fallback path.

    Evidence to keep

    • the original error, correlation or request ID and UTC timestamp;
    • the read-only command output that identified the failed layer;
    • before-and-after configuration for the specific change;
    • the successful validation transaction; and
    • any limitation that still needs monitoring or vendor escalation.

    References