STATUS_INVALID_ACE_CONDITION (0XC00001A2) Fix: Bad ACE Condition

Quick answer for advanced users

Open regedit or explorer on the affected path, locate the object with the bad ACE, and use icacls with /remove or /setowner to strip the invalid condition. If that fails, restore the default ACL via secedit or group policy reset.

What's actually happening here

I see this error mostly on Windows 10/11 systems where someone messed with advanced security settings—either manually in the GUI, through a buggy third-party software installer, or via a corrupted group policy object (GPO). The error code 0XC00001A2 translates to STATUS_INVALID_ACE_CONDITION, which means a security descriptor has an ACE (Access Control Entry) that contains a conditional expression (like a claim or device group condition) that's malformed or references a resource attribute that doesn't exist. Had a client last month whose entire file server directory went read-only because of a bad GPO that applied a conditional ACE using a claim type that wasn't defined in Active Directory. Took me an hour to trace it back to a misconfigured dynamic access control rule.

The error usually pops up in Event Viewer (Security log, event ID 4662 with failure code 0xC00001A2) or when you try to access a file/folder and get an access denied or error box with that hex code. You might also see it during Windows startup if a service can't read its own config files due to a corrupted ACE.

Fix steps

1. Find the object. Look in Event Viewer under Windows Logs > Security for the exact file or registry key path. If you don't see it, check Windows Logs > System. The error will show the object name near the event ID.
2. Open elevated command prompt. Run as admin. Type icacls "C:\Path\To\File" (or registry path like HKLM\Software\...\Key). Look for ACE entries with (ConditionalExpression) or (ResourceCondition) that look odd—like an expression that references a claim like @USER.AccountType when your environment doesn't use claims at all.
3. Remove the bad ACE. Use icacls "path" /remove "TrusteeName" if you know which user/group it's tied to. Or if the ACE is orphaned (no trustee listed), run icacls "path" /save backup.acl to export, manually edit the backup file to delete the broken ACE line, then icacls "path" /restore backup.acl. Not pretty, but works.
4. If it's a registry key, use regedit. Navigate to the key, right-click > Permissions > Advanced. Look for any ACE with a blue shield icon or a condition listed in the “Condition” column. Delete that entry.
5. Reapply default security. For system files: sfc /scannow. For registry: secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose. Yes, that command looks like alphabet soup, but it resets most system registry keys to their default permissions without touching your data.

Alternative fixes if the main one fails

• Group policy reset. If a GPO is the culprit (common in domain environments), run gpupdate /force on the affected machine, then check the GPO in Group Policy Management Console—look for “Central Access Policy” or “Dynamic Access Control” settings that reference claims you don't use. Disable or remove that policy.
• Use Process Monitor. Filter by error code 0xC00001A2. I’ve seen this pinpoint a bad ACE in a scheduled task's security descriptor. Kill the task and recreate it from a clean template.
• Third-party tool. SetACL (free) can strip conditional ACEs with a command like SetACL.exe -on "C:\Path" -ot file -actn clear -clr dacl -rec yes — but back up your current ACLs first.
• Last resort: restore from backup. If the object is a critical system file or registry hive, restore it from a known-good backup. Had a client who tried to manually edit the security on HKEY_LOCAL_MACHINE\SAM — don't do that. Restore the registry backup.

Prevention tip

Never manually edit ACE conditions in the advanced security GUI unless you know exactly what each claim and resource attribute means. Stick to built-in tools like icacls or group policy for setting permissions. If you need dynamic access control, define all claim types in Active Directory first using ADAC (Active Directory Administrative Center). And always take a screenshot or backup of the security settings before making changes. I learned that one the hard way after spending a Saturday fixing a server that had 30+ broken ACEs from a misconfigured third-party backup tool.