Fix 0xC00000B9 ACL missing info error in Windows

Your access control list (ACL) is missing critical data. This usually happens after a security tool or script corrupts a registry key. We'll rebuild it.

You're staring at 0xC00000B9 — it's an ACL corruption, not a hardware issue.

This error pops up when Windows tries to read an access control list and finds it's structurally incomplete. The ACL exists, but it's missing mandatory fields like the owner SID or the system ACL. I've seen this most often after running a third-party security cleaner, or after a botched registry permission change via a script. The fix is straightforward: you need to reset the ACL on the affected key or file using the Windows built-in tools.

The direct fix: Reset the ACL with subinacl or icacls

Identify the exact object. The error message usually includes a path — a registry key like HKLM\Software\Microsoft\Windows\CurrentVersion\Policies or a system file like C:\Windows\System32\config\SAM. That's your target.
Open an elevated Command Prompt. Windows key, type cmd, right-click, Run as Administrator.
Reset the ACL with icacls (for files/folders):
```
icacls "C:\Path\To\Target" /reset /t /c /q
```
The /reset flag replaces the ACL with the default inherited permissions. /t applies to subfolders, /c continues on errors, /q keeps output quiet. If it's a registry key, use subinacl instead.
For registry keys, use subinacl (Windows Server 2003 Resource Kit tool — still works on Win10/11):
```
subinacl /keyreg "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies" /setowner=administrators /grant=administrators=f
```
Download subinacl.exe from Microsoft's archive if you don't have it. The /setowner flag fixes a missing owner SID, which is the most common cause of this error. The /grant ensures full control for the local admin group.
Reboot and test. The error should disappear. If it doesn't, you may have multiple corrupted ACLs — repeat for each path mentioned in any error logs.

Why this works

What's actually happening here is that the ACL's security descriptor is malformed. Every ACL must contain at least an owner SID and a system ACL (SACL) or discretionary ACL (DACL). When those fields are null or garbled, Windows throws 0xC00000B9 because it can't interpret the permission structure. The /reset flag in icacls doesn't just copy permissions — it rebuilds the entire security descriptor from the parent object's inheritance. For registry keys, subinacl's /setowner explicitly writes a valid owner SID into the descriptor header, which is the missing piece that causes the error. The reason step 3 works is that it forces the OS to re-read the inherited template and reconstruct a complete ACL object in memory.

If you're thinking "I already have permissions to that key," that's not the issue. The ACL itself is broken — Windows can't even parse it to check if you have rights. It's like handing someone a lock with no keyhole. The fix doesn't grant you permissions; it repairs the container.

Less common variations

Sometimes 0xC00000B9 shows up in the System event log with no obvious file or key. Here are three scenarios I've debugged:

Chkdsk runs at boot: A corrupted volume bitmap can produce this error. Run chkdsk c: /f from an elevated prompt, then reboot. The disk check repairs the MFT entries that store ACL metadata.
Network share drives: If the error appears when mapping a drive, the remote share's ACL is broken. You can't fix the remote ACL from your machine — the admin of that server needs to run icacls /reset on the shared folder.
PowerShell profile corruption: Rare, but if the error triggers when launching PowerShell, your $PROFILE script might be owned by a deleted user account. Delete the user-specific profile from %USERPROFILE%\Documents\WindowsPowerShell and let PowerShell recreate it.

Prevention

Stop using permission-cleanup tools that claim to "optimize" registry or file security. They often strip mandatory ACL fields to reduce size. Stick to icacls and subinacl for any permission work — these tools validate ACL structure before writing. Also, if you're scripting registry permission changes, always use Set-Acl in PowerShell with a proper System.Security.AccessControl.RegistrySecurity object. Don't write raw SDDL strings unless you know every field. The error 0xC00000B9 is a symptom of treating the ACL like a plain text file — it's not. It's a binary structure with required fields. Respect those fields, and you won't see this error again.