Fix COMADMIN_E_CAT_WRONGAPPBITNESS 0x80110484

Quick answer: Open Component Services, right-click the COM+ application, choose Properties, and flip the "32-bit application" checkbox to match the DLL you're registering — or register the DLL from the correct System32/SysWOW64 regsvr32.

I've seen this one bite people at the worst possible time. You've got a legacy line-of-business app that's been humming along since Server 2008, you build a new VM, install everything, and the moment you try to register the component or start the COM+ app you get slammed with COMADMIN_E_CAT_WRONGAPPBITNESS (0x80110484). The cryptic message — "There was a type mismatch between a binary and an application" — doesn't tell you much. What it actually means is straightforward: the COM+ application you created is set to one bitness, and the DLL you're pointing at is the other. A 32-bit COM+ app can only host 32-bit in-proc components, and a 64-bit COM+ app can only host 64-bit ones. Windows refuses to mix them, and honestly that's a good thing — trying to load a 32-bit DLL into a 64-bit host is how you get silent corruption.

The classic trigger I run into: someone registers a DLL from an elevated 64-bit command prompt using plain regsvr32. On a 64-bit Windows box, that invokes the 64-bit regsvr32.exe in C:\Windows\System32. If the DLL was compiled x86 (which most older vendor components were), regsvr32 registers it into the 64-bit COM+ catalog. If you'd already built a 32-bit COM+ application to house it, boom — 0x80110484. Same thing in reverse: you use %windir%\SysWOW64\regsvr32.exe to register a 64-bit DLL and the catalog can't reconcile it.

How to fix it

Figure out the actual bitness of your DLL. Don't guess. Run this in an elevated command prompt:
```
dumpbin /headers "C:\Path\To\Your.dll" | findstr machine
```
You'll see either x86 or x64. If you don't have dumpbin, use corflags for .NET assemblies or grab the free Sigcheck from Sysinternals — sigcheck -a yourdll.dll tells you the machine type too.
Open Component Services. Hit Win+R, type comexp.msc, Enter. Expand Component Services → Computers → My Computer → COM+ Applications.
Right-click your application and open Properties. On the first tab (General), look for the checkbox labeled 32-bit application. That checkbox is the entire ballgame. If your DLL is x86, it must be checked. If x64, it must be unchecked.
Register the DLL with the matching regsvr32. If you're on a 64-bit OS and the DLL is 32-bit, you must call the SysWOW64 version:
```
%windir%\SysWOW64\regsvr32.exe "C:\Path\To\Your.dll"
```
And for a 64-bit DLL:
```
%windir%\System32\regsvr32.exe "C:\Path\To\Your.dll"
```
Yes, the naming is backwards from what you'd expect. SysWOW64 is the 32-bit subsystem. Microsoft has never apologized for this and probably never will.
Rebuild the COM+ application if the checkbox won't stick. Sometimes you've already got components registered that conflict, and the checkbox greys out. In that case, delete the COM+ app entirely, recreate it, set the bitness first, then add components. The catalog validates on add, not on create, which is why people get the error at the wrong step.
Recycle the application. Right-click the app → Shut down, then Start. Don't skip this. The catalog caches bitness info per-process and stale state will keep throwing the error until the process is torn down.

If that doesn't work

Check the 64-bit registry view. A component might be registered under HKLM\SOFTWARE\Classes\CLSID\{...}\InprocServer32 in the 64-bit hive but your COM+ app is looking under Wow6432Node. Open regedit and check both trees for your CLSID. If it's only in one and you need the other, re-register with the opposite regsvr32.
Rebuild the vendor's installer. If the vendor shipped a single MSI that installs both bitnesses, one of the two registration steps is failing silently. Run the MSI with verbose logging: msiexec /i installer.msi /l*v c:\temp\install.log and search the log for 0x80110484. You'll usually see the failing custom action right there.
Move to a 64-bit build of the component. If the vendor has one, use it and rebuild the COM+ app as 64-bit. Mixing bitness across a modern stack is a losing battle — every new Windows update tightens the screws further.

Prevent it next time

When you create a COM+ application in Component Services, set the 32-bit flag before you touch the Components folder. That single order-of-operations change eliminates about 90% of the 0x80110484 errors I've seen in the wild. And keep a note of your DLL's bitness in your build docs — future you will thank present you the next time an app gets migrated to a fresh server.