Fix COMADMIN_E_REGISTRY_ACCESSDENIED 0X80110823

What you're dealing with

You're trying to register a COM+ application, or maybe you just fired up the Component Services console and clicked something, and boom — error 0X80110823. The message says "The specified user cannot write to the system registry." That's exactly what's happening. Your user account doesn't have write access to a handful of registry keys that COM+ needs to touch. This isn't a random glitch — it's a permissions problem, and it's fixable in a few minutes.

The fix: grant write permissions on COM+ registry keys

The real fix here is giving your user account (or a specific group) write access to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3 and its subkeys. In some cases, you also need HKEY_CLASSES_ROOT\CLSID and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventSystem. I'll walk you through the exact steps for the most common scenario — a single user on a Windows 10 or Server 2019+ machine.

Press Win + R, type regedit, and hit Enter. If UAC asks, click Yes.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3. This key exists on any machine with COM+ installed (which is basically all modern Windows).
Right-click the COM3 key, select Permissions.
Click Add, type your username or group name (e.g., DOMAIN\YourName or just YourName), then click OK.
In the permissions list for that user, check the box for Full Control (or at minimum Write).
Click Advanced, select the user you just added, then click Edit. In the dropdown that says Applies to, change it from This key only to This key and subkeys. Click OK all the way out.
Repeat steps 2-6 for HKEY_CLASSES_ROOT\CLSID and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventSystem. Yes, you need all three.
Close Regedit. Restart the Component Services console (or restart the machine if you're paranoid).

That's it. Try your COM+ operation again. It'll work.

Why this works

What's actually happening here is that COM+ stores registration data for components in those registry keys. When you install or configure a COM+ application, the system creates entries under COM3 — things like application IDs, class IDs, and interface mappings. The CLSID key under HKEY_CLASSES_ROOT is where the actual class factory pointers live, and the EventSystem key is used by the COM+ Events system (if you're using loosely-coupled events).

The reason step 3 works is that by default, only SYSTEM, Administrators, and TrustedInstaller have write access to those keys. Standard users get read-only. The COM+ runtime checks permissions before writing — it doesn't just fail silently — and throws this specific error code if write is denied. Granting write access to your user bypasses that security check. It's a blunt fix, but it's the intended mechanism: the COM+ admin tools expect the calling user to have permissions.

Less common variations

Sometimes the fix above doesn't cut it. Here are a few edge cases I've seen:

Group Policy overrides: If your organization locks down registry permissions via Group Policy (e.g., a strict security baseline), the keys may revert to restricted permissions hourly. In that case, you need to either add your user to the local Administrators group (the nuclear option) or ask your domain admin to adjust the GPO to allow write on COM3. There's no workaround that bypasses policy — you have to change the policy.
Anti-malware interference: Some security software hooks registry write operations. I've seen CrowdStrike and Carbon Black block COM+ registry writes even when permissions are correct. Temporarily disable the real-time protection for a test. If that fixes it, add an exception for regedit.exe and mmc.exe (the COM+ snap-in host).
WOW64 registry redirection: If you're running a 32-bit COM+ app on a 64-bit Windows, the system redirects writes to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\COM3. That key also needs write permissions. Apply the same fix there — the steps are identical, just the path differs.
Corrupted COM+ catalog: If the above all fail, the COM+ catalog itself might be hosed. Run regsvr32 mscomct2.ocx (for older apps) or use the Component Services snap-in to reinstall COM+ via the COM+ Applications folder. This is rare but happens after a bad uninstall.

Prevention

Once you have this working, lock it down without breaking it again. Don't just leave Full Control open to everyone. Instead, create a local group called COM+ Users, add your service accounts and trusted users to it, and grant that group Write (not Full Control) on the three keys above. This way, new rogue processes can't modify COM+ registrations, but legitimate ones can. If you ever need to revoke access, just remove the user from the group.

Also, on servers, consider running COM+ applications under a dedicated service account (like NT AUTHORITY\NETWORK SERVICE) instead of a domain user. That account already has the necessary registry access on modern Windows — you won't hit this error at all.