CO_E_CLSREG_INCONSISTENT (0x8000401F) fix on Windows Server

You're staring at that 0x8000401F error and the message "The registration information for this server is inconsistent or incomplete" — yeah, it's annoying because it usually kills some random COM-dependent service or app. Let's get it sorted.

The fix: rebuild the COM+ catalog

What's actually happening here is the COM+ catalog database got corrupted or your COM+ registration entries are out of sync. The catalog lives in %SystemRoot%\Registration\ as a set of files named *.clb. When those get mangled — bad shutdown, failed update, or a botched COM component install — COM+ can't resolve class IDs anymore. The fix is to nuke and rebuild that catalog.

1. Open an elevated Command Prompt — right-click CMD and pick Run as administrator.
2. Stop the COM+ services with:
   

   net stop comsysapp
   net stop comadmin
   net stop eventsystem

3. Rename the catalog folder (don't delete it yet — safety net):
   

   ren %SystemRoot%\Registration Registration.old

4. Restart the services — they'll recreate the folder and a fresh catalog automatically:
   

   net start eventsystem
   net start comadmin
   net start comsysapp

5. Re-register the core COM+ DLLs:
   

   regsvr32 /s comadmin.dll
   regsvr32 /s comsvcs.dll
   regsvr32 /s colbact.dll
   regsvr32 /s mtxclu.dll
   regsvr32 /s mtxex.dll
   regsvr32 /s mtxoci.dll
   regsvr32 /s clbcatq.dll

6. Reboot the server — I know, feels old-school, but COM+ caches a ton of state per boot cycle.

After reboot, your error should be gone. Test whatever component or app was throwing the error.

Why this works

The COM+ catalog is a set of binary .clb files — think of them as a local database that maps CLSIDs to implementation details (DLL paths, threading models, security settings). When one of those files gets corrupt, the COM runtime can't find the matching registration for a class, so it spits back CO_E_CLSREG_INCONSISTENT. By renaming the folder, you force the COM+ subsystem to regenerate those files from scratch using the registry keys under HKCR\CLSID and HKLM\SOFTWARE\Microsoft\COM3. The clbcatq.dll re-registration is the key step — it's the catalog manager that actually writes the fresh .clb files. Without it, you'd just get the same corrupt state after reboot.

When the standard fix doesn't stick

Sometimes the error persists even after a catalog rebuild. Here are the less common variations:

Corrupted registry CLSID entries

A specific COM component has its registry entry mangled — maybe a bad uninstall left orphaned references. Check HKCR\CLSID\{your-GUID} for missing InprocServer32 or LocalServer32 keys. Also look under HKLM\SOFTWARE\Classes\CLSID. If you find a GUID that points to a DLL that doesn't exist, that's your culprit. Unregister and re-register the component's DLL:

regsvr32 /u path\to\bad.dll
regsvr32 path\to\good.dll

DCOM launch permission corruption

If the error comes from a DCOM activation (like a remote WMI call or a scheduled task), the catalog might be fine but the DCOM launch permissions under HKLM\SOFTWARE\Microsoft\Ole\DefaultLaunchPermission got reset or corrupted. Use dcomcnfg — go to Component Services > Computers > right-click My Computer > Properties > COM Security tab. Click Edit Default under Launch and Activation Permissions. Ensure LOCAL SERVICE, NETWORK SERVICE, and Administrators have local launch permissions. If not, add them.

Windows Update broke COM+

I've seen this after a .NET Framework or a security-patch rollback that left COM+ registration in a half-applied state. Run sfc /scannow first, then dism /online /cleanup-image /restorehealth. Then re-run the catalog rebuild above. If that fails, uninstall the problematic update via wusa /uninstall /kb:xxxxx.

How to keep it from coming back

Back up your COM+ catalog after you get it working. Use the built-in COM+ Export tool:

%windir%\system32\dcomcnfg.exe

Inside Component Services, right-click your COM+ applications folder and pick Export. Save as an .MSI file. Keep that backup in a safe place.

Also, avoid killing the svchost.exe host process that runs COM+ — it's often the culprit when someone force-kills tasks via Task Manager. Use tasklist /svc to see which svchost hosts comadmin or eventsystem before terminating anything.

One more thing: if you're running Hyper-V or SQL Server on the same machine, they depend on COM+ for management tools. Rebuilding the catalog will nuke custom COM+ applications you've installed — but it won't touch system components. Always export your custom apps before a rebuild.