0X00000521

Fix ERROR_NO_SUCH_PRIVILEGE (0x00000521) on Windows fast

Windows Errors Beginner 👁 0 views 📅 May 26, 2026

Windows can't find a privilege it needs. Usually happens after a corrupt group policy or a messed-up user token. Two fixes, one under a minute.

The 30-second fix: Force a group policy refresh

I've seen this error pop up when Windows has a stale or corrupted local group policy cache. It's looking for a privilege that got deleted or renamed by an update, and the cached policy still references it.

  1. Open Command Prompt as Administrator.
  2. Type gpupdate /force and hit Enter.
  3. Wait for it to complete (usually 10-15 seconds).
  4. Restart your PC.

If the error goes away, you're done. Had a client last month whose entire remote desktop setup broke because of this—one gpupdate fixed it instantly.

If not, move to the next fix.

The 5-minute fix: Reset local security policy

Sometimes the security policy database itself gets corrupted. Windows stores user rights assignments in a file called secedit.sdb. If that file has a bad entry referencing a privilege that doesn't exist anymore (like after a feature update), you'll see 0x00000521.

  1. Open Command Prompt as Administrator.
  2. Run secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose
  3. Let it run. This rebuilds the local security policy from defaults.
  4. Restart.

If that command gives you an error, run secedit /export /areas USER_RIGHTS /cfg C:\backup_privs.inf first—that exports your current settings as a backup just in case.

I've used this on Windows 10 and 11 systems after botched updates. One client's print server couldn't start spooler—turned out a privilege entry was pointing to a GUID that didn't exist. This fix cleared it right up.

The 15+ minute fix: Manual registry check and repair

If the above didn't work, the privilege list in the registry is probably mangled. This happens when third-party software (antivirus, tweaking tools) or a half-baked update writes bad data into HKEY_LOCAL_MACHINE\SECURITY. Don't touch that branch directly—it's locked by Windows for a reason.

Instead, we'll use the system file checker and then check user rights assignments manually.

  1. Run sfc /scannow in Admin Command Prompt. Let it finish (can take 15-20 minutes on older drives).
  2. After that, run dism /online /cleanup-image /restorehealth to fix component store corruption.
  3. Restart.

Still broken? We can check if a specific privilege is missing from the system.

  1. Open Local Security Policy (run secpol.msc).
  2. Expand Security SettingsLocal PoliciesUser Rights Assignment.
  3. Look for any empty entries or entries with a string like SeSomePrivilegeNameNotInstalled. Delete those with the Remove button.
  4. Close secpol.msc and run gpupdate /force again.

If you find an entry that's blank, that's your culprit. Windows tried to create a privilege assignment but the privilege name was null. Delete it, reboot, and you're golden.

Had one case where a domain controller was handing out a privilege the workstation didn't have—removed the entry from the policy, problem solved.

Last resort: Create a new user profile

If none of the above works, the user token itself might be corrupt. Create a fresh local admin account, log into it, and see if the error follows. If it doesn't, migrate your data and delete the old profile.

This isn't common—90% of the time gpupdate /force fixes it. But for that last 10%, a new profile is the nuclear option.

One pro tip: if you're on a domain, check with your domain admin if a recent Group Policy update added a privilege that doesn't exist on your Windows version (like SeCreateSymbolicLinkPrivilege on an older build). That's a common mismatch that throws 0x00000521.

That's it. Start with gpupdate, then secedit, then manual cleanup. You'll kill this error in under 5 minutes most of the time.

Was this solution helpful?