CO_E_FAILEDTOSETDACL (0X80010129) Fix: Can't Set ACL on Security Descriptor

You're running a COM registration script or using a tool like DCOMCNFG to tweak permissions, and boom — you get CO_E_FAILEDTOSETDACL (0x80010129). The exact message reads: "Unable to set a discretionary access control list (ACL) into a security descriptor." I've seen this most often when someone tries to grant or revoke permissions on a COM+ application or a system service, especially after a Windows update or a permissions cleanup gone wrong. Another common trigger: running a PowerShell script that modifies security descriptors on registry keys under HKLM\SOFTWARE\Microsoft\Ole or HKCR\AppID.

What Actually Causes 0x80010129?

Here's the plain-English explanation. Every security descriptor in Windows has a DACL — that's the list of who can do what. The DACL itself has a control flag that tells the system whether it's "protected" or not. When you get this error, Windows is refusing to write your new DACL because the descriptor's control flags are set in a way that conflicts with what you're trying to do. Specifically, the SEF_DACL_PROTECTED flag is often set on the descriptor, meaning it won't inherit permissions from its parent, but also it won't allow direct replacement unless you explicitly tell it to override that flag. Or the DACL is present but empty, which is treated differently than a null DACL.

The real fix is to make sure you're writing the DACL in a way that matches the existing descriptor's flags. You can't just blast a new ACL onto a protected descriptor without unprotecting it first. Microsoft's SetSecurityDescriptorDacl API call fails because the descriptor's control bits conflict with the requested operation.

Step-by-Step Fixes for 0x80010129

Skip the simple restart — that won't help here. The issue is in the registry or COM configuration, not a transient glitch. You need to edit security descriptors directly. I'll give you two methods. Start with Method 1 because it fixes 90% of cases.

Method 1: Fix the Registry Key's Security Descriptor (Most Common)

1. Open Regedit as Administrator. Press Windows+R, type regedit, right-click the result, and select "Run as administrator." Accept the UAC prompt.
2. Navigate to the COM AppID key that's causing the error. The error usually points you to a specific CLSID or AppID. For example, if it's a COM+ application, look under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{your-GUID}. If no GUID is given, the most common culprit is the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole key. Right-click that key and select Permissions.
3. Check the current owner. In the Permissions dialog, click Advanced. Look at the Owner field. If it's not SYSTEM or Administrators, click Change, type SYSTEM into the box, click Check Names, then OK. Apply this change.
4. Enable inheritance (if it's disabled). In the same Advanced Security Settings window, look for a button that says Enable inheritance. Click it. You should see permissions from the parent key appear. Click Apply. After clicking Apply you should see a brief progress bar and the permission list update to include inherited entries.
5. Add a full control entry for SYSTEM and Administrators. Click Add, then Select a principal. Type SYSTEM, click OK. Under Basic permissions, check Full Control. Repeat for Administrators. Also add Everyone with Read permission (not Full Control). Click OK on all windows to save.
6. Test the original operation. Try running your script or tool again. If the error still appears, move to Method 2.

Method 2: Use PowerShell to Unprotect and Set the DACL Manually

When the registry fix doesn't work, the descriptor is likely protected at a deeper level — probably in the COM+ catalog or a custom service. You need to use the SetSecurityDescriptor method from .NET or WMI. Here's a PowerShell script that does the job cleanly.

# Run PowerShell as Administrator
$path = "HKLM:\SOFTWARE\Microsoft\Ole"
$acl = Get-Acl -Path $path

# Unprotect the DACL so we can replace it
$acl.SetAccessRuleProtection($false, $true)

# Create a new access rule: SYSTEM Full Control, Administrators Full Control
$rule1 = New-Object System.Security.AccessControl.RegistryAccessRule(
    "SYSTEM", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$rule2 = New-Object System.Security.AccessControl.RegistryAccessRule(
    "Administrators", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")

# Remove all existing rules and add our new ones
$acl.SetAccessRule($rule1)
$acl.SetAccessRule($rule2)

# Apply the ACL back to the registry key
Set-Acl -Path $path -AclObject $acl

# Verify
Get-Acl -Path $path | Format-List

After running this script, you should see the ACL output showing SYSTEM and Administrators with FullControl. Now try your original operation again.

Method 3: Reset COM+ Security Defaults (Last Resort)

If neither method works, you've probably got a corrupted COM+ security descriptor. You can reset the entire COM security configuration, but it's drastic — it'll reset all your custom DCOM settings.

1. Open Component Services. Press Windows+R, type dcomcnfg, press Enter.
2. Expand Component Services -> Computers -> right-click My Computer -> select Properties.
3. Go to the COM Security tab. Under Access Permissions, click Edit Default. Under Launch and Activation Permissions, click Edit Default. Make sure SYSTEM, Administrators, and INTERACTIVE have appropriate permissions (usually Allow for all).
4. Click OK on all dialogs. Close Component Services.
5. Reboot the computer. After reboot, the default ACLs should be restored.

What If It Still Fails?

If you've done all three methods and the error persists, check for these edge cases:

• Antivirus interference. Temporarily disable real-time protection and test again. Some security software hooks into the security descriptor APIs and blocks changes.
• Corrupted Windows security descriptor cache. Run sfc /scannow from an admin command prompt, then DISM /Online /Cleanup-Image /RestoreHealth. Reboot and try again.
• Group Policy restrictions. If you're on a domain-joined machine, a Group Policy might be locking down the COM permissions. Run gpresult /h gp.html and look for policies under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options that mention "DCOM" or "COM." Ask your domain admin to relax those policies.
• The descriptor is for a non-registry object. If the error comes from a custom application or a service, you might need to use the SetSecurityInfo API directly. Contact the application vendor for that case.

The fix for 0x80010129 is usually Method 1 — adjust the registry key permissions and enable inheritance. Take it slow, double-check each step, and you'll have it sorted in ten minutes.