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\Registrationfrom real-time AV scanning. Every major endpoint product has shipped at least one signature update that locked a .clb file. - Back up
C:\Windows\Registrationbefore 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.