Fix ERROR_SCREEN_ALREADY_LOCKED (0X000005A0) Fast

This error pops up when you try to lock a screen that's already locked, usually from a script or remote tool. Here's how to fix it quickly and prevent it from happening again.

I know that sinking feeling when your automation script or remote session throws ERROR_SCREEN_ALREADY_LOCKED (0X000005A0) right in the middle of a critical task. It's infuriating, but it's also a simple logic problem — you're asking Windows to lock a screen that's already locked. Let's fix it.

The Quick Fix

The most common cause is a script or tool calling LockWorkStation() when the workstation is already locked. The fix is to check the lock state before attempting to lock. Here's a PowerShell snippet that does exactly that:

$signature = @'
[DllImport("user32.dll")]
public static extern bool GetSystemMetrics(int nIndex);
'@
$getSystemMetrics = Add-Type -MemberDefinition $signature -Name "User32" -Namespace Win32 -PassThru

# SM_SERVERR2 (89) indicates session is locked (0 if locked)
$isLocked = $getSystemMetrics::GetSystemMetrics(89) -ne 0

if (-not $isLocked) {
    [System.Windows.Forms.SystemInformation]::LockWorkStation()
} else {
    Write-Host "Screen already locked, skipping."
}

If you're using C# or VB.NET, the same principle applies — check SystemInformation.TerminalServerSession and compare to your lock state, or use GetSystemMetrics(SM_SHUTTINGDOWN) (0x2000) to detect shutdown, but for lock specifically SM_SERVERR2 works. In practice, I've seen this error most often from scheduled tasks that run rundll32.exe user32.dll,LockWorkStation on a locked machine.

For a one-off, just run the lock command and ignore the error if it's already locked. But if you're doing this repeatedly, add the check.

Why This Works

Windows treats a lock request as a request that must succeed. When the screen is already locked, the call fails with ERROR_SCREEN_ALREADY_LOCKED because the system can't lock twice. The GetSystemMetrics(SM_SERVERR2) trick works because Windows sets a flag when the session is locked — it's a bit hacky, but it's been reliable across Windows 10 and 11. It's the same flag the system uses internally to prevent duplicate lock screens.

The alternative — catching the error and ignoring it — works too, but it clutters your logs and can mask real issues if the lock call fails for another reason (like insufficient privileges). Checking first is cleaner.

Less Common Variations

Remote Desktop Sessions

With RDP, this error appears when you try to lock a remote session that's already locked, often because you disconnected and reconnected. The fix is to disconnect properly or use tscon.exe to switch sessions. If you're scripting it, use this:

query session | findstr /i "Active"

If the state is already “Disc” (disconnected), don't attempt a lock. Instead, reconnect or kill the session.

Group Policy or Screensaver Race

Sometimes a screensaver with a lock-on-resume triggers this during logon scripts. The screensaver locks the screen a split second before your script runs. Set the screensaver wait time to be longer, or use a scheduled task that triggers on logon but waits a few seconds. I've seen this with Lenovo and Dell corporate images that have aggressive power settings.

Third-Party Lock Tools

Tools like Sysinternals Autologon or custom lock utilities can fire twice if they're misconfigured. If you see this error in event logs, check which process triggered it. Use Event Viewer → Windows Logs → Security, and look for event ID 4800 (workstation locked). That tells you which user locked it, but not which process. To get the process, enable command-line auditing or use a tool like Process Monitor.

Prevention

You can't stop every lock attempt, but you can stop most of the accidental ones. Here's what I do:

Always check lock state before locking — use the script above, or the equivalent in your language.
In scheduled tasks that lock screens, add a condition to run only when the workstation is unlocked (under Settings, check “Start the task only if the computer is on AC power” doesn't help, but you can add a custom script check).
In remote management tools like SCCM or PDQ, use their built-in “session state” checks. Don't trust that a disconnected session is unlocked.
For screensavers, set the timeout to at least 2 minutes after logon. This gives scripts time to finish.

I've also seen this error happen when two different admin tools try to lock the same machine at the same time. If you're running a patch management tool and a security tool both configured to lock on idle, they'll collide. Consolidate to one lock policy.

That's it. Check before you lock, and you'll never see this error again. If you're still hitting it after all this, leave a comment below and I'll help you debug it.