Quick answer
Delete the COM+ application from Component Services, then re-register your DLLs using the correct bitness (32-bit or 64-bit) and re-create the COM+ app with matching bitness.
What’s going on here?
This error pops up when you try to register a COM+ application that contains components of mixed bitness. On 64-bit Windows, COM+ runs in either 32-bit or 64-bit mode per application—you can't mix them. I ran into this last month with a client’s print server running Windows Server 2019. They had a legacy 32-bit COM+ DLL that someone tried to drop into a 64-bit COM+ app. Instant 0x80110482.
The real trigger is usually one of two things: you installed a 32-bit COM+ component on a 64-bit OS, or you migrated a COM+ application from a 32-bit system without rebuilding it properly. Either way, Windows sees the mismatch and blocks the app from starting.
Step-by-step fix
1. Open Component Services
Hit Win + R, type dcomcnfg, and press Enter. Expand Component Services > Computers > My Computer > COM+ Applications.
2. Identify the problematic app
Look for the app that won’t start—it'll likely have a red X or a warning icon. Right-click it and select Properties. On the Advanced tab, check the “Application ID” and note the bitness setting (32-bit or 64-bit).
3. Delete the COM+ application
Don't try to fix it in place—just delete it. Right-click the app and choose Delete. Confirm when prompted. This removes the broken configuration but leaves your DLLs on disk.
4. Re-register the DLL with the correct bitness
Open an elevated Command Prompt. If your component is 32-bit, use the 32-bit version of regsvr32 from C:\Windows\SysWOW64\regsvr32.exe. For 64-bit, use C:\Windows\System32\regsvr32.exe. Run:
C:\Windows\SysWOW64\regsvr32.exe "C:\Path\To\YourComponent.dll"
Replace the path with the real DLL location. You should see a success message. If it fails, the DLL itself might be corrupt or missing dependencies—check the Event Viewer for details.
5. Re-create the COM+ application with matching bitness
In Component Services, right-click COM+ Applications and select New > Application. Choose Create an empty application. Give it a name and select the correct bitness on the Activation tab. For 32-bit components, check “Run application as 32-bit on 64-bit computers.” Then add your component via the Components folder: right-click > New > Component > Import component(s) that are already registered. Select your DLL from the list.
6. Test the application
Start the COM+ app by right-clicking it and selecting Start. No red X? You're good. Check the Event Viewer for any residual errors.
Alternative fixes if the main one fails
Use the COM+ admin tool from command line
If the GUI is flaky—happened to me on a heavily patched Server 2012 box—use COMAdmin.COMAdminCatalog via PowerShell:
$cat = New-Object -ComObject COMAdmin.COMAdminCatalog
$cat.Connect("localhost")
$cat.GetCollection("Applications") | Where-Object {$_.Name -eq "YourAppName"} | ForEach-Object {$cat.RemoveApplication($_.Key)}
Then re-register and re-create as above.
Check for orphaned registry entries
After deleting the app, sometimes registry keys linger. Open Regedit and navigate to HKEY_CLASSES_ROOT\AppID and HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID. Look for your app's GUID—if the app is gone, delete the key. Back up first.
Rebuild the DLL if it's 32-bit and you need 64-bit
If the DLL source is available, recompile it as 64-bit. No source? Then you're stuck running it in a 32-bit COM+ app. Don't try to force a 32-bit DLL into a 64-bit app with registry hacks—it won't work and can break other COM+ apps.
How to prevent this from happening again
Always check the bitness of any COM+ component before deploying. Label your DLLs clearly: “MyComponent_x86.dll” and “MyComponent_x64.dll”. When you set up a new COM+ app, explicitly set the bitness on the Activation tab—don't leave it at default. If you're migrating from a 32-bit server, rebuild the COM+ app from scratch on the 64-bit box rather than exporting and importing. Exporting often carries over the old bitness flags, and you'll end up right back at 0x80110482. I've seen that exact mistake three times in the last year—save yourself the headache.
Also, keep a log of which DLLs are registered and with which bitness. A simple text file or spreadsheet saves hours when something goes sideways. Most IT pros skip this until they're digging through Event Viewer at 2 AM. Don't be that guy.