Quick answer: Boot into Safe Mode or a recovery environment, then run icacls * /t /q /reset on the affected folder, followed by sfc /scannow and chkdsk /f. That fixes 90% of cases.
I've seen 0XC0000077 on Windows 10, 11, and even Server 2019. The culprit here is almost always a corrupted security descriptor — the ACL structure the OS uses to decide who can do what. This can happen after a bad software uninstall, a disk write failure, or when an antivirus tool botches a permission rollback. The error shows up when you try to open a file, run an executable, or even just browse a folder. Windows can't read the ACL, so it throws STATUS_INVALID_ACL and blocks access entirely.
Don't bother with simple reboots or reinstalling the app that triggers it — that rarely helps. The real fix is surgical: reset the ACL, then check for underlying file system corruption.
Step 1 — Determine the affected resource
First you need to know exactly which file or folder is causing the error. The error message usually gives you a path. If it doesn't, check the Application event log:
- Press Win + R, type
eventvwr.msc, hit Enter. - Go to Windows Logs > Application.
- Look for an Event ID 0xC0000077 or a source like Application Error.
- Note the full path in the event details — that's your target.
Step 2 — Boot into Safe Mode with Command Prompt
Running these commands while the OS is fully loaded might fail because the system holds locks on the ACLs. Safe Mode strips that down. Here's how:
- Windows 10/11: Hold Shift while clicking Restart. Then go to Troubleshoot > Advanced options > Startup Settings > Restart. Press 4 for Safe Mode, or 5 for Safe Mode with Networking if you need internet access.
- Once in Safe Mode, open an elevated Command Prompt (right-click Start, choose Command Prompt (Admin) or Terminal (Admin)).
Step 3 — Reset the ACL with icacls
This is the bread and butter. Navigate to the parent folder of the offending file and run:
cd /d "C:\Path\To\Affected\Folder"
icacls * /t /q /reset
/tapplies to all child items recursively./qsuppresses success messages — keeps the output clean./resetreplaces every ACL with the default inherited permissions for that location.
If the error is on a registry key instead of a file, you'll need to use subinacl or the Set-Acl PowerShell cmdlet. But 95% of the time it's a file or folder.
Step 4 — Run System File Checker
Sometimes the corruption lives in system files that manage ACLs. After the icacls reset, run:
sfc /scannow
Wait for it to finish. If it finds corrupt files but can't repair them, note the log (%windir%\logs\cbs\cbs.log) and move to the next step.
Step 5 — Check disk for errors
ACL corruption often traces back to a failing disk or bad sectors. Run:
chkdsk /f /r
You'll be prompted to schedule it for next reboot. Type Y and restart. Let it run — this can take hours on larger drives. After it finishes, reboot back to normal mode and test your file.
Alternative fix — Takeown + Force ACL reset
If the above didn't work, the ACL might be so broken that icacls /reset can't even touch it. You need to take ownership first, then force a reset:
takeown /f "C:\Full\Path\To\File.ext" /r /d y
icacls "C:\Full\Path\To\File.ext" /grant administrators:F /t /q
The /grant administrators:F part gives full control to the Administrators group. This overrides the broken ACL. After that, you can run icacls /reset again to restore sanity.
Alternative fix — Restore from backup
If none of that works and you have a recent backup (File History, VSS shadow copy, or third-party), restore just the affected file. The ACL will come from the backup's security descriptor, which is likely clean. Right-click the file, go to Properties > Previous Versions and pick one.
Prevention tip
Don't manually edit ACLs on system files unless you really know what you're doing. I've seen admins try to lock down a folder with custom permissions and accidentally delete the SYSTEM entry — instant 0xC0000077. Stick to inherited permissions for most things. Also, keep your disk healthy — run chkdsk quarterly on mechanical drives. On SSDs, watch for reallocated sectors via SMART data.
One last thing: if you're on Windows 11 22H2 or later, there's a known issue with Windows Sandbox and integrity levels that can cause this error. Disabling Sandbox or updating to 23H2 fixed it for two of my clients.