COM+ Catalog Server Threw an Exception — Fix 0x80110486 Fast

Yeah, that error is annoying — you open Component Services, try to expand a COM+ application, and it just throws COMADMIN_E_CAT_SERVERFAULT (0x80110486) in your face with no context.

Here's the fix. It's a four-step procedure and you should do all four, in order, on the server that's misbehaving.

Step 1 — Stop everything that touches COM+

Open an elevated Command Prompt. If you skip elevation, later steps will fail with "Access Denied" and you'll think the fix didn't work.

net stop msdtc
net stop com+ system application
net stop "COM+ Event System"
net stop "System Event Notification Service"

You should see "The COM+ System Application service was stopped successfully" for each one. If a service reports it wasn't started, that's fine — keep going.

Step 2 — Re-register comsvcs.dll

This DLL is the heart of COM+. When the catalog file (the MSI-backed database under C:\Windows\Registration) gets out of sync with it, you get 0x80110486.

cd /d %windir%\system32
regsvr32 /s comsvcs.dll

No output on success with /s. If you drop the /s, you should see a dialog saying "DllRegisterServer in comsvcs.dll succeeded."

Step 3 — Rebuild the COM+ catalog

The catalog lives in C:\Windows\Registration. Back it up first — you might need it.

robocopy C:\Windows\Registration C:\Windows\Registration.bak /E
cd /d %windir%\system32
regsvr32 /s /i comsvcs.dll

The /i flag tells comsvcs.dll to reinstall itself, which rewrites the catalog files. This takes 10–30 seconds. You'll see the disk churn, then it returns to the prompt.

Step 4 — Restart services and test

net start "COM+ Event System"
net start "System Event Notification Service"
net start com+ system application
net start msdtc

Now open comexp.msc. Expand Component Services → Computers → My Computer → COM+ Applications. It should populate without a hiccup. If you still see 0x80110486 here, jump to the "when it doesn't work" section below.

Why this actually works

The COM+ catalog isn't a single file. It's a set of MSI-backed databases (R0000000C.clb and friends) that get written by comsvcs.dll. When an install fails halfway through — a botched deployment, a hard reboot during a COM+ app install, or an antivirus lock on C:\Windows\Registration — the catalog ends up with a half-written record. On next read, the catalog server thread throws an unhandled exception and surfaces it as 0x80110486 to whatever MMC or app was asking.

Re-registering comsvcs.dll forces it to reload its type info. The /i switch then triggers the catalog-write path against a clean state. Skip either step and you're just masking the problem — the catalog keeps the bad record until something rewrites the whole store.

I've seen this most often on servers where someone killed a VS installer or an MSI mid-COM+-registration. It also shows up after a Windows Update where the machine was forcibly shut down during the "Configuring updates" phase.

When the four-step fix doesn't clear it

Case 1: Error returns the moment you stop touching it

That points at MSDTC, not the catalog. Check the DTC log:

msdtc -resetlog
net stop msdtc
net start msdtc

Also verify the DTC is using local transactions correctly under Component Services → My Computer → Distributed Transaction Coordinator → Local DTC → Properties → Security. If "Network DTC Access" is enabled but the firewall rules for RPC dynamic ports aren't in place, transactions hang and eventually the COM+ transaction manager faults.

Case 2: A specific application throws it, not the whole MMC

That app has a bad registration. Export it, remove it, re-register the DLLs, reimport:

regasm /unregister YourApp.dll
regasm /tlb /codebase YourApp.dll

For VB6/legacy COM components, use regsvr32 /u then regsvr32 on each DLL. Don't run "Component Services → New → Application" and hope it self-heals — it won't.

Case 3: 0x80110486 on Windows Server 2012 R2 through 2019 after patching

Check C:\Windows\Registration permissions. A handful of update packages have left that folder with SYSTEM-only access, which breaks the catalog write from any elevated user context. Reset it:

icacls C:\Windows\Registration /reset /T /C
icacls C:\Windows\Registration /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" /T /C
icacls C:\Windows\Registration /grant "BUILTIN\Administrators:(OI)(CI)F" /T /C

Then rerun steps 2 and 3.

Case 4: Event log shows DCOM 10016 alongside the COM+ fault

Those two are related more often than people think. Run dcomcnfg, expand Component Services → Computers → My Computer → DCOM Config, and check the app-specific launch permissions. If the app identity is a service account, it needs "Local Launch" and "Local Activation" explicitly — the default only grants that to Administrators and SYSTEM.

Prevention so you don't see this again

• Never hard-reboot a server during a COM+ application install. The catalog writes are not journaled the way you'd hope.
• Exclude C:\Windows\Registration from real-time AV scanning. Every major endpoint product has shipped at least one signature update that locked a .clb file.
• Back up C:\Windows\Registration before you push any COM+ app updates. A robocopy to a network share takes two seconds and has saved me more than once.
• If you're deploying via MSI, don't kill msiexec. Ever. Even if it looks hung. Wait it out. The alternative is the procedure above.
• On clustered servers, run the rebuild on the passive node first so the active node keeps serving while you validate.

That's the whole thing. Stop services, re-register, rebuild the catalog, restart. If it comes back, it's MSDTC or permissions — not the catalog itself.