Windows Update Keeps Failing: Working Through It

Update failures produce generic error codes that cover several unrelated situations, which is why searching the code alone rarely resolves anything. The reliable approach is to work through the layers in order of cost, because the cheapest checks rule out the most common causes.

Work in This Order

Working from the bottom up is how an afternoon disappears into a component store repair when the volume was simply full.

Free Space

Updates stage files, expand them, and keep enough of the previous state to roll back. The space needed is considerably more than the download size, and feature updates need substantially more than monthly quality updates.

A system volume close to capacity is the single most common cause of an update that downloads and then fails during installation. Clearing space is quick and it either fixes the problem or eliminates it.

Disk Cleanup, run with the option to clean up system files, removes previous update files and old installation data. On a machine that has been upgraded in place, that can be a large amount.

Date, Time and Region

Certificate validation depends on the clock. A machine with a badly wrong date cannot validate the certificates presented during the update exchange, and the failure surfaces as a connection or trust error rather than as a clock problem.

Confirm the time, the time zone and that time synchronisation is working. This takes seconds and it explains a category of failures that look like network problems.

Clearing the Update Cache

The update cache holds downloads in progress and a catalogue of what is available. A partial or corrupted download stays there and is retried, failing identically each time.

The cache can only be cleared with the update services stopped, because they hold the files open. Stop the update service and the background transfer service, rename or clear the distribution folder, then start the services again.

Renaming rather than deleting is worth doing. It has the same effect, the folder is rebuilt on the next check, and the old one is still there if something else turns out to have been the problem.

After restarting the services, check for updates again. The catalogue rebuilds and the download starts fresh.

Repairing the Component Store

If a fresh download still fails to install, the problem is more likely in the component store the update is being applied against than in the update itself.

DISM repairs that store, pulling replacement components over the network. SFC then repairs system files using the store DISM has just fixed. The order matters, and the reasoning is covered in chkdsk, SFC and DISM: SFC copies from the store, so a damaged store gives it nothing valid to copy.

DISM often appears to stall at a percentage for a long stretch. Leave it. Cancelling partway leaves the store in a worse state than when it started.

Reading the Log

Windows records the update process in detail, and the log names the stage that failed. On a machine where the generic steps have not helped, this is the point at which guessing stops.

The log is verbose, and the useful approach is to search it for failure entries rather than reading it through. A specific component name or a driver in a failure line turns a generic error code into something actionable.

The setup log written during a feature update is separate and records the phase and operation where a rollback was triggered, which is the information needed when an update installs and then reverts.

Rollbacks at Restart

An update that applies and then reverts at restart failed its checks during the offline phase. The two usual causes are a driver that the new build rejects and a component store problem that only surfaces when the update is applied.

A driver rollback for recently updated hardware is a reasonable test, particularly for storage and graphics drivers. Disconnecting non-essential peripherals before retrying is another, because a device with a problematic driver that is not attached cannot block the update.

Blocked Updates and Paused Updates

Check whether updates are paused or deferred before troubleshooting anything. A machine configured to defer feature updates is behaving correctly when it does not offer one, and the setting is easy to forget.

Where a machine is managed by an organisation, update behaviour may be controlled centrally and a local fix will not hold.

What People Get Wrong About This

The first mistake is starting with the component store repair. It is the longest step and the least likely cause.

The second is searching the error code and applying the first command found. Update codes are generic; the same code appears with entirely different underlying problems.

A third is deleting the distribution folder while the services are running, which either fails or leaves the update state inconsistent. Stop the services first.

A fourth is cancelling DISM because the percentage has not moved. It frequently sits still while working.

And the last is reaching for a reinstall after a couple of failed attempts. Reinstalling Windows removes installed applications and, depending on the option chosen, the files on the system volume. It is a large cost for a problem that is usually free space or a cached download.

When the Update Is the Problem

Occasionally a specific update genuinely fails on specific hardware, and the manufacturer or Microsoft documents it. If a single update fails repeatedly while others install normally, that is worth checking before spending more effort on the machine.

An update can be hidden or deferred while the underlying issue is resolved, which is preferable to disabling updates entirely and leaving the machine unpatched.