Why Windows updates fail: how to find the real cause and fix it

Windows updates fail for one of about five common causes: a full system drive, a reboot that never happens, corrupted update components, a leftover WSUS address pointing at a server that no longer answers, or a machine that is simply never online during the patch window. Each cause has its own tell in the error codes and logs, and its own fix. Patch reports show the result as a plateau: the same few devices failing every month, whether the machines belong to clients or to your own company. Here is how to tell the causes apart, and what to do about each.

The symptom: a compliance number that will not move

Windows Update failures are not evenly spread. On a healthy estate, most machines patch themselves without ever being noticed, and the failures concentrate on repeat offenders: a machine that fails an update this month very often failed one last month too. So the gap between 92% and 100% is not random noise. It is a short, stable list of devices, and those are precisely the machines that stay exposed to known vulnerabilities the longest.

The mistake is treating that list as a queue of identical chores. Reboot it, run the troubleshooter, watch it fail again in four weeks. The faster route is to work out which of the five causes each machine actually has, because the causes announce themselves quite clearly once you know the tells.

How to tell which cause you actually have

Start with the pattern, not the machine. One device failing repeatedly points to a local cause: disk, reboot state or corruption. Many devices failing at once points to infrastructure: they are all being told the same wrong thing. No errors at all, just staleness, points to machines that were never switched on when it mattered.

• Full disk. The tell is error 0x80070070, or simply a system drive with under 15 GB free. A cumulative update needs room to download, unpack and install, roughly triple its own size. Classic on older 128 GB SSDs, which fill up the way lofts accumulate boxes: gradually, then completely.
• Pending reboot loop. The update reports installed, but compliance never changes and the device sits at "restart required" for weeks. Usual suspects: laptops that sleep every night and are never actually restarted. Modern Windows makes this worse, because closing the lid looks like shutting down and is nothing of the sort.
• Corrupted update components. The same machine throws the same error code month after month, often 0x80073712 or another component-store error. The troubleshooter fixes it once, then it breaks again. The corruption usually lives in one of two places: the download cache in SoftwareDistribution, or the component store itself under WinSxS.
• Pointed at a server that no longer answers. Many machines "checking for updates" that never find any, often with 0x8024402f, 0x8024401c or similar. Almost always a leftover WSUS address or update policy from a previous management tool, still set after the server was retired. The devices are dutifully asking a corpse for instructions.
• Never online during the window. No errors anywhere. The machine is just behind, because it belongs to someone part-time, on leave, or it lives in a cupboard. Failure and absence look identical on a lazy report, and they need entirely different responses.

Where the evidence lives: history, logs and error codes

Before you can match a machine to a cause, you need its history, and Windows keeps that history in several places of varying honesty.

• Update history in Settings. Settings, Windows Update, Update history. Quick, and it shows the failed attempts alongside the error code for each. This is where most diagnoses start and, for the disk and WSUS cases, where they can end.
• The Windows Update log. On Windows 10 and 11 the old plain-text log is gone. Run Get-WindowsUpdateLog in PowerShell to reconstruct it from ETW traces onto the desktop. It is verbose, but it names the server the client is actually talking to, which settles the stale-WSUS question in one search.
• CBS.log. Component-store failures leave their trail in C:\Windows\Logs\CBS\CBS.log. If sfc /scannow or DISM reports problems, this is where the detail is.
• Event Viewer. The Microsoft-Windows-WindowsUpdateClient/Operational log records installs, failures and reboots with timestamps, which is useful when you need to prove a machine has been "restart pending" since March.
• The policy registry key. HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate is where a configured WSUS address hides, in the WUServer value. If that key exists and the server it names does not, you have found your fleet-wide cause.

What the common error codes actually mean

Windows Update error codes look like line noise, but a handful cover most real-world failures, and each maps neatly onto one of the causes above.

• 0x80070070: disk full. The literal meaning is "there is not enough space on the disk", and for once the error means exactly what it says. Check free space before anything else.
• 0x80073712: component store corruption. The servicing stack has lost or damaged files it needs. This is the DISM and SFC case.
• 0x80070002 and 0x80070003: file not found. Usually a damaged download cache, fixed by clearing SoftwareDistribution rather than by deep surgery.
• 0x8024402f and 0x8024401c: the client cannot reach, or times out against, its update server. On a single machine, suspect a proxy or firewall. On many machines at once, suspect a stale WSUS policy.
• 0x800f081f: DISM cannot find source files to repair from. The machine needs a known-good source, either Windows Update itself or mounted installation media passed with the /Source switch.
• 0xC1900101: a feature update rolled back during setup, almost always because of a driver. Covered in the feature update section below.

A code you do not recognise is not a dead end. Search the specific hex value rather than the vague message around it, because the code is precise and the message rarely is.

What to do about each cause

Full disk: clear space with Disk Cleanup or Storage Sense and remove old profiles, but be honest when the drive is simply too small. That machine is a hardware decision, not a patching one, and belongs in your refresh plan. Skip this honesty and you will free 4 GB every month forever, one careful gigabyte at a time.

Reboot loop: enforce restarts with a visible warning and a deadline rather than hoping users oblige. Then change what you measure: "installed" is not the finish line, "installed and restarted" is. A patch that has not survived a reboot has not protected anything yet.

Corruption: run DISM /Online /Cleanup-Image /RestoreHealth and then sfc /scannow, in that order, because SFC repairs from the component store and DISM repairs the component store itself. If the download cache is the problem rather than the store, reset the components properly, as below.

Stale update server: check for a configured WSUS address in policy or the registry and remove it, so devices talk to Microsoft's servers directly. Delete the policy, run gpupdate /force if the machines are domain-joined, then check in again. Because the cause is shared, so is the cure: one change can bring a whole fleet back, which is why it is worth checking first after leaving an old RMM. If you are still weighing that move, our comparison of the major RMM and PSA tools covers what each leaves behind.

Absent machines: decide deliberately. Wake devices for a maintenance window, or accept the lag but make reporting distinguish "failed" from "not seen for 30 days". Both need attention, but not the same attention, and a report that conflates them is a guess wearing a spreadsheet's clothes.

Stuck downloads and "undoing changes": the two symptoms users report

The people you support rarely quote error codes. They describe two things: an update sitting at 0% or some fixed percentage for hours, and a restart that ends with "We couldn't complete the updates. Undoing changes." Both map onto the same five causes, once you stop reading the screen and start reading the logs.

• Stuck at a percentage. A download frozen at 0% usually means the client cannot reach its server or BITS has stalled, so check the WSUS key and the network path first. A download that reaches 100% and never installs is more often disk space or a damaged cache. Give it a fair interval, because large cumulative updates can sit still for a long while on slow disks, and then reset the components rather than waiting another day.
• Undoing changes. This is a rollback: the install began, hit something it could not resolve, and reverted. Check Update history for the code. A disk or component-store error points back to the fixes above; a 0xC1900101 family code points at drivers. The loop continues every night until you fix the cause, because Windows will keep offering the same update.

The overnight test: if a machine shows the same percentage after a full night online and awake, it is not slow. It is stuck, and waiting longer is just a quieter way of doing nothing.

How to reset Windows Update components properly

"Reset Windows Update" is the most searched fix and the most sloppily executed one. The troubleshooter does a version of it. Done by hand, it takes two minutes and you know exactly what happened. From an elevated prompt:

1. Stop the services: net stop wuauserv, net stop cryptSvc, net stop bits, net stop msiserver.
2. Rename the caches: ren C:\Windows\SoftwareDistribution SoftwareDistribution.old and ren C:\Windows\System32\catroot2 catroot2.old. Renaming rather than deleting means you can roll back if something else was living in there.
3. Restart the services: the same four net start commands in reverse.
4. Check for updates again. The client rebuilds its cache from scratch and re-downloads anything in flight. Update history in Settings will look empty afterwards; the installed updates themselves are untouched.

Delete the .old folders once the machine has patched cleanly, or they become their own disk-space problem, which would be a tidy irony.

Feature updates fail for their own reasons

Everything above applies to monthly cumulative updates. Feature updates, the big version upgrades, add failure modes of their own and deserve a separate glance before you assume corruption.

• They need far more disk. A feature update is effectively a reinstall of Windows that keeps your files, and the working space required is measured in tens of gigabytes, not single figures. A machine that takes monthly patches happily can still choke on a version upgrade.
• Safeguard holds are not failures. Microsoft blocks feature updates on hardware or driver combinations with known problems. The machine reports itself as up to date while quietly staying on the old version. That is a hold, not a fault, and forcing past it is how you inherit the known problem.
• Drivers and low-level software interfere. Setup failures with 0xC1900101 codes almost always mean a driver problem, most often storage, graphics or third-party security software. The setup logs under C:\$WINDOWS.~BT\Sources\Panther usually name the offending driver. Update or remove the culprit before retrying, rather than retrying five times and then reimaging in a temper.

When to stop fixing and rebuild

The twice test: if the same machine has needed component repair twice, stop nursing it and rebuild it. A morning of reimaging is cheaper than a year of monthly surgery, and a component store that keeps re-corrupting is usually telling you something about the disk underneath it. Run a health check on the drive before you put a fresh image on failing hardware, because a rebuild on a dying SSD is just a slower way of doing the same ticket again in the autumn.

The same logic applies at estate level. If ten machines share a symptom, do not fix ten machines. Find the shared cause: the policy, the image, the retired server they all still believe in.

Two failure modes to avoid

Estates go wrong with update management in two opposite ways, and it is worth knowing which one you are prone to.

The whack-a-mole estate treats every failed update as a fresh ticket. Someone remotes in, runs the troubleshooter, reboots, closes the ticket, and the same device is back next month because nobody asked which of the five causes it had. The compliance number stays at 92% forever while the team stays busy. Activity is mistaken for progress.

The report-worship estate has the opposite vice: the dashboard says green, so nobody looks closer. But "installed" without "restarted" is not protection, "no errors" from a machine that has not checked in for six weeks is not compliance, and Windows updates are only the visible half of patching anyway. The browsers and readers that attackers actually target update outside Windows Update entirely, and deserve the same scrutiny.

The cure for both is the same: measure the right thing, diagnose by cause rather than by device, and let the short list of repeat offenders get genuinely shorter each month instead of merely churning.

Where this fits with Helios

Most of this article is diagnosis, and diagnosis is quick when the tells are in front of you, tedious when each one means remoting into a machine. The Helios agent reports per-device patch state, disk space, pending reboots and last-seen times side by side, so the failed column separates into its real causes at a glance. When a device needs a closer look, Helio can investigate it and pull the update history and error codes for you, rather than you finding a login window. The judgement calls, like when a machine has failed the twice test, remain yours.

Helios: monitoring and patch visibility for the machines you support, whether they belong to clients or to your own company. 14-day trial and no feature gating. Start free.

Related: Slow computer troubleshooting: find the real cause before you reimage

Common questions about failed Windows updates

Is it safe to delete the SoftwareDistribution folder?

Clearing the SoftwareDistribution folder is safe if you stop the Windows Update, BITS, cryptographic and installer services first. The folder holds the download cache and history, not the installed updates, so Windows simply rebuilds it and re-downloads anything pending. Renaming the folder to SoftwareDistribution.old rather than deleting it is the cautious route, because it allows a rollback.

Why does Windows Update keep failing on the same update?

A Windows update that fails repeatedly on one machine usually points to a local cause: too little free disk space, a restart that never completes, or a corrupted download cache or component store. Check Update history for the error code, then run DISM followed by SFC, or reset the update components. If repair has been needed twice, rebuild the machine.

How long should I wait if a Windows update is stuck?

A Windows update showing the same percentage after a full night online and awake is stuck rather than slow. A download frozen at 0% usually means the device cannot reach its update server, often because of a leftover WSUS policy. A download that completes but never installs more often means low disk space or a damaged cache needing a component reset.

What does "Undoing changes made to your computer" mean?

The "Undoing changes made to your computer" message means a Windows update began installing, hit an error and rolled back. Windows will keep offering the same update until the underlying cause is fixed. Check Update history for the error code: disk and component-store codes point to cleanup or DISM repair, while 0xC1900101 codes on feature updates point to a driver problem.

Researched and written with Helio SEO, our AI writer for business blogs.