Error 0x80080005 (CO_E_SERVER_EXEC_FAILURE) means a COM server — the background component Windows Update uses to do its work — failed to start or crashed on launch. In practical terms, the Windows Update service or one of its helper components is broken at the process level: it is not a bad download or a corrupt package, but the machinery itself refusing to run.

On Dell laptops this often follows a botched update, a registry cleaner that removed COM registrations, or antivirus software that blocked a system component from launching. The symptom is distinctive: Windows Update may show a blank page, fail instantly when you click ‘Check for updates’, or report this code without any download attempt at all.

Repair means getting the service and its COM registrations healthy again: restart the services, re-register the update DLLs, repair system files, and reset the update components. It is plumbing work, and the order below goes from least to most invasive. If you are dealing with a related symptom instead, see the 0x80240016 install-conflict error and the 0x80070652 already-running error .

If Windows Update shows a blank page or fails the instant you click ‘Check for updates’, that immediacy is the signature of this error — the machinery crashes before any real work begins. There is no point troubleshooting downloads or packages here, because the service never gets far enough to attempt either. The repairs below are plumbing work: re-registering the COM components, repairing the binaries behind them, and resetting the state they start from.

Why this happens

  • Windows Update service crashed wuauserv fails to start or dies immediately.

  • Corrupt COM registrations update DLLs lost their registry entries.

  • Antivirus blocking service launch security software prevents the COM server from executing.

  • Corrupt system files damaged binaries behind the update service.

  • Registry cleaner damage third-party tools deleted needed COM registrations.

  • Conflicting pending operations stale state prevents the service from initializing.

  • User profile or permissions damage the service cannot access what it needs under its account.

How to fix it

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

Fix 1: Restart the Windows Update services

Clears transient crashes and hung states. Set the Startup types correctly while you are there: Automatic for BITS and Cryptographic Services prevents this entire failure class from recurring. While in services.msc, verify the ‘Log On’ account for Windows Update is still Local System; permission changes here are a rare but real cause of launch failures.

  1. Press Win + R, type services.msc, press Enter.

  2. Restart ‘Windows Update’, ‘Background Intelligent Transfer Service’, and ‘Cryptographic Services’.

  3. Set each Startup type to Automatic (or Manual for Windows Update).

  4. Open Settings > Windows Update and click ‘Check for updates’.

Fix 2: Re-register the Windows Update DLLs

Rebuilds the COM registrations this error is named for. Run the commands from an elevated prompt or every single one will fail; regsvr32 needs administrator rights to write the COM registrations. Copy the DLL list into a batch file if you ever need to repeat this; running ten regsvr32 commands by hand is tedious and easy to mistype.

  1. Open Command Prompt as administrator.

  2. Run: net stop wuauserv, net stop bits.

  3. Run each of these, confirming success: regsvr32 atl.dll, regsvr32 wuapi.dll, regsvr32 wuaueng.dll, regsvr32 wuaueng1.dll, regsvr32 wucltui.dll, regsvr32 wups.dll, regsvr32 wups2.dll, regsvr32 wuweb.dll, regsvr32 qmgr.dll, regsvr32 msxml3.dll.

  4. Run: net start wuauserv, net start bits.

  5. Retry Windows Update.

Fix 3: Run SFC and DISM

Repairs the underlying binaries the COM server loads. DISM first, then SFC, then a reboot, then retry — that sequence is the canonical repair order Microsoft’s own support engineers follow. If DISM fails with its own error, fix that first using an ISO source; a DISM that cannot run cannot repair the store the COM server depends on.

  1. Elevated prompt: DISM /Online /Cleanup-Image /RestoreHealth.

  2. Then: sfc /scannow.

  3. Restart the laptop.

  4. Retry the update.

Fix 4: Reset Windows Update components

Wipes corrupted state that can crash the service on start. If the SoftwareDistribution.old folder grows stale over weeks, delete it to reclaim the disk space; it serves no purpose once the new one is working. After the reset, open Windows Update and let it check for updates without interrupting; the first check rebuilds the database and takes noticeably longer than usual.

  1. Stop wuauserv, cryptSvc, bits, msiserver.

  2. Rename SoftwareDistribution and catroot2 folders to .old.

  3. Restart the services.

  4. Retry Windows Update.

Fix 5: Check antivirus exclusions

If security software blocks the COM server, add exclusions or test without it. Windows Security (Defender) does not need these exclusions, but third-party suites with aggressive behavior blocking frequently do. Add exclusions for the full servicing paths — SoftwareDistribution, catroot2, and System32 — rather than single files, since the COM server touches many components.

  1. Temporarily disable third-party antivirus real-time protection.

  2. Retry Windows Update immediately.

  3. If it works, add exclusions for C:\Windows\SoftwareDistribution and the update services, then re-enable.

Fix 6: Run the Windows Update troubleshooter

Automated check of the service configuration. The troubleshooter cannot fix broken COM registrations itself, but it reliably detects the service misconfiguration that accompanies them. The troubleshooter’s report names the exact service or setting it changed, which helps you understand whether the root cause was configuration or corruption.

  1. Settings > System > Troubleshoot > Other troubleshooters.

  2. Run Windows Update troubleshooter, apply fixes, restart.

Fix 7: Create a fresh admin profile test / in-place upgrade

Determines whether the damage is profile-level or system-level. Testing in a fresh profile takes ten minutes and definitively separates profile-level damage from system-level damage, saving hours of misdirected repair. If the new profile works, use Windows’ built-in migration to move your files rather than copying AppData by hand; manual copies often carry the corruption with them.

  1. Create a new local administrator account and test Windows Update there.

  2. If it works in the new profile, migrate to it.

  3. If it fails there too, run an in-place upgrade from a Windows 11 ISO (keep files and apps) to rebuild the servicing stack.

Closing

Error 0x80080005 is the update engine failing to start its own machinery. Re-registering the components and repairing the underlying files restores the COM server, and Windows Update goes back to behaving like a normal service instead of crashing on launch. For official guidance, see Microsoft’s Windows update support hub .

Frequently asked questions

What does 0x80080005 mean?
CO_E_SERVER_EXEC_FAILURE: a COM server process that Windows Update depends on failed to launch. The update service cannot start its worker components, so checks and downloads fail immediately. Unlike download or package errors, this is the machinery itself refusing to run — the service crashes before any update work begins. Re-registering the update DLLs and repairing system files restores the broken launch path.
Why does Windows Update show a blank page with this error?
Because the UI depends on the same COM components. When they fail to start, the Settings page cannot populate — the blank page and the error code are two symptoms of one broken service layer. The Settings app asks the update COM server for status, gets no answer, and renders nothing. Fixing the underlying COM registration problem restores both the page and the update functionality in one stroke.
Is regsvr32 safe to run on these DLLs?
Yes — these are Microsoft’s own update components, and re-registering them is a documented repair step. Each command simply rewrites the registry entries that tell Windows where the component lives. You are not modifying the DLLs themselves, only restoring their registration records. Run Command Prompt as administrator, confirm each success dialog, and restart the update services afterward.
Could a registry cleaner have caused this?
Quite possibly. Aggressive registry cleaners are a known cause of broken COM registrations. Avoid them going forward — they cause more update failures than they ever fix. These tools delete registry entries they deem unused, but COM registrations for system components look unused right up until Windows needs them. The performance gains they promise are negligible on modern systems, while the damage can be severe.