COMADMIN_E_NOTINREGISTRY (0x8011043E) – COM+ object missing from registry

When you'll see this error

You're administering a COM+ application through Component Services (dcomcnfg), or deploying one programmatically. You attempt to start the application, add a component, or run a client that calls into it. The system throws COMADMIN_E_NOTINREGISTRY (0x8011043E) with the message: "Object was not found in registry."

This shows up most often on Windows Server 2016, 2019, or 2022 after a DLL was replaced, an update was rolled out, or a COM+ application was exported and imported between machines. It's less common on Windows 10/11, but you'll hit it when developing COM components locally.

What's actually happening here

COM+ keeps its own database called the COM+ catalog (stored at %windir%\registration\clbcatq.dll and accompanying CLB files). This catalog stores references to COM classes, interfaces, and methods. When you add a component from a DLL to a COM+ application, the system looks up the CLSID (class identifier) and ProgID in the standard Windows registry under HKEY_CLASSES_ROOT\CLSID\{...}.

The error 0x8011043E means the CLSID you're trying to use–or the CLSID that an existing component references–doesn't exist in the registry. The DLL itself may be present on disk, but regsvr32 was never called (or failed silently). Or someone unregistered the DLL. Or the original COM+ export package included a component that was registered on the source machine but not on the target.

The root cause is always the same: a mismatch between what COM+ expects to find in the registry and what's actually there. COM+ doesn't check if the DLL file exists–it checks if the CLSID and its InprocServer32 path are present and point to a valid file.

The fix: re-register the DLL or rebuild the application

Skip the wild goose chase of hunting through the COM+ catalog internals. Do one of these two things depending on your situation.

Option 1: Re-register the component DLL

1. Open an elevated Command Prompt (Run as Administrator).
2. Run: regsvr32 /u "C:\full\path\to\your.dll" – this unregisters it cleanly, even if it's not registered yet. It removes any stale entries.
3. Then run: regsvr32 "C:\full\path\to\your.dll" – this re-registers the DLL and writes the CLSID, ProgID, and all interface entries into the registry.
4. Open Component Services (dcomcnfg.exe), navigate to Component Services > Computers > My Computer > COM+ Applications, right-click your application and select Shut down (if running), then right-click again and choose Start.

The reason step 3 works is that regsvr32 calls the DllRegisterServer export inside your DLL, which writes the exact CLSID entries COM+ needs. If you just copied the DLL over, those entries are missing. If the DLL doesn't export DllRegisterServer (unusual but possible for some older COM components), then Option 2 is your only path.

Option 2: Remove and re-add the component to the COM+ application

This is the right fix when the DLL is already registered but the COM+ application was imported from another machine and its internal component list is broken.

1. In Component Services, find your COM+ application, expand it, then expand Components.
2. Right-click each component that shows a gray icon (disabled) or that you suspect is broken, and select Remove.
3. Right-click Components, choose New > Component.
4. Select Install new component, browse to the DLL, and add it.
5. Restart the COM+ application.

This forces COM+ to re-read the component's registration from the registry and rebuild its internal catalog entry. It also validates that the DLL is actually present and loadable.

If it still fails after these steps

Three more things to check:

• DLL bitness mismatch: If your COM+ application runs as a 64-bit process, it can't load a 32-bit DLL, and vice versa. The error message won't tell you this directly, but the CLSID will be present in the registry under the wrong bitness key. Check HKEY_CLASSES_ROOT\CLSID\{your-clsid}\InprocServer32 – the default value should point to the DLL. If it's a 32-bit DLL on a 64-bit system, you'll find it under Wow6432Node instead, and COM+ won't see it.
• DLL dependencies: The DLL might depend on Visual C++ redistributables or other runtime libraries that are missing. Use Dependency Walker or Dependencies (the open-source one) to check. If a dependency is missing, regsvr32 will fail silently or return an error about entry point not found.
• Permissions: The COM+ application runs under a specific identity (e.g., Interactive User, Network Service, or a custom account). That account needs read+execute access to the DLL's folder. Check the folder NTFS permissions.

If none of this helps, consider deleting the COM+ application entirely and recreating it from scratch. Export the working application from a known-good machine as a .MSI file (right-click on the application > Export > Application proxy or Application), but be aware that this carries the same registry dependency. The cleanest approach is to document every DLL and its registration status, then rebuild manually on the target server.