0x00000520: A specified logon session does not exist

1. Stale cached credentials in Credential Manager

This is the most common reason you're seeing the 0x00000520 error. Windows is trying to use a logon session that it stored in Credential Manager, but the session is gone—maybe the user changed their password, maybe the server reset the session, or the cache got corrupted. I had a client last month whose entire remote desktop setup died because Windows kept using an old domain admin password from Credential Manager.

Here's the fix:

1. Open Control Panel, go to User Accounts > Credential Manager.
2. Click Windows Credentials.
3. Look for any entries related to the service or drive where the error shows up. Common names include TERMSRV/<servername>, MicrosoftAccount, or generic network share credentials.
4. Click the arrow to expand, then Remove. Yes, just remove them. Windows will ask you for fresh credentials next time it needs them.
5. Restart the service or application that failed. For task scheduler jobs, run them manually first to test.

If you see a bunch of stale entries from old users who no longer exist, clean them all out. A client of mine had 14 old credentials from a shared workstation that caused this error on a print server every time someone tried to scan to folder. Wiping them fixed it instantly.

2. Service account password expired or changed

If you're running a Windows service or scheduled task under a specific user account, and that account's password changed (or the account was deleted), you get this error. The service tries to start, but Windows can't create a logon session because the credentials don't work anymore. I see this all the time with SQL Server services, backup agents, and custom in-house apps that run as a domain service account.

To fix it:

1. Open Services.msc (or Task Scheduler for scheduled tasks).
2. Find the service that's failing. Look for services stuck in Starting or Stopped state.
3. Right-click > Properties > Log On tab.
4. If it says This account, update the password. If the account was deleted, switch to Local System account or Network Service instead—that avoids the whole credential mess.
5. Apply, then restart the service.

For scheduled tasks, go to Task Scheduler, find the task, right-click > Properties > General tab, and re-enter the password under Security options. Also check Run whether user is logged on or not—that's a common trigger for this error.

One quick tip: if you're not sure which service or task is causing the error, check the System and Application event logs in Event Viewer. Filter by Source: Service Control Manager or TaskScheduler. The event details usually include the user account name that's failing.

3. Kerberos ticket or network session mismatch

This one's rarer but happens when you're accessing a remote machine over the network, and the Kerberos ticket or SMB session is stale. You might see the error when trying to access a network share, run a remote PowerShell command, or connect to a SQL Server instance. The session that Windows thought was valid has been dropped—maybe the remote server rebooted, or the ticket lifetime expired.

Fix it like this:

1. Open a command prompt as admin. Run klist purge to clear all Kerberos tickets. This forces Windows to request fresh tickets.
2. If that doesn't work, disconnect any existing network drives: net use * /delete.
3. Then reconnect: net use Z: \\server\share /user:domain\username.
4. For remote PowerShell, close the session and restart. For SQL Server, restart the SQL Server Management Studio or application that's connecting.

I once had a developer who couldn't deploy to a test server because his Visual Studio kept reusing a dead logon session from a previous build. Running klist purge before each deployment fixed it, but ultimately we had to use a different authentication method (Windows Authentication with a service account) to avoid the issue entirely.

Quick-reference summary table