COMADMIN_E_SYSTEMAPP 0x80110433: Fix the System App Lockout

You're trying to tweak the COM+ System Application in Component Services (dcomcnfg.exe) — maybe to change identity, add a role, or adjust the activation type — and you get slapped with COMADMIN_E_SYSTEMAPP: 0X80110433. This usually happens when you're logged in as a standard user or even a local admin, but not as a member of the Administrators group on the machine. I've seen it most often on Windows 10 Pro and Server 2016/2019, right after a quick 'repair' of a third-party installer that decided to mess with the COM+ catalog.

What's actually happening here is that the COM+ System Application is a protected, system-owned object. The Component Services snap-in checks your token against the ACL of that specific application before letting you do anything. If you're not elevated or missing the right group membership, the COM+ infrastructure refuses the operation — not because the operation is invalid, but because it can't verify you're allowed to touch it.

The fix is straightforward: run Component Services with full elevation and make sure you're in the right group. But there's a twist — sometimes even an elevated admin hits this because the SYSTEM account's permissions have been stripped. Let's handle both cases.

Why This Error Won't Go Away If You Just Re-run as Admin

If you're already an admin and still see 0x80110433, the problem is that the System Application's ACL has been modified — either by a misbehaving MDM policy or by a previous cleanup script that over-privileged or under-privileged it. The default ACL grants LOCAL SYSTEM and Administrators full control. When that's missing or overwritten, even a legit admin gets locked out.

So step one is to verify and repair the ACL. Then restart the COM+ System Application service (it's actually a service named COMSysApp), because COM+ caches security descriptors.

The Fix, Step by Step

1. Start Component Services elevated. Hit Win, type dcomcnfg, right-click it, and choose Run as administrator. If you're not a local admin, you'll need to add yourself to the Administrators group first (or get someone who is).
2. Navigate to the System Application. Go to Component Services → Computers → My Computer → COM+ Applications. Right-click System Application and select Properties.
3. Check the Security tab. If you can get in, you're done — the error won't appear anymore because you're now elevated. But if you still get the error, proceed to step 4.
4. Repair the ACL using the command line. Open an elevated Command Prompt (or PowerShell) and run these commands to reset the COM+ catalog permissions. The first one restores the default DACL on the registry key that stores the catalog, and the second restarts the service that reads it.

# Reset the COM+ catalog ACL (run as admin)
sc config COMSysApp start= demand
sc stop COMSysApp
sc start COMSysApp

# If that doesn't fix it, forcibly reset the registry key permissions
regini \"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\REGDB\Applications\{1E2E5C00-...}\"  # replace with the actual GUID of System App

But that GUID is a pain to find. The easier route is to use the COM+ catalog dump tool. Actually, the cleanest fix is to delete and re-register the System Application. Don't worry — it's not a user app; it's a built-in component that Windows will recreate automatically.

# Delete and re-register the COM+ System Application (run as admin)
cd /d %windir%\system32\com
regsvr32 /s comsvcs.dll
regsvr32 /s coloader.dll
net stop COMSysApp
net start COMSysApp

The reason step 3 and 4 work is that re-registering comsvcs.dll rebuilds the COM+ catalog entries, including the System Application's security descriptor. The service restart then forces COM+ to re-read that descriptor instead of using a stale cached copy.

If It Still Fails: Check UAC and Local Security Policy

You've done the re-registration, restarted the service, and the error persists. What you're looking at now is a UAC knee-cap or a local security policy that's stripping your token. Here's what to check:

• UAC is set to 'Always Notify'? That's fine, but make sure you're truly elevating — double-click dcomcnfg with a right-click 'Run as administrator', not just double-clicking it. If you're on Server Core, you don't have UAC, but you still need to be in the Administrators group.
• Local Security Policy → User Rights Assignment — ensure your account (or your group) has “Impersonate a client after authentication” and “Adjust memory quotas for a process”. These are common in COM+ scenarios. Without them, COM+ won't let you do anything because it can't impersonate you.
• Check the Component Services log. Open Event Viewer → Applications and Services Logs → Microsoft → Windows → COM+ → Operational. Look for event IDs 4097 or 4098 that might give a more specific sub-error.
• Last resort: use a local account. If you're on a domain, sometimes the domain's default security policy blocks the required privilege. Log in with a local admin account and test — if it works there, the problem is your domain policy, not COM+.

One more thing — if you're automating this via PowerShell and New-Object -ComObject COMAdmin.COMAdminCatalog throws 0x80110433, the same elevation rules apply. Run your script in an elevated shell, and issue Start-Process powershell -Verb RunAs if you're not already elevated.

That's the whole ballgame. The error is rarely a broken COM+ system; it's almost always a permissions or elevation mismatch. Fix that, and the System Application opens right up.