COMADMIN_E_COMPFILE_GETCLASSOBJ (0X80110426) Fix

When This Error Shows Up

You're in the Component Services snap-in, trying to add a new COM+ application or install a pre-built package. The install wizard runs, then stops dead with COMADMIN_E_COMPFILE_GETCLASSOBJ (0X80110426) — GetClassObject failed in the DLL. This happens most often with older C++ COM components built with Visual Studio 6 or 2005, or with third-party DLLs that aren't properly self-registering. I've seen it on Windows Server 2019 and Windows 10 22H2 after moving a component from an older server.

What's Actually Happening

COM+ doesn't just copy a DLL — it asks the DLL to expose its class objects via DllGetClassObject. That function is the entry point COM uses to get pointers to class factories. If the DLL can't return a valid class object for any reason, you get this error. The reasons are usually one of three things:

• The DLL isn't properly registered with regsvr32 first.
• The DLL depends on a runtime DLL (like MSVCRT, MFC, or ATL) that's missing or the wrong version.
• The DLL itself is corrupt or wasn't built for the current architecture (x86 vs x64 mismatch).

Note the exact wording — it says "in the DLL," not "by COM+". That means the failure happened inside the DLL's own code. COM+ handed off the request and the DLL dropped it.

The Fix

Step 1: Register the DLL with regsvr32

Open an elevated command prompt (Run as Administrator). Navigate to the directory containing the DLL. Then run:

regsvr32 YourComponent.dll

If regsvr32 succeeds with a popup saying "DllRegisterServer succeeded," move to Step 2. If it fails, note the error code. A common one is 0x8002801c (error accessing registry) — that means the process doesn't have admin rights, or the DLL is trying to write to a registry key it can't touch. A missing runtime dependency gives 0x80070715 ("The DLL 'MSVCR80.dll' could not be found").

You must get regsvr32 to pass before COM+ will work. That's non-negotiable.

Step 2: Check Runtime Dependencies

The biggest hidden culprit is Visual C++ redistributables. A DLL built with VS 2005 needs the VC++ 2005 redistributable (x86 or x64, matching the DLL's architecture). VS 2008 needs 2008, 2010 needs 2010, and so on. These don't always install by default on newer Windows versions.

To check what your DLL needs, use Dependency Walker (depends.exe) from the Windows SDK, or Dependencies (the modern replacement, available on GitHub). Load the DLL and look for missing modules marked with a yellow exclamation. If you see entries like MSVCR80.dll, MFC80U.dll, or ATL80.dll missing, install the matching Visual C++ redistributable package.

Step 3: Retry the COM+ Install

After you confirm regsvr32 works and dependencies are satisfied, go back to Component Services. Right-click "COM+ Applications" → New → Application. Choose "Install pre-built application" and point it to the same DLL or the .MSI package. If the DLL is already registered correctly, the install should proceed past the GetClassObject check.

Step 4: If Still Fails — Use the Command Line

Sometimes the GUI wizard trips over permissions or cached state. Try the command-line approach with regsvcs.exe (the .NET Services Installation Tool). Run this from an elevated prompt:

regsvcs YourComponent.dll

regsvcs will attempt to register the assembly with COM+ directly. If it succeeds, the error's root was likely a stale COM+ catalog entry. If it fails with a similar error, you have a deeper problem with the DLL's DllGetClassObject implementation itself — possibly the component's threading model (Apartment vs Free) conflicts with COM+ expectations.

What to Check If It Still Fails

If none of the above works, you're looking at a code-level issue. Here's what I'd check:

• Architecture mismatch: A 32-bit DLL cannot be registered in a 64-bit COM+ application, and vice versa. Check the application's properties in Component Services — it'll say "32-bit only" or "64-bit only." Use dumpbin /headers YourComponent.dll to see the DLL's machine type (x86 or x64).
• Corrupt COM+ catalog: Rare but happens. Reset the COM+ catalog by running regsvr32 /u comsvcs.dll then regsvr32 comsvcs.dll from an elevated prompt. This re-registers the COM+ system files without affecting your component registrations.
• Antivirus interference: I've seen endpoint protection (especially McAfee and Symantec) block the in-process COM call because it looks like a DLL injection attempt. Temporarily disable real-time scanning, try the registration, then re-enable it.
• Event Viewer clues: Open Event Viewer → Windows Logs → Application. Look for errors from source "COM+" around the time you attempted the install. The details often contain the exact HRESULT and the module path that failed.

One last thing — if you're trying to install a .NET assembly into COM+, you shouldn't be using the old COM+ wizard at all. Use regsvcs.exe or the System.EnterpriseServices API directly. The classic COM+ install path doesn't handle .NET assemblies gracefully, and you'll see this error as a false positive.