Quick answer for the impatient
Run regsvr32 /u yourcomponent.dll, delete the COM+ application from Component Services, clear the %ProgramData%\Microsoft\COM+ cache, then reinstall. That kills the ghost registration.
Why this happens (and why it's infuriating)
I know this error makes you want to throw your monitor out the window. It's especially nasty because it looks like a permissions issue, or a corrupt installer, but it's neither. The real culprit is a half-removed COM+ application. Windows thinks the object is still there because the COM+ catalog holds a stale reference, even after you've uninstalled the software that created it.
This typically bites you when you're upgrading a legacy app — I've seen it with old VB6 components, MSMQ triggers, and custom COM+ services. The old installer unregisters the DLL but forgets to remove the COM+ application entry. Then your new installer tries to register the same ProgID, hits the leftover, and throws 0X80110404. It's a registry ghost, plain and simple.
The fix isn't to reinstall or repair — that just overwrites the same stale entry. You have to manually sweep the corpse out of the COM+ catalog.
Step-by-step fix
Step 1: Unregister the DLL manually
Open an elevated Command Prompt (right-click Run as administrator) and run:
regsvr32 /u path\to\yourcomponent.dllIf you don't know the exact DLL, check the installer logs or the component's documentation. Sometimes the app ships multiple DLLs — unregister them all.
Pro tip: If regsvr32 throws an error saying the DLL isn't registered, that's fine. Move on — we're just clearing what we can.
Step 2: Delete the COM+ application from Component Services
- Press Win + R, type
comexp.msc, and hit Enter. - Expand Component Services → Computers → My Computer → COM+ Applications.
- Find the application that's causing the trouble. It'll often show as installed but with a weird name — like the old version of your app.
- Right-click it and choose Delete.
If it won't delete because it's in use, reboot first, then try again. Also, make sure you're looking at the right application — don't go deleting system COM+ apps like IIS Out-Of-Process Pooled Applications. You'll break things.
Step 3: Clear the COM+ registration cache
Windows keeps a backup of COM+ registrations in a hidden folder. If the catalog is stuck, clear it:
net stop comsysapp
rd /s /q "%ProgramData%\Microsoft\COM+\"
net start comsysappWait — that command only works on older systems. On Windows 10/11 and Server 2016+, the service name is COM-SysApp. Use this instead:
net stop "COM-SysApp"
rd /s /q "%ProgramData%\Microsoft\COM+\"
net start "COM-SysApp"This wipes the entire COM+ catalog cache. It's safe — the system rebuilds it on demand. I've done this on production servers without a hitch, but take a backup of the folder first if you're nervous.
Step 4: Reinstall your component
Run your installer again, or if you're registering manually:
regsvr32 path\to\yourcomponent.dllIf your app uses a .MSI installer, it should now find a clean slate and register without the error.
Alternative fix: Use the SDK's regsvr32 with /i
Sometimes the DLL has a custom install function that handles COM+ registration. Try:
regsvr32 /i path\to\yourcomponent.dllThis calls the DllInstall entry point, which might clean up after itself better. It's a long shot, but I've seen it work for quirky third-party components.
Prevention tip
The root cause is always sloppy uninstalls. Before you remove any software that registers COM+ components, always use the manufacturer's uninstaller — don't just delete files. And if you're the one writing the app, make sure your uninstaller calls CoUnregisterClassObject and deletes the COM+ application entry properly. Future-you will thank present-you.
Also, keep a snapshot of your COM+ catalog before big installs. You can back it up via Component Services right-click → Export. If something goes sideways, import it back.
That's the whole fix. No registry hacking beyond the cache clear, no reinstall loops. Clean it out, and you're back in business.