Fix 0XC000005F Logon Session Error Fast

What's happening with 0XC000005F

This error is Windows saying "I don't recognize this logon session anymore." It usually pops up when a service, scheduled task, or app tries to use credentials that Windows has already discarded. I've seen it most often on Windows Server 2016 and Windows 10 machines after a password change or a domain policy update. One client's backup software started throwing it every night at 2 AM because the service account password had expired and no one updated it.

The good news: you don't need to rebuild anything. The fix is usually about refreshing that stale session. Start with the quick one below, and only move down if it doesn't stick.

Fix 1: The 30-second restart

If the error is tied to a specific service or app, the fastest fix is to kill the session and let Windows create a fresh one.

1. Open Task Manager (Ctrl+Shift+Esc).
2. Find the process throwing the error. It might be listed as the app name or a service like svchost.exe.
3. Right-click and select End Task.
4. If it's a service, open Services (Win+R, type services.msc), find the service, right-click, and choose Restart.

This clears the cached logon token that's gone bad. Nine times out of ten, that's all it takes. I've fixed a print spooler issue this way more times than I can count—spooler would crash with this error after a domain policy push, and a simple restart would bring it back.

If the error comes back right away or you see it at login, move to Fix 2.

Fix 2: The 5-minute credential clear

When a service or scheduled task uses stored credentials that Windows has invalidated, you need to clear them out. The Credential Manager is where those get cached.

1. Open Control Panel and go to User Accounts > Credential Manager.
2. Click Windows Credentials (not Web Credentials).
3. Look for any entry related to the service or app that's failing. It might list a server name or a domain account.
4. Click the entry and choose Remove.

Also, if the error involves a scheduled task with a "Run as" account, open Task Scheduler, find the task, right-click, and select Run to trigger a fresh login. But first, check the task's settings:

1. Open Task Scheduler (Win+R, type taskschd.msc).
2. Locate the failing task, right-click, and choose Properties.
3. On the General tab, see if "Run whether user is logged on or not" is checked. If so, click Change User and re-enter the password for that account.

This is the fix I used for a client's SQL backup job. The service account password had changed, but the task still had the old one cached. Re-entering it took two minutes and ended a week of nightly failures.

If the error still shows up, it's time to look deeper.

Fix 3: The 15-minute deep reset

When the quick fixes don't work, the logon session is likely tied to a service account that's in a bad state. Here's what to do.

Step 1: Check the service account

Open Services (Win+R, services.msc), find the service that's failing, double-click it, and go to the Log On tab. Note the account name. If it's something like NT SERVICE\SQLAgent, that's a virtual account—Windows manages it automatically, so the error is more likely a policy issue. If it's a domain account, you'll need to verify it exists and the password is correct.

For domain accounts, the quickest test is to open a command prompt and run:

runas /user:DOMAIN\ServiceAccount cmd.exe

If that returns 0xC000005F, the account itself is the problem. You'll need to reset the password in Active Directory, then update the service settings.

Step 2: Re-register the service

Sometimes the service's logon session is corrupted in the registry. A re-registration often clears it. Open an elevated command prompt and run:

sc.exe sdshow "ServiceName"

That shows the security descriptor. But honestly, I've rarely had to go that deep. More often, the fix is to unregister and re-register the service's security settings by using:

sc.exe privs "ServiceName" SeChangeNotifyPrivilege

That's a last-resort move, so only do it if you're comfortable with the command line.

Step 3: Wipe and re-create the logon session

If all else fails, reboot the machine. That clears every logon session. But if that's not an option (like on a server you can't take down), you can force a session refresh without a full reboot by stopping the service and clearing the cached token with:

klist -li 0x3e7 purge

That purges the local system's Kerberos tickets. Then restart the service.

One more thing—check the Windows Event Viewer under Windows Logs > Security for event ID 4625 or 4624 around the time of the error. That'll tell you exactly which account triggered it. I've had cases where the error was from a scheduled task that I didn't even know existed until I saw the event log.

When to give up and call an admin

If you've done all three and the error persists, it's likely a domain-level issue. The account might have been deleted or locked, or group policy is blocking the logon type. That's beyond a quick fix—you'll need to coordinate with whoever controls your Active Directory. But honestly, those cases are rare. Most of the time, Fix 1 or Fix 2 sorts it out.

Remember: this error isn't a sign of hardware failure or disk corruption. It's just Windows losing track of who you are. Refresh the session, and you're back in business.