Patch management

Why Windows updates fail: how to find the real cause

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.

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.
• 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.
• 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.
• Pointed at a server that no longer answers. Many machines "checking for updates" that never find any, often with 0x8024402f or similar. Almost always a leftover WSUS address or update policy from a previous management tool, still set after the server was retired.
• 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.

What to do about each

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.

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.

Corruption: stop the update service, clear the SoftwareDistribution folder, then run DISM /Online /Cleanup-Image /RestoreHealth and sfc /scannow. If the same machine needs this twice, stop nursing it and rebuild it. A morning of reimaging is cheaper than a year of monthly surgery.

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

One caution once the estate looks green: Windows updates are the visible half of patching. The browsers and readers that attackers actually target update outside Windows Update entirely, and deserve the same scrutiny.

Where this fits with Helios

Diagnosis is quick when the tells are in front of you, and 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.