CO_E_EXCEEDSYSACLLIMIT (0X80010139): ACE Limit Fix

Too Many ACEs in a DCOM or Registry ACL

I've seen this one a lot in enterprise setups—especially after someone gets overzealous with DCOM permissions. The error 0x80010139 fires when Windows hits a hard limit: 1,024 access control entries (ACEs) in a single ACL. Most ACLs stay well under 100. If you're here, something went sideways.

This usually happens when a script or admin tool adds inheritable permissions under a COM object or registry key repeatedly. Each time you grant or deny a permission for a user or group, you add an ACE. Do that 1,024 times and boom—this error appears when you try to launch or configure a COM+ application or DCOM component.

Don't waste time rebuilding the COM object. The fix is surgical: find the bloated ACL, trim it, and you're back in business.

Step 1: Identify the Offending Object

You'll need to know which COM or registry key is the culprit. Check the event log under Windows Logs > System for source DCOM or Microsoft-Windows-DistributedCOM. Look for an event with the error 0x80010139. It often shows the CLSID or AppID. Write that down. If the event log is sparse, run dcomcnfg, expand Component Services > Computers > My Computer > DCOM Config. Find the app that fails to launch—usually the one you just tried to start.

Step 2: Check the ACL Count

Open PowerShell as admin and run this, replacing YourAppID with the actual AppID from the event log or dcomcnfg:

$path = 'HKLM:\SOFTWARE\Classes\AppID\{YourAppID}'
$acl = Get-Acl $path
$acl.GetSecurityDescriptorSddlForm('Access')

The SDDL string shows the ACL after D:. Count the A; entries—that's your ACE count. If it's near 1,024, you've found the problem.

Step 3: Trim the ACL

The real fix is removing duplicate or unnecessary ACEs. Don't delete the whole ACL—that breaks the COM app. Instead, use Set-Acl with a cleaned list. First, get the current Acl object:

$acl = Get-Acl $path
$currentRules = $acl.Access

Now filter out rules that are duplicates or for users/groups that no longer exist. For example, remove all rules for Everyone except the minimum needed. Then apply:

$newAcl = New-Object System.Security.AccessControl.RegistrySecurity
$currentRules | Where-Object { $_.IdentityReference -notlike '*BUILTIN\*' -and $_.IdentityReference -notlike '*NT AUTHORITY\*' } | ForEach-Object {
    $newAcl.AddAccessRule($_)
}
Set-Acl -Path $path -AclObject $newAcl

This strips out built-in accounts that you probably don't need. Adjust as needed. Reboot or restart the COM+ service for changes to take effect.

Registry Key Inheritance Goes Wild

Second most common cause: a registry key under HKLM\SOFTWARE\Classes\CLSID has inheritance enabled, and some parent key added hundreds of ACEs that trickled down. Each subkey inherits them, so even if the parent is fine, the child keys get overloaded.

Check the inheritance flag on the registry key in question. Open regedit, right-click the key, choose Permissions > Advanced. Look at the Inherited from column. If you see many entries from parent keys, that's your issue. To fix: uncheck Include inheritable permissions from this object's parent. Click Convert inherited permissions into explicit permissions on this object—this makes them explicit so you can edit them. Then remove duplicate or redundant ACEs manually, or use the PowerShell approach above.

Software Installers That Add ACEs Repeatedly

I've seen antivirus or security software (looking at you, old McAfee and Symantec versions) add ACEs to the DCOM ACL every time they update. Same with VPN clients that register custom COM objects. Each update adds, never removes. Over months, the count climbs. If you recently installed or updated security software, check if it's the source. Uninstall it temporarily, reboot, and see if the error clears. If yes, update to the latest version—they often fix this. If not, roll back to the previous version or contact the vendor.

Quick-Reference Summary Table

That's it. No need to nuke the system. Find the bloated ACL, trim it, and you're done. If you hit this again, it's probably the same app—so tighten your change control on that one.