STATUS_NO_SUCH_PRIVILEGE (0XC0000060) Fix: Missing Privilege Error

Quick Answer (Advanced Users)

Run secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /areas USER_RIGHTS as admin. If that fails, check for orphaned SIDs in HKLM\SECURITY\Policy\Accounts and delete the bad one. Otherwise, restore the security policy from a backup.

Why You're Seeing This Error

STATUS_NO_SUCH_PRIVILEGE (0XC0000060) pops up when Windows tries to apply a user right assignment—like SeServiceLogonRight or SeBatchLogonRight—but the privilege name doesn't map to anything valid. This usually happens after you mess with Group Policy, corrupt the security database, or import a policy from a different machine. I had a client last month who copied a GPO from a Windows Server 2022 box to a Windows 10 workstation, and boom—every service account lost logon rights because the privilege names didn't match.

Another common trigger: using a third-party tool like LGPO.exe or secedit to export and import security settings. If the tool drops a privilege name that doesn't exist on the target OS version (e.g., SeTrustedCredManAccessPrivilege from a newer build), Windows throws 0xC0000060. You'll see it in event logs as Windows failed to apply Privilege Rights with error code 0xC0000060.

Less common but still real: a damaged SAM or Registry hive. Power failure during a policy update can corrupt the SECURITY hive, leaving dangling entries. That's harder to fix, but I'll include it below.

Step-by-Step Fix: Restore Default Security Policy

1. Open Command Prompt as Administrator – hit Windows+X, choose Terminal (Admin).
2. Backup current policy (just in case):
   secedit /export /cfg C:\backup\secpolicy.inf
   If this fails, skip it—you need working policy to export, which you don't have.
3. Reset to default with built-in template:
   secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /areas USER_RIGHTS /verbose
   This reassigns all user rights to their out-of-box values. The /verbose flag shows you exactly which privilege fails—take note if it still errors.
4. Reboot. Then test. If error persists, go to the registry fix below.

If That Doesn't Work: Registry Edit for Orphaned Privileges

Sometimes the security database is fine but a privilege name got mangled in the registry. Open regedit and navigate to:
HKEY_LOCAL_MACHINE\SECURITY\Policy\Accounts
You'll see SIDs like S-1-5-21-...-513. Expand each one, look at Privilgs—that's the old 8.3-style name for privileges. If you see something like SeUndocumentedPrivilege or a name with garbage characters, delete that subkey. Backup the entire Accounts key first (right-click, Export).

After deletion, run:
secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /areas USER_RIGHTS
This regenerates the privilege list. Reboot.

Alternative Fixes If the Above Fails

• System Restore – if you have a restore point from before the error appeared, roll back. Works 80% of the time.
• DISM + SFC – run DISM /Online /Cleanup-Image /RestoreHealth then sfc /scannow. This repairs system files but not policy corruption directly. Still worth a try.
• Active Directory environment – if this is a domain-joined machine, the problem might be a corrupted GPO. Run gpresult /h C:\gpreport.html, look for any Filtering Denied or Error on user rights. On the domain controller, check Default Domain Policy and remove any custom privileges that don't apply to your client OS.
• Nuke and rebuild – wipe the SECURITY hive? Not possible—it's protected. But you can export and re-import the security policy from a working machine (same OS build) using secedit /export on the good machine, then secedit /configure on the bad one. Match both OS versions exactly or you'll import new privileges that don't exist.

Prevention Tip

Stop copying security policies between different Windows versions. Each OS build has a distinct set of privileges. If you must export/import, use the /areas flag with secedit to only move the specific section you need—like FILE_PATHS or REGISTRY_VALUES—never USER_RIGHTS across builds. Also, never edit the SECURITY hive directly without a backup. I've seen admins delete a key that looked orphaned but turned out to be a critical privilege for the Local System account. Took me three hours to rebuild the machine.

Real story: A client ran LGPO.exe to apply a security baseline from Microsoft's website. It included a privilege called SeDelegateSessionUserImpersonatePrivilege which only exists in Windows 10 1809+. Their 1709 machines threw 0xC0000060 on every user logon. Fix was to delete that privilege entry from the GPO using secpol.msc. Took me 10 minutes.

Bottom line: if you see 0xC0000060, start with secedit /configure. It's the fastest reset. If that fails, dig into the registry. Only resort to system restore or rebuild as a last step. Most cases are just a bad privilege name that got imported.