Troubleshooting Windows Update Failures: Cache, Services, and Post-Malware Repair

When Windows Update keeps failing, work from least invasive to most invasive: run the built-in Windows Update troubleshooter first, then reset the update cache by stopping the Windows Update service and renaming the SoftwareDistribution folder, then check for deeper damage — disabled services, a modified hosts file, or rogue policy entries — which is especially common on machines that were recently infected with malware. If all of that checks out and updates still fail, install the update manually from the Microsoft Update Catalog or perform an in-place repair upgrade.

Step one: the Windows Update troubleshooter

Windows 10 and 11 ship with an automated troubleshooter specifically for update problems. In Windows 11 it lives under Settings > System > Troubleshoot > Other troubleshooters > Windows Update. It restarts the relevant services, clears stuck downloads, and fixes several known misconfigurations without you touching anything by hand.

On the exam and in real life, this is the FIRST tool to reach for when a PC shows generic update error codes. It is fast, it is safe, and it resolves a surprising share of tickets. Only when the troubleshooter reports it could not fix the problem — or the failure returns — do you move to manual repairs.

Step two: reset the update cache (SoftwareDistribution)

Windows stages every update it downloads in C:\Windows\SoftwareDistribution. If files in that folder are corrupted — a half-finished download, a bad disk sector, interference from security software — the same update can fail over and over with the same error code. The fix is to force Windows to rebuild the cache:

1. Stop the Windows Update service (wuauserv) and the Background Intelligent Transfer Service (BITS). You can do this from the Services console (services.msc) — Task Manager’s Services tab can stop them too, though startup types live only in services.msc — or an elevated prompt with net stop wuauserv and net stop bits.
2. Rename C:\Windows\SoftwareDistribution to something like SoftwareDistribution.old. Renaming is safer than deleting — you can roll back if needed.
3. Restart both services. Windows recreates the folder from scratch and re-downloads pending updates with a clean slate.

The ordering matters: the folder is locked while the update service is running, so you must stop the service before you can rename it. Expect an exam question that tests exactly that sequence and exactly that folder name.

Step three: post-malware damage

Malware frequently sabotages Windows Update on purpose — an infected machine that cannot patch itself stays exploitable. Even after the infection is cleaned, the damage it did to the update mechanism remains until you repair it. On any PC where update failures started around the time of an infection, check these areas:

• Service configuration. Malware commonly sets the Windows Update service, BITS, or Cryptographic Services to Disabled. An error saying a required update service cannot start after a cleaned infection almost always means the service’s startup type is still Disabled — the malware changed it and removal tools rarely change it back. Reset the startup type to its default (Manual/Automatic depending on the service) and start it.
• The hosts file. C:\Windows\System32\drivers\etc\hosts can be edited to redirect Microsoft update domains to a dead address, silently blocking downloads. Any entry pointing an update-related domain somewhere unexpected should be removed.
• Registry policy keys. Malware can write values under the Windows Update policy keys (the HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate area) that disable updating entirely. If a service’s startup type was set “by policy” but the organization never configured any such policy, the most likely explanation is that malware wrote the policy entry. This trips people up because the setting looks like legitimate IT administration — the giveaway is that nobody in the org actually deployed it.
• System file integrity. Run sfc /scannow and, if needed, DISM to repair protected system files the infection may have replaced or corrupted.

Checking the service startup types and scanning system file integrity are the two classic “post-infection update repair” checks, and they pair naturally: one restores the plumbing, the other restores the pipes. For the full removal workflow that precedes this repair, see malware removal and remediation.

SFC vs. DISM

	SFC (System File Checker)	DISM (Deployment Image Servicing and Management)
Command	sfc /scannow	DISM /Online /Cleanup-Image /RestoreHealth
What it repairs	Protected Windows system files	The component store SFC pulls its repair copies from
Repair source	Local component store	Windows Update (or a specified source)
When to run	First, for suspected system file corruption	When SFC fails or reports it could not fix files

The practical rule: if SFC cannot complete its repairs, the local repair source itself is damaged — run DISM to fix the store, then run SFC again.

When everything checks out: install manually

Sometimes you clear the cache, confirm the services run, verify DNS resolves Microsoft’s update domains, and get clean results from both SFC and DISM — and the same update still fails. At that point, stop fighting the automatic mechanism and go around it: download the update’s standalone package from the Microsoft Update Catalog and install it manually. Searching the catalog by the update’s KB (Knowledge Base) number gets you an installer that does not depend on the client-side machinery that is misbehaving. If even manual installation fails, the remaining option is an in-place repair upgrade, which reinstalls Windows over itself while keeping apps and data.

How the 220-1202 exam tests this

Update-repair scenarios anchor the Software Troubleshooting domain — the full 220-1202 study guide breaks down every domain’s weight, and the practice exam bank runs this repair ladder from every angle.

• A scenario describes repeated monthly update failures with generic error codes and asks what to run FIRST — the answer pattern is the built-in Windows Update troubleshooter, not manual surgery.
• A scenario states the technician suspects a corrupted update cache and asks which folder gets renamed after stopping the update service — SoftwareDistribution, with the stop-the-service prerequisite baked into the question.
• A post-malware scenario says a required update service cannot start, or that a policy nobody configured disabled the service, and asks for the most likely cause — the expected reasoning is that the malware disabled the service or wrote the policy entry, and cleanup did not revert it.
• A process-of-elimination scenario lists everything that already checks out (cache cleared, service running, DNS fine, SFC/DISM clean) and asks what is NEXT — manual installation from the Microsoft Update Catalog.

Quick reference

• Run the built-in Windows Update troubleshooter before any manual fix.
• Corrupted update cache: stop wuauserv (and BITS), rename C:\Windows\SoftwareDistribution, restart the services.
• The folder cannot be renamed while the update service is running — stop it first.
• After malware: check service startup types (Windows Update, BITS, Cryptographic Services), the hosts file, and update-related registry policy keys.
• A “policy” disabling updates that the organization never configured points to malware, not IT.
• sfc /scannow repairs system files; DISM repairs the component store SFC relies on.
• When all client-side checks pass and updates still fail, install the update manually from the Microsoft Update Catalog.
• Last resort: an in-place repair upgrade that preserves apps and data.