0XC0000079

Fix STATUS_INVALID_SECURITY_DESCRIPTOR (0xC0000079) on file access

Cybersecurity & Malware Intermediate 👁 0 views 📅 Jun 9, 2026

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 NtSetSecurityObject with 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 NtSetSecurityObject and 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 via chkntfs /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?