How Selenium + Chrome Locked Me Out of My Own Windows Account

Bill Gates — Fri, 11 Sep 2026 15:32:59 +0000

I ran into one of those "bugs" that initially looks completely unrelated to your code.

My Windows account started getting locked randomly.

The weird part was that I knew the password was correct. Sometimes I could log in normally, and sometimes Windows would suddenly say that the account was locked.

At first I assumed it was some Windows issue.

It wasn't.

The clue: Event ID 4625

After checking the Windows Security event log, I found a large number of failed logon events:

Event ID: 4625
TargetUserName: John Doe
LogonType: 2
SubStatus: 0xc000006a
ProcessName: C:\Program Files\Google\Chrome\Application\chrome.exe

0xc000006a means that the authentication attempt failed because of an incorrect password.

But the interesting part was this:

ProcessName: chrome.exe

Chrome was generating failed Windows authentication attempts.

And then I remembered what I was doing immediately after logging in: running a Selenium application that starts multiple Chrome instances in parallel.

What was actually happening

By default, ChromeDriver creates a temporary Chrome profile for a Selenium session.

Chrome has Windows-specific logic that may check the current user's authentication state. One of those checks can call the Windows LogonUser API using an empty password.

DWORD logon_result =
    LogonUser(username, L".", L"", LOGON32_LOGON_INTERACTIVE,
              LOGON32_PROVIDER_DEFAULT, &handle);

For a Windows account with a real password, that authentication attempt fails. Normally this is mostly harmless. But my application was creating many independent Chrome instances.

So effectively I had something like this:

Start Selenium -> Create many ChromeDriver instances -> Create many fresh Chrome profiles -> Chrome performs Windows authentication checks -> Create many fresh Chrome profiles -> Chrome performs Windows authentication checks -> Windows records multiple failed logon attempts -> Account lockout threshold is reached

So the funniest part of the bug was that my actual password was never wrong.

Windows was locking me out because Chrome instances started by Selenium were generating failed authentication attempts in the background.

How I confirmed it

The Windows Security log contained batches of Event ID 4625 entries, all pointing to:

chrome.exe

The timing also matched the moment my Selenium application started creating browser instances.

You can check the current Windows lockout policy with:

net accounts

Look for the account lockout threshold.

If the threshold is relatively low and your Selenium app starts many fresh Chrome profiles, you can hit it surprisingly quickly.

Temporary workaround

You can disable account lockout completely:

net accounts /lockoutthreshold:0

This prevents Windows from locking the account after failed authentication attempts.

I would treat this as a workaround, not necessarily the ideal permanent solution, since account lockout is also a security feature.

Better fix: reuse Chrome profiles

Instead of letting ChromeDriver create a fresh temporary profile every time, give each Selenium worker its own persistent profile:

var options = new ChromeOptions();

options.AddArgument(
    $@"--user-data-dir=C:\SeleniumProfiles\Worker{workerIndex}");

var driver = new ChromeDriver(options);

For parallel execution, don't point every Chrome instance at the same profile.

Use one persistent profile per worker:

SeleniumProfiles/
    Worker0/
    Worker1/
    Worker2/
    Worker3/

This also has the nice side effect of avoiding repeated first-run initialization for every Selenium session.

Conclusion

If Windows suddenly starts locking your account and you're running lots of Selenium/ChromeDriver instances, check Event Viewer before blaming your password.