Fix 0X8001013A: ACEs in Wrong Order on Windows
This error means your ACL has deny ACEs after grant ACEs. Fix it by reordering them with PowerShell or icacls. Don't waste time on generic registry tweaks.
Yeah, that error is a pain. You're trying to launch a COM app, set a registry key, or access a file, and boom — 0X8001013A with a long message about ACEs being in the wrong order. It's not a hardware failure or a driver problem. It's an ACL structure issue. The culprit here is almost always someone manually editing permissions and accidentally placing deny ACEs after grant ACEs in the security descriptor stream. Windows expects all deny entries before grant entries. Get that order wrong, and you get this error.
The Quick Fix: Reorder the ACL
Don't bother with sfc /scannow or chkdsk. That's not the problem. You need to read the current security descriptor, reorder the ACEs, and apply it back. I'll show you two ways — PowerShell and icacls. Pick the one you're comfortable with.
Method 1: PowerShell (Recommended)
This works on Windows 10 and Server 2016+. Open PowerShell as Administrator. Replace Path\To\Your\Target with the actual file, folder, or registry key path.
$path = "HKLM:\SOFTWARE\Microsoft\YourApp"
$acl = Get-Acl -Path $path
$accessRules = $acl.GetAccessRules($true, $true, [System.Security.Principal.NTAccount])
$denyRules = $accessRules | Where-Object { $_.AccessControlType -eq 'Deny' }
$grantRules = $accessRules | Where-Object { $_.AccessControlType -eq 'Allow' }
$newAcl = New-Object System.Security.AccessControl.RegistrySecurity
foreach ($rule in $denyRules) { $newAcl.AddAccessRule($rule) }
foreach ($rule in $grantRules) { $newAcl.AddAccessRule($rule) }
Set-Acl -Path $path -AclObject $newAclFor files or folders, change the first line to Get-ChildItem C:\YourFolder and adjust the New-Object to FileSecurity. The logic is the same — deny first, then grant.
Method 2: icacls (Classic, Works Everywhere)
If you're on Server 2012 R2 or older, or you just prefer command-line tools, use icacls. Save the current ACL to a file, manually reorder, and restore.
icacls "C:\YourFolder" /save acl_backup.txt /t
notepad acl_backup.txtIn the text file, you'll see lines like:
YourFolder
D:PAI(A;;FA;;;BA)(D;;FA;;;BU)The D: is the DACL. Each ACE is in parentheses. D means deny, A means allow. Move all deny entries before allow entries. Save the file, then restore:
icacls "C:\YourFolder" /restore acl_backup.txt /tThat's it. Test the app or action that was failing. It should work now.
Why This Happens
Windows security descriptor format is strict. The ACL stream has a header, then ACEs. The SDK header ACL_REVISION defines the order: deny ACEs first, then grant ACEs. This is documented in Microsoft's ACE_HEADER structure. When you manually edit permissions — especially with third-party tools or by copying ACLs between systems — it's easy to screw up this order. The COM runtime and NTFS parser check for this. If they find deny after grant, they throw 0X8001013A. It's a safeguard against ambiguous permissions.
Less Common Variations and Edge Cases
Sometimes the error isn't on a file but on a registry key, especially under HKEY_CLASSES_ROOT\CLSID for COM applications. The exact same fix works there — use the PowerShell script above with the registry path. I've also seen this happen on printer permissions and service DACLs. In those cases, use the icacls method or the Security tab in Advanced settings. If you're feeling brave, you can use the SetSecurityInfo API call with a reordered ACL, but that's overkill.
One weird case: if the ACL has inherited ACEs mixed with explicit ones, the reorder might not stick because inheritance reapplies. In that scenario, disable inheritance first:
icacls "C:\YourFolder" /inheritance:dThen reorder and reapply. Afterward, re-enable inheritance if needed:
icacls "C:\YourFolder" /inheritance:eAnother edge: Group Policy might rewrite the ACL on next refresh. If the error comes back after a reboot, check if a GPO is enforcing a bad ACL. Run gpresult /h gpoutput.html and look for security policy settings that touch the target path.
How to Prevent This From Coming Back
Stop editing permissions manually with the GUI's Advanced Security Settings. That interface lets you add deny rules anywhere. If you must use it, always add deny rules first. Better yet, script your permission changes with PowerShell or icacls so the order is enforced programmatically. If you're deploying software that sets permissions, include a post-install script that reorders ACEs. And if you're copying ACLs between servers with tools like subinacl or xcacls, always test the resulting ACL with icacls /save first — it'll show you the raw order. A few seconds of caution saves the headache of chasing 0X8001013A later.
Was this solution helpful?