Why Windows Updates Fail: The 5 Causes, Error Codes and

Patch reports rarely show a disaster. They show a plateau: 92% compliant this month, 91% last month, and the same few devices in the failed column every time. Working out why Windows updates fail is mostly about reading that failed column properly, because a failed update is a symptom with about five common causes, each with its own tell and its own fix. That is true whether the machines belong to clients or to your own colleagues. Here is how to identify each cause, where the evidence lives, and what to do about it.

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 almost always 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.

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. This one fix regularly resurrects whole fleets, especially after leaving an old RMM.

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.

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:

Stop the services: net stop wuauserv, net stop cryptSvc, net stop bits, net stop msiserver.
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.
Restart the services: the same four net start commands in reverse.
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. 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.

Why Windows updates fail: how to find the real cause