I know this error is infuriating — you're just trying to configure a COM+ app and Windows throws this cryptic nonsense at you. Let's cut to the chase.
The Fix
Open Component Services. Run dcomcnfg from the Start menu or Command Prompt. Expand Component Services > Computers > My Computer > COM+ Applications. Find the application that's throwing the error — commonly it's a custom app or one tied to IIS or MSMQ.
Right-click the application and choose Export. Pick Application proxy, save the file somewhere temporary. Then delete the application entirely (right-click > Delete). Now import it back: right-click COM+ Applications, choose New > Application, select Install pre-built application, and point to the exported file you just saved.
If that doesn't work, you'll need to delete the problem component from inside the app, then add it fresh. Drill into the application, expand Components, and delete the component that's causing the error. Then right-click Components > New > Component. Choose Install new component and select the DLL or class that belongs there. This forces the catalog to rebuild the parent-child link correctly.
dcomcnfgWhy This Happens
The COM+ catalog stores every component as a child of a specific COM+ application — that's the "parent collection." When a component gets orphaned (like after a botched uninstall, a partial Windows update, or copying an application across servers), the catalog sees a component without a valid parent. Error 0x80110808 is the catalog saying "I can't save this because I don't know where it belongs."
Deleting and recreating the component resets that relationship. Exporting and reimporting the whole app does the same thing at a higher level. Either way, you're giving the catalog a clean slate.
Less Common Variations
I've seen this error pop up in some weird scenarios:
- MSMQ Triggers: If you're using Message Queuing triggers, a corrupted trigger queue can orphan its COM+ component. The fix is to delete the trigger queue in Computer Management, then recreate it. Same parent-missing logic applies.
- IIS Application Pools: Some IIS versions (especially on Windows Server 2012 R2) tie COM+ apps to application pools. If the pool identity changes or the pool is deleted, the COM+ component loses its parent. Recycle the pool or recreate the COM+ app from scratch.
- XML Parser Registration: A few Microsoft XML (MSXML) components rely on COM+. If you uninstall MSXML 6.0 and reinstall a different version, you might see this error on
msxml6.dll. The fix is to re-register the DLL withregsvr32 msxml6.dlland then manually update the COM+ catalog entry viadcomcnfg.
Prevention
Three things you can do starting today:
- Never manually delete COM+ components from the registry or file system. Always use
dcomcnfgor the COM+ administration API. If you yank a component behind the catalog's back, the parent reference gets stale. - Back up your COM+ applications regularly. In
dcomcnfg, right-click each app and choose Export. Save the proxy file. If you have many apps (like on an IIS server), script this — the COM+ administration library (COMAdmin.COMAdminCatalog) can export programmatically. - Avoid mixing 32-bit and 64-bit components in the same COM+ application. While not directly a parent issue, cross-bit assemblies often fail on import, leaving orphaned components. Keep your apps clean: one bitness per application.
That's it. Export, delete, re-import. The error vanishes. If you're still stuck after these steps, check the Application Event Log — the source will usually be COM+ Services with more context on what parent is missing. But 9 times out of 10, the re-import does the trick.