When optional updates misbehave beyond the quick fixes — failing repeatedly, failing in batches, or failing with different codes each time — you need diagnosis, not just remedies. This is the systematic troubleshooting pass: isolate the failing package, read what the error code is actually telling you, verify the update pipeline itself is healthy, and then apply the targeted fix. Think of it as the difference between treating symptoms and running labs.

If you have not tried the straightforward fixes yet, the companion guide on fixing optional updates that won’t install covers them. This guide assumes those did not fully resolve things, or that you want to understand the failure properly before acting.

The mindset shift for this guide is from “fixing updates” to “reading failures.” Every failed optional update leaves evidence: an error code in Update history, a timestamped entry in the update log, a device state in Device Manager. Most people never look at this evidence and instead apply generic fixes blindly \u2014 which is why generic fixes so often fail here. The steps below teach you to collect the evidence first and let it dictate the fix, which is faster in practice than the shotgun approach, not slower.

Why this happens

  • Multiple independent package failures: Each optional update fails for its own reason; treating them as one problem leads to fixes that address the wrong package.
  • Driver version conflicts: Manufacturer utilities and Windows Update offering different versions of the same driver create install-time collisions.
  • Corrupt per-package downloads: One damaged package in a batch can stall or confuse the whole install sequence.
  • Wedged update services: BITS or wuauserv in a bad state manifests as optional updates stuck at 0% or perpetually “pending install”.
  • Stale device metadata: Windows Update’s hardware inventory is out of date, so it offers drivers for devices that changed, were disabled, or were removed.
  • Policy restrictions: Group Policy or registry settings (common on work laptops) can block driver installation while allowing other updates.
  • Component store damage: A damaged servicing store fails driver payloads with misleading codes — the same territory as driver updates failing in a loop .
  • Disk space pressure: Driver packages need staging space; a nearly full drive causes cryptic install failures that look like driver problems.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Isolate the failures one package at a time

Diagnosis starts with separation.

  1. Go to Settings, Windows Update, Advanced options, Optional updates.
  2. Uncheck everything, then select exactly one update and click Download & install.
  3. Record the result and error code for each package in turn.
  4. You will end up with a list: packages that install fine (pipeline is healthy) and packages that fail with specific codes (package-specific problems). Treat the two groups differently from here on.

Fix 2: Decode the error codes from Update history

  1. Open Update history and expand the failed entries.
  2. 0x800f020b means a driver install failure — see the dedicated 0x800f020b step-by-step guide .
  3. 0x80070002 or 0x80070003 means missing files — clear the cache (Fix 4).
  4. 0x80240034 means the update was superseded — hide it, you do not need it.
  5. No code at all with a silent failure usually means a service stall — continue to Fix 3.

Fix 3: Verify the update pipeline with a test package

Confirm the mechanism works before blaming packages.

  1. If any optional package installed successfully in Fix 1, the pipeline is fine — your remaining failures are package-specific. Skip to Fix 5.
  2. If nothing installs, restart the Windows Update and BITS services via services.msc.
  3. Run the Windows Update troubleshooter from Settings, System, Troubleshoot.
  4. Retry a single small optional update. If it now works, the stall was a service problem.

Fix 4: Purge the cache and reset components

  1. Open an elevated Command Prompt.
  2. Run net stop wuauserv, net stop bits, net stop cryptsvc, net stop msiserver.
  3. Delete the contents of C:\Windows\SoftwareDistribution.
  4. Restart all four services, reboot, and retry the isolated failing packages one at a time.

Fix 5: Resolve driver conflicts at the source

  1. For each failing driver package, check the manufacturer’s support site for a newer version.
  2. Install manufacturer drivers directly for devices you care about.
  3. For devices that work fine, use the wushowhide.diagcab troubleshooter to hide the failing optional package.
  4. If a manufacturer utility (Dell, HP, Lenovo) is fighting Windows Update over the same driver, pause its automatic updates while you sort out Windows Update, then re-enable it.

Fix 6: Check policies and disk space

  1. On Pro editions, open gpedit.msc and check Computer Configuration, Administrative Templates, Windows Components, Windows Update for driver installation restrictions.
  2. Ensure at least 15–20 GB free on the system drive.
  3. Check Settings, Network & internet to confirm the connection is not metered — optional updates are deprioritized on metered connections.

Fix 7: Repair the servicing stack and make a final pass

  1. Run DISM /Online /Cleanup-Image /RestoreHealth followed by sfc /scannow in an elevated Command Prompt.
  2. Restart.
  3. Retry each remaining failing package individually one last time.
  4. Anything still failing on a working device gets hidden; anything failing on a broken device gets a manufacturer driver. Document which you chose for each — future you will thank present you. Microsoft’s official troubleshooting reference at the Windows support hub covers these same escalation steps.

Fix 8: Read the Windows Update log for silent failures

Some optional updates fail without any visible error code.

  1. Open an elevated PowerShell and run Get-WindowsUpdateLog to build a readable log on your desktop.
  2. Search for the driver name or “optional” around the failure timestamp.
  3. Look for access-denied or file-not-found entries \u2014 they reveal whether the failure was permissions, a missing device, or a corrupt package.
  4. Match what you find to the targeted fix: permissions issues mean security software interference, missing-device entries mean hiding the update, corrupt-package entries mean a cache clear.

Closing

Systematic troubleshooting of optional updates is really about refusing to treat five different failures as one problem \u2014 and about reading the evidence each failure leaves behind. Isolate, decode, verify the pipeline, read the logs when codes are absent, then fix each package on its own terms. The payoff is a clean Optional updates page and the knowledge, recorded per package, of exactly what your laptop needs and what it can safely ignore.

Frequently asked questions

What is the difference between this guide and the basic fix guide?
The companion fix guide covers the common quick resolutions. This troubleshooting guide is the deeper diagnostic pass: isolating exactly which package fails, reading the error codes, testing the update pipeline itself, and handling recurring or multi-package failures that the quick fixes did not resolve.
Where do I find the error code for a failed optional update?
Go to Settings, Windows Update, Update history, and expand Driver Updates or Other Updates. Each failed entry shows an error code like 0x800f020b. That code tells you whether you are dealing with a driver mismatch, a corrupt package, or a service problem.
Why do some optional updates install and others fail on the same laptop?
Because each optional package is independent. One driver may match your hardware perfectly while another targets a disconnected device or an already-superseded version. Mixed success is normal and actually helpful — it proves the update pipeline works and the problem is package-specific.
Should I install all optional updates at once?
No — install them one at a time while troubleshooting. Batch installs hide which package failed and can create dependency confusion that muddies the diagnosis. Once everything is healthy and you understand your system’s patterns, batching is perfectly fine. But during diagnosis, the one-at-a-time rule is what lets you attribute each result to its cause.