ERROR_INVALID_SID (0x00000539): Fix Invalid SID Structure

You try to open a folder, start a service, or launch an app, and Windows throws ERROR_INVALID_SID (0x00000539) at you. The message is blunt: "The security ID structure is invalid." It's not a network error, it's not a permissions error in the friendly sense — it's Windows telling you the binary blob it read as a Security Identifier isn't shaped like a SID at all.

What's actually happening here is that Windows stores SIDs in two places: inside access tokens (generated at logon) and inside security descriptors (attached to files, registry keys, services). If a descriptor is truncated, mis-typed, or references a SID that no longer maps to a real account, calls like LookupAccountSid and AccessCheck fail with 0x539. The fix depends entirely on which of those three is broken.

Cause 1: Corrupted ACL on a file, folder, or registry key

This is the most frequent trigger. It usually shows up after a botched restore from backup, a crash mid-write to the $Secure stream, or a third-party permissions tool (looking at you, old versions of SetACL and some "take ownership" PowerShell scripts) writing a malformed DACL. You'll see it when trying to open a specific path, and other paths work fine.

The tell: Event Viewer → Windows Logs → Security shows Event ID 4670 or 4907 with 0x539, or an app event log entry from the specific binary that touched the file. icacls on the path returns "The security ID structure is invalid" instead of the normal ACL dump.

Don't try to fix this by clicking through the Properties → Security tab. That dialog reads the same broken descriptor and will either hang or give you a misleading error. Use the command line, because it can bypass the cached ACL.

Step 1 — Take ownership using a built-in account SID rather than a name, so resolution doesn't fail:

takeown /f "C:\Broken\Path" /r /d y
takeown /f "C:\Broken\Path" /a

Step 2 — Reset the ACL to explicit Administrators + SYSTEM, then re-grant as needed:

icacls "C:\Broken\Path" /reset /t /c /q
icacls "C:\Broken\Path" /grant "BUILTIN\Administrators:(OI)(CI)F" /t
icacls "C:\Broken\Path" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" /t

The reason step 2 works is that /reset replaces the descriptor with one inherited from the parent, which is rebuilt from scratch. Any malformed ACE inside the old DACL gets discarded. If the parent itself is corrupt, walk up until you find a clean one, or reset from the drive root — which is a heavier hammer and will wipe inheritance you may care about.

Registry equivalent, if the bad descriptor lives in the hive:

regini -m \\%COMPUTERNAME% reset_acl.ini

Or use the built-in SubInACL (still downloadable from Microsoft's archive) with /reset. regedit's Permissions dialog will just throw the same 0x539 back at you.

Cause 2: A service or scheduled task points to a SID that no longer resolves

Scenario that trips this constantly: you migrate a machine off a domain, or delete a domain user, and a service was configured to run as that account. The service registration stores the account's SID in the registry under HKLM\SYSTEM\CurrentControlSet\Services\<name>\ObjectName. When the SCM tries to start the service, it calls LookupAccountSid against a SID that no longer exists in the local SAM or the domain — and if the SID itself is malformed (not just orphaned), you get 0x539 instead of the friendlier 1069 "logon failure."

Open Services.msc, find the service, and check the Log On tab. If it shows a long unresolved S-1-5-21-... string instead of a name, that's your culprit. Set it back to LocalSystem, or re-enter a valid account with services.msc or sc.exe:

sc.exe config "ServiceName" obj= "NT AUTHORITY\LocalSystem"

Note the space after obj= — that's not a typo, sc.exe requires it. Skip it and you'll get a syntax error and waste ten minutes.

For scheduled tasks, the offending XML lives in C:\Windows\System32\Tasks\<TaskPath>. Delete the task and recreate it, or export it, fix the <UserId> element, and re-import. Don't try to edit in place with Task Scheduler GUI on a locked task — you'll just get the same 0x539 when it tries to save.

Cause 3: A corrupted access token from profile or Group Policy damage

Least common but the nastiest. If the error fires across many operations — Explorer, cmd, services, all at once — the problem isn't a file descriptor, it's your logon token. This happens after a bad profile load, a corrupted NTUSER.DAT, or damaged GroupPolicy\Machine registry entries that inject extra SIDs into the token at logon.

Quick test: run whoami /user. It should print your SID cleanly. If it errors with 0x539, the token is the problem, not any file.

The fix is to blow away the profile and log back in:

1. Log in as a different admin account.
2. Open System Properties → Advanced → User Profiles → Settings, delete the broken profile.
3. Delete C:\Users\<brokenuser> if it survived.
4. Check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and remove any orphaned S-1-5-21-...} subkeys whose ProfileImagePath points at a missing folder.
5. Log back in as the user. Windows rebuilds the profile and a fresh token.

If Group Policy is the source, the registry keys under HKLM\SOFTWARE\Policies\Microsoft\Windows\System are the usual suspects — specifically RestrictAnonymous and any custom SID-based restrictions. Rename the key, run gpupdate /force, and reboot. A clean secedit /configure against the local security database also helps when local policy has a SID reference that no longer exists:

secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

One caveat: secedit /configure with defltbase.inf resets local security policy to defaults. On a domain-joined machine, group policy will re-apply on next gpupdate, so the blast radius is contained. On a standalone box, back up Local Security Policy via secedit /export first.

Quick reference

If none of those touch it, check the disk. A failing SSD or a controller throwing read errors will corrupt the $Secure stream silently, and you'll chase ACLs for a week while the drive quietly dies. Run chkdsk /scan and check smartctl -a before assuming it's software.