What's going on here
The error COMADMIN_E_PRIVATE_ACCESSDENIED (0X80110821) pops up when you try to register or view a COM+ component that's flagged as private. Private components can only be seen or modified by the user who created them. If you're logged in as a different user — or the registration got corrupted — you'll get this exact error.
I've seen this most often after a botched software install or when someone ran a script that registered a COM+ component under their own user instead of SYSTEM. It's also common after migrating a COM+ application from an old server. The fix is straightforward, but you need to work through these steps in order.
Step 1: The 30-second fix — Run Component Services as admin
Half the time, this is all it takes. Windows sometimes caches permissions wrong, or your current session doesn't have the elevation you think it does.
- Close any open Component Services windows.
- Hit Win+R, type
dcomcnfg— but don't hit Enter yet. - Hold Ctrl+Shift and press Enter to launch it as Administrator. Click Yes on the UAC prompt.
- Navigate to Component Services > Computers > My Computer > COM+ Applications.
- Find your application. Right-click it and select Properties. If it opens, you're golden — the error was just a permission hiccup.
If you still get the error, move to Step 2.
Step 2: The 5-minute fix — Delete and re-register the private component
The component is stuck as private under a user that no longer exists or a session that's gone. You'll nuke the bad entry and start fresh.
- Open an admin Command Prompt (or PowerShell as admin).
- Type
dcomcnfgand press Enter — yes, this opens the same Component Services, but now from an elevated context. - In the left pane, expand Component Services > Computers > My Computer > COM+ Applications.
- Look for the application that's throwing the error. It might have a red X or a funky icon.
- Right-click it and choose Delete. Confirm the prompt.
- Now re-register the component. If it's a DLL, run
regsvr32 C:\path\to\your.dllfrom the same admin Command Prompt. - Go back to Component Services, right-click COM+ Applications, and select New > Application. Follow the wizard to install the pre-built application or import the MSI.
If you can't delete it because of the same error, you'll need to go nuclear — Step 3.
Step 3: The 15-minute fix — Wipe the COM+ catalog
This is the sledgehammer. It resets all COM+ applications, so only do this if Steps 1 and 2 failed. You'll need to reinstall any custom COM+ apps afterward.
Backup first (paranoid mode)
Open an admin Command Prompt and export the current COM+ catalog:
reg export HKLM\SOFTWARE\Microsoft\COM3 C:\com3_backup.regThis saves all COM+ registrations. Keep it safe for 30 days, then you can delete it.
Nuke the catalog
- Stop the COM+ services:
net stop COMSysApp
net stop MSDTC- Delete the COM+ registry key:
reg delete HKLM\SOFTWARE\Microsoft\COM3 /f- Restart the services:
net start MSDTC
net start COMSysAppWait 10 seconds after starting MSDTC before starting COMSysApp — they have a dependency order.
Rebuild the default applications
Open Component Services as admin (like Step 1). You'll see an empty COM+ Applications folder. Right-click COM+ Applications, choose New > Application, and create the default System Application if it's missing. Then reinstall any third-party COM+ apps from their original installers.
This almost always fixes the error. If it doesn't, you're looking at a corrupted OS or a deeply broken component — might be faster to restore from a backup or rebuild the machine.
Quick reference table
| Step | What you do | Time | Success rate |
|---|---|---|---|
| 1 | Run Component Services as admin | 30 sec | ~50% |
| 2 | Delete and re-register the component | 5 min | ~80% |
| 3 | Wipe and rebuild COM+ catalog | 15 min | ~95% |
What causes this in the real world
Most common scenario: you install an application that registers a COM+ component under the LOCAL_SYSTEM account, then later you log in as a domain user and try to manage it. Windows says "nope, that's private to SYSTEM." Another common trigger: copying a COM+ application from an old Server 2012 R2 box to a Server 2019 box without using the export/import tools — the ACLs get scrambled.
Don't bother trying to manually edit the COM+ security descriptors with dcomperm or oleview.exe — it rarely helps and often makes things worse. Stick to the three steps above.
Pro tip: If you're on a domain, run Component Services under the Domain Admin account, not a local admin. Domain Admins have implicit rights to COM+ objects that local admins sometimes lack due to UAC filtering.