Fix STATUS_INVALID_SECURITY_DESCRIPTOR (0xC0000079) on file access
App or driver can't read a file's security descriptor because the structure is corrupted or truncated. Usually a permissions mismatch or NTFS corruption.
When you see this error
You're trying to open a file, run a program, or mount a drive on Windows 10 or 11 and you get error 0xC0000079. Maybe it's an old backup from a NAS you're restoring, or a folder you copied from an external drive that was yanked out mid-write. The app crashes, Windows Event Viewer logs a STATUS_INVALID_SECURITY_DESCRIPTOR under Application or System, and nothing you do with permissions seems to help. The real trigger is almost always a corrupted ACL — the security descriptor (SD) for the file is physically malformed.
What's actually happening
The security descriptor is a binary structure Windows attaches to every file and folder on NTFS. It tells the OS who owns the object, who can read/write/execute, and what auditing rules apply. If the SD is truncated, has an invalid revision number, or contains a self-relative pointer that points outside the structure, Windows throws 0xC0000079. The OS literally can't parse the security data, so it refuses access — even if you're the admin.
Common causes:
- Copying files from a Linux Samba share that wrote a malformed SD.
- An antivirus or backup tool that modified the SD mid-write.
- Disk corruption from a sudden power loss or improper USB ejection.
- A buggy driver that issues
NtSetSecurityObjectwith bad input.
The fix: Rebuild the security descriptor
Skip the GUI permission dialogs — they'll fail because they rely on the same broken descriptor. You need to force Windows to reset it at the filesystem level.
Step 1: Identify the broken file or folder
Open Event Viewer (eventvwr.msc), go to Windows Logs > System or Application. Filter by Event ID 0xC0000079 or search for “INVALID_SECURITY_DESCRIPTOR”. The log entry usually includes the file path. Write it down.
Step 2: Run Chkdsk to rule out NTFS corruption
Open Command Prompt as admin. Run:
chkdsk C: /scan
(Replace C: with the drive letter of the affected file.) If it finds bad clusters or orphaned SD entries, also run:
chkdsk C: /f /r
This will require a reboot. The /f flag fixes errors, /r recovers readable data. The reason step 3 works is that Chkdsk can reallocate the file's SD from its backup copy in the NTFS $Secure stream. If Chkdsk finds no issues, the SD is corrupted but the disk is physically fine — you move to the next step.
Step 3: Reset the security descriptor using icacls
Still in Command Prompt (admin), run:
icacls "C:\path\to\broken\file" /save "%TEMP%\perms.txt" /t /c /q
This exports the current ACLs to a text file (if it fails, don't worry — the SD is broken). Then force a grant to Administrators:
icacls "C:\path\to\broken\file" /grant "Administrators:(OI)(CI)F" /t /c
(OI)(CI)F means Object Inherit, Container Inherit, Full Control. The /t makes it recursive for folders, /c continues on errors. This overwrites the malformed SD with a clean one from the system's template. If you get “access denied” here, you'll need to take ownership first —
takeown /f "C:\path\to\broken\file" /r /d y
Then try the icacls command again.
Step 4: Restore original permissions (optional)
If you saved the perms in step 3, restore them:
icacls "C:\path\to\broken\file" /restore "%TEMP%\perms.txt" /t /c
If the backup file is empty or missing, just re-apply the correct ACLs manually via the Security tab — it should work now.
If it still fails
Three things to check:
- Antivirus interference: Temporarily disable real-time protection. Some security products (especially McAfee, Norton, and Webroot) hook into
NtSetSecurityObjectand can write malformed SDs. Test with the file after disabling. - Volume-level corruption: Run
fsutil dirty query C:to see if the volume is marked dirty. If yes, force a full Chkdsk at boot viachkntfs /x C:then reboot. - Third-party shell extensions: Explorer context menu items from Dropbox, OneDrive, or 7-Zip can sometimes write bad ACL entries. Uninstall them temporarily to rule it out.
If nothing works, the file itself might be a lost cause. Copy any data out from inside it (if it's a folder) using robocopy with /ZB flags, then delete the original and recreate it fresh.
Was this solution helpful?