Windows Update stuck at 0% or 100%: the fix order that works
Stop the update services, clear the download cache, and let Windows rebuild it: stop wuauserv, cryptSvc, bits and msiserver, rename C:\Windows\SoftwareDistribution and C:\Windows\System32\catroot2, then start the services again.
If updates still fail, repair the component store first with DISM /Online /Cleanup-Image /RestoreHealth, then run sfc /scannow, reboot, and retry the update. Running SFC before DISM is the usual mistake: SFC repairs from the component store, so a damaged store has to be fixed first.
A machine that sits at 0% downloading, or at 100% installing, is almost always one of three things: a corrupted download cache, a damaged component store, or something upstream of the machine entirely (WSUS, a metered connection policy, or a full disk). The sequence below deals with them in order of likelihood and cost, so you stop as soon as one works.
Step 1: reset the update components
The download cache in SoftwareDistribution corrupts more
often than anything else in the chain. Renaming it is safe: Windows
rebuilds it on the next check. You lose the update history display, not
the updates themselves.
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start bits
net start cryptSvc
net start wuauservRun from an elevated prompt, then check for updates again. If the stall
was the cache, this fixes it in five minutes. Delete the two
.old folders once updates are flowing.
Step 2: repair the image, then the files
If the same update fails repeatedly with an error code, the component store is the next suspect. Order matters here:
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowDISM repairs the component store from Windows Update itself; SFC then repairs system files from that store. DISM pausing at 62.3% for a long while is normal, let it run. Expect 10 to 30 minutes each. Reboot and retry the update afterwards.
Step 3: look outside the machine
- Disk space. Feature updates want 20 GB free or more. Check before blaming the machine.
- WSUS or Intune policy. If the machine points at a
dead WSUS server it will wait forever. Check
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdatefor a staleWUServervalue. - Metered connection. A connection marked metered quietly defers downloads.
Step 4: the in-place repair upgrade
When a machine resists all of the above, an in-place upgrade reinstalls
Windows while keeping applications, settings and data. Mount the matching
ISO and run setup.exe, choosing to keep everything. It takes
about an hour and resolves the deep cases without a rebuild.
Chasing update state across a whole fleet?
Moorfox shows every machine's agent and patch state in one list, gives you a remote terminal to run exactly these commands without interrupting the user, and keeps the machine's logs readable even when it goes offline.
Related tool: subnet calculator, for when the update problem turns out to be a network problem after all.
Frequently asked questions
Is it safe to delete the SoftwareDistribution folder?
Yes. It is a download cache and Windows rebuilds it automatically. You lose the visible update history but not the installed updates. Rename rather than delete so you can roll back if needed.
Should I run SFC or DISM first?
DISM first, then SFC. SFC repairs files using the component store, so if the store itself is damaged SFC either fails or reports unfixable corruption. DISM /RestoreHealth repairs the store from Windows Update.
Why does DISM hang at 62.3%?
It is not hung. That stage performs the slow comparison work and can sit at the same percentage for 15 minutes or more, especially on spinning disks. Leave it running.