COMADMIN_E_BADREGISTRYLIBID (0X8011041E) Fix

Quick answer

Delete the orphaned TypeLib registry key that COM+ points to — use OLEView to find it, then regedit to nuke it. Then reboot.

Why this happens

You're seeing COMADMIN_E_BADREGISTRYLIBID (0X8011041E) when you try to configure a COM+ application in Component Services. What's actually happening here is COM+ is looking up a TypeLib ID (LIBID) in the registry — specifically under HKEY_CLASSES_ROOT\TypeLib\{GUID} — and it either can't find that GUID, or the key exists but points to a missing DLL. The most common trigger is uninstalling an application that left its COM registration behind, or a partially botched install of something like an older Microsoft Office version, SQL Server, or a custom COM server component. The COM+ catalog doesn't validate these at registration time — it only complains when you actually try to use the component.

How to fix it — numbered steps

1. Identify the broken LIBID. Open Component Services (dcomcnfg), expand Component Services > Computers > My Computer > COM+ Applications. Find the application throwing the error. Right-click it, choose Properties, go to the Components tab. The error message usually lists the GUID in the format {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Write that down.
2. Check if the TypeLib key exists. Open Regedit (regedit). Navigate to HKEY_CLASSES_ROOT\TypeLib\{GUID} where {GUID} is the one from step 1. If the key is missing entirely, that's your problem. If it exists but the default value or child keys point to a DLL that doesn't exist on disk, that's also the problem.
3. If the key is missing: You can't just make one up — COM+ needs the full TypeLib registration. Instead, you can re-register the original component that installed it. Look at the COM+ application's DLL path (check the Components tab, or dig into HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID}\InprocServer32 if you have a CLSID). Once you find the DLL, run regsvr32 \"C:\path\to\that\component.dll\" as Administrator. That should recreate the TypeLib key.
4. If the key exists but is pointing to nothing: The safest fix is to delete the entire TypeLib GUID key. Yes, delete it. COM+ won't break because the component was already orphaned — it was never going to load anyway. Right-click the {GUID} key under HKEY_CLASSES_ROOT\TypeLib\ and choose Delete. Confirm.
5. Reboot. This forces COM+ to re-read the registry. After the restart, open Component Services again and try to view the application's properties. The error should be gone.

Alternative fixes if the main one fails

• Use OLEView (part of the Windows SDK, or download the \"OLEView .NET\" tool). It shows every registered TypeLib with a green checkmark or red X. Find the broken one, right-click, and choose Remove. That's cleaner than regedit for this.
• Reinstall the COM+ application. If you know what installed it — say a third-party software — run its installer in repair mode. This often replaces the missing TypeLib registration.
• Reset COM+ catalog as last resort. Run regsvr32 /i comsvcs.dll from an elevated command prompt, then reboot. This rebuilds the entire COM+ catalog from scratch — but it wipes all custom COM+ applications. Back up your COM+ apps first using the Component Services export feature.

Prevention tip

Before uninstalling any software that uses COM+ (like SQL Server, Exchange, or custom enterprise apps), export the COM+ application from Component Services. Right-click the app, choose Export, select \"Application Proxy\" — that saves a .msi you can reinstall if the uninstaller botches the TypeLib. Also, don't let uninstallers \"clean\" the registry automatically. Uncheck any registry-cleaning options they offer — those tools often strip TypeLib keys that other apps still reference.