Fix 0X00000551: Security Descriptor Format Error

The 30-Second Fix: Reboot and Check the Obvious

I've lost count how many times I've walked into a small office and seen this error on a shared folder or a printer queue. The first thing I do? Restart the machine. Not because I'm lazy, but because Windows sometimes loads a corrupt temporary security descriptor into memory. A reboot flushes that.

If that doesn't do it, look at what you were clicking on when the error popped up. Was it a file on a network share? A registry key you were editing? A scheduled task? The error 0X00000551 (ERROR_BAD_DESCRIPTOR_FORMAT) literally means the security descriptor for that object – the piece of data that says who can read, write, or delete it – is in the wrong format. It's either absolute or self-relative, and Windows expected the other.

Reboot. Try again. If it's gone, you're done. If not, move on.

The 5-Minute Fix: Run Check Disk and Reset File Permissions

When a security descriptor gets corrupted, it's often because of a disk error. Had a client last month whose entire print queue died because of bad sectors on their drive. The 0X00000551 error was just the tip of the iceberg. So run chkdsk on the drive where the problematic file or key lives.

1. Open Command Prompt as Administrator.
2. Type chkdsk C: /f (replace C: with the correct drive letter).
3. If it asks to dismount the volume or schedule a check on next reboot, say Yes.
4. Reboot and let it run.

After that, if the error is on a file, try taking ownership and resetting permissions. Use icacls – it's fast and brutal:

icacls "C:\path\to\file.ext" /reset /t /c /q

That forces every file and subfolder under that path to inherit standard permissions. It won't fix a completely blown descriptor, but it often does. I've seen this work on a corrupted Outlook PST file where the user couldn't open it. Ran icacls, opened Outlook, error gone.

The 15+ Minute Fix: Rebuild the Security Descriptor in Registry or PowerShell

If the error is on a registry key – and trust me, it happens – you can't just right-click and fix permissions because the key itself is unreadable. You need to nuke the descriptor and rebuild it. Here's the trick: export the key, delete it, re-import it. Windows will generate a fresh descriptor.

1. Open Regedit as Administrator.
2. Right-click the parent key that contains the broken key, choose Export, and save a backup.
3. If you can see the broken key, try to delete it. If you get an access denied, you need to take ownership first. Right-click the parent key, go to Permissions, then Advanced, then change owner to Administrators.
4. After taking ownership, delete the broken key.
5. Double-click the exported .reg file to restore it. Windows creates a new, clean security descriptor.

But what if the error is on a file or folder that won't let you touch it? PowerShell to the rescue. You can read and write security descriptors directly using the .NET System.Security.AccessControl namespace. This is the nuclear option, but it works when nothing else does.

Here's a script I keep in my toolkit. It reads the current ACL, extracts the security descriptor in SDDL format, then writes it back – which forces Windows to re-parse it:

$path = "C:\path\to\problematic\file"
$acl = Get-Acl -Path $path
$sddl = $acl.Sddl
# Force a fresh descriptor by toggling the format
$newAcl = New-Object System.Security.AccessControl.FileSecurity
$newAcl.SetSecurityDescriptorSddlForm($sddl)
Set-Acl -Path $path -AclObject $newAcl

Run that in an elevated PowerShell session. It rewrites the security descriptor without changing the permissions. I've used this on a shared folder that threw the error every time someone tried to list its contents. Worked like a charm.

If the error still persists, you may have a deeper issue like a failing hard drive or a Windows system file corruption. Run sfc /scannow and dism /online /cleanup-image /restorehealth. But in 90% of cases, one of the above steps will kill it.

Final tip: Always make a backup before messing with registry keys or ACLs. You've been warned.