Fix COMADMIN_E_CAT_UNACCEPTABLEBITNESS (0x80110483) error

I've seen this error pop up when someone tries to register a 64-bit COM+ component but the installer—or the catalog—insists it's a 32-bit binary. Or you're importing an old component into a 64-bit COM+ application on Windows Server 2019. The system throws COMADMIN_E_CAT_UNACCEPTABLEBITNESS (0x80110483) and says "A binary of unknown or invalid type was provided." It's maddening because the file compiles fine, it's the right architecture, and yet COM+ just won't accept it.

Let's fix it. I'll walk you through three levels—start with the quickest check, then get more aggressive if needed. Stop when the error is gone.

Fix 1: The 30-Second Check (Install Path & File Bitness)

Most of the time, this error is caused by one simple mistake: you're trying to install a 64-bit DLL into a 32-bit COM+ application—or vice versa. COM+ catalogs are bitness-aware, and they reject mismatches.

1. Open Component Services (dcomcnfg).
2. Navigate to Component Services > Computers > My Computer > COM+ Applications.
3. Right-click the application that's failing, choose Properties.
4. Go to the Advanced tab.
5. Look at the Application Bitness field. It will say either 32-bit or 64-bit.
6. Now check your DLL: right-click it in File Explorer, select Properties, then the Details tab. Look for File description or CPU platform. If it says x64, it's 64-bit; x86 or 32-bit is 32-bit.

If they don't match, you've found your problem. You can either:

• Reconfigure the COM+ application to match the bitness of your DLL (change it on the Advanced tab—though this requires deleting and recreating the app sometimes), or
• Recompile your DLL to match the application's bitness.

I've also seen this happen when someone copies a DLL from a 32-bit system to a 64-bit system and tries to register it with regsvr32 into the 64-bit COM+ catalog. That's a guaranteed mismatch. If the bitness matches but you still get the error, move on to Fix 2.

Fix 2: The 5-Minute Fix (CLSID Registration Cleanup)

Sometimes the DLL itself is fine, but the registry has a stale or incorrect CLSID entry pointing to the wrong bitness. Windows caches the bitness from the last registration, and a half-uninstall can leave junk behind.

1. Open Registry Editor (regedit).
2. Back up the registry first—File > Export. Seriously, do it.
3. Navigate to HKEY_CLASSES_ROOT\CLSID\{your-clsid}. The CLSID is usually shown in the COM+ error details, or you can find it by searching for your DLL name under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.
4. Once you find the CLSID folder, look for a REG_SZ value named AppID or InprocServer32 that references your DLL.
5. Right-click the entire CLSID folder and choose Delete. Yes, delete it. You'll re-register it cleanly in a moment.
6. Open an admin Command Prompt. Run cd /d C:\path\to\your\dll.
7. Now re-register the DLL with the correct bitness version of regsvr32. For a 64-bit DLL, use:

%SystemRoot%\System32\regsvr32.exe YourComponent.dll

For a 32-bit DLL on a 64-bit system, use:

%SystemRoot%\SysWOW64\regsvr32.exe YourComponent.dll

After the registration succeeds, go back to Component Services, right-click the COM+ application and choose Refresh. Then try again. If the error persists, it's probably deeper—time for the registry rebuild.

Fix 3: The 15+ Minute Fix (Registry Rebuild for COM+ Catalog)

If none of the above worked, the COM+ catalog itself is corrupted or has old bitness metadata stuck in a lower layer. This happens most often after uninstalling and reinstalling the same component multiple times, or after a failed Windows update that touched COM+ internals.

Step 1: Stop COM+ Services

Open an admin Command Prompt and run these commands one at a time:

net stop COMSysApp
net stop MSDTC
net stop VSS

Step 2: Rename the COM+ Catalog Files

The catalog lives in C:\Windows\System32\Com. You're going to rename the two key files so Windows rebuilds them from scratch on next boot.

ren C:\Windows\System32\Com\*.cob *.cob.old
ren C:\Windows\System32\Com\*.cbr *.cbr.old

If you get a permission denied error, use takeown /f C:\Windows\System32\Com\*.cob then icacls to grant yourself full control. Or boot into Safe Mode, which is simpler.

Step 3: Reboot and Recreate the Application

Restart your computer. Windows will automatically rebuild the COM+ catalog files. Now open Component Services, delete the problem COM+ application (right-click, Delete), then create a new application:

1. Right-click COM+ Applications > New > Application.
2. Choose Create an empty application.
3. Give it a name and set the bitness correctly (64-bit if you're using a 64-bit DLL).
4. Inside the new application, right-click Components > New > Component.
5. Choose Install new component and browse to your DLL.

If it still fails at this point, I'd suspect the DLL itself is not truly 64-bit—maybe it's a mixed-mode assembly or has a native dependency that's 32-bit. Run dumpbin /headers YourComponent.dll from a Visual Studio Developer Command Prompt and check the machine field. It should be x64 (machine 8664) or x86 (machine 14C). If it says unknown or ARM, you've got a deeper compilation problem.

One last thing: I've seen people confuse COM+ with simple COM registration. COM+ requires the binary to be installed through Component Services, not just registered with regsvr32. If you only ran regsvr32 and got this error, try importing the DLL through Component Services instead. That's often the real fix.

You've got this. Start with Fix 1—it's usually the culprit. If not, move down the chain. The catalog rebuild is nuclear, but it works when nothing else does.