SSOGEN / Free tools / Event ID 4740: Decode an Account Lockout and Find What Caused It, Free in Your Browser

Free tool

Event ID 4740: Decode an Account Lockout and Find What Caused It, Free in Your Browser

Event ID 4740 means a user account was locked out. Paste the event into this free decoder to see who was locked out and which computer sent the bad passwords, in your browser, with nothing uploaded.

Try it on your systems

Paste an event and read it

Paste the text from Event Viewer, or the XML from its Details tab. To see the output first, press Account locked out (4740) to load an Acme sample.

Paste the event text or XML

From Event Viewer: open the event, then copy the General text, or the XML from the Details tab (XML View). Events 4624, 4625, 4634, 4647, 4648, 4672, 4740, 4768, 4769, 4771 and 4776 are recognized.

Private by design. Decoding happens in this page and nothing is sent anywhere. Event text holds account names, host names and IP addresses: use a copy you are allowed to look at, and remove anything you must not share.

Free, in your browser. No sign-up and no limit, and the page makes no network request when you decode. Event text still holds account and host names, so use a copy you are allowed to read.

What event 4740 records

Event ID 4740 is the Windows Security log entry for “a user account was locked out”. Windows writes it once, at the moment the account crosses the lockout threshold.

The key field. It names the Caller Computer Name: the computer the last bad logon attempt came from.
The usual cause. That name is the shortest route to the cause, which is almost always an old password saved somewhere.

This page covers how a lockout happens, where to find the event and how to trace it. For the failures that lead up to a lockout, see the event ID 4625 decoder.

How an account gets locked out

Three Group Policy settings control lockout. All three are under Computer Configuration, Policies, Windows Settings, Security Settings, Account Policies, Account Lockout Policy, according to Microsoft Learn (read 2026-10-09).

Setting	What it does	Allowed values	Default
Account lockout threshold	Failed sign-in attempts that cause the account to lock	0 to 999; 0 means never lock	0 in the default domain policy
Account lockout duration	Minutes a locked account stays locked before it clears itself	0 to 99,999; 0 means locked until an administrator clears it	Not defined
Reset account lockout counter after	Minutes after a failed sign-in before the failure count returns to 0	1 to 99,999	Not defined

One rule ties them together: if the threshold is above zero, the duration must be at least the reset time.

Microsoft’s pages say the Windows security baselines recommend a threshold of 10 and a reset time of 15 minutes, with about 15 minutes as a sensible duration.

Microsoft calls all of these a guideline, not a rule, because no single value fits every organization.

With a threshold of 10 and a 15-minute window, ten bad passwords inside 15 minutes lock the account; ten spread across a day do not.

The default threshold is 0, so no 4740 is written until someone sets a threshold.

If you never see lockouts, check this setting before you assume all is well.

Microsoft’s threshold page also lists behaviors that explain unexpected counts:

Kerberos can retry a sign-in automatically when clients, servers and domain controllers negotiate encryption types, and those retries count toward the threshold.
An application that handles failures badly, such as one whose connection keeps dropping, can send many failed attempts. They all count.
A wrong password typed at a workstation lock screen counts too, because Windows must contact a domain controller when the password differs from the one used to log on.
The built-in Administrator account is excluded from the lockout threshold policy.

Where event 4740 is logged

Microsoft’s event 4740 page says it is generated on domain controllers, member servers and workstations (read 2026-10-09).

A domain account. Start on a domain controller. In a domain with several, the event is on the one that processed the failure, so search each until you find it. Microsoft’s page does not say which domain controller records it.
A local account. Look on that workstation or server.
The audit policy. The event belongs to the Audit User Account Management subcategory; if that audit policy is off, the event is never written.

Reading the fields

Field	What it holds
Subject, Account Name	The account that performed the lockout. Microsoft notes the event is typically triggered by the SYSTEM account (the sample shows the domain controller’s computer account, DC01$)
Account That Was Locked Out, Security ID and Account Name	The person or service whose account is now locked
Caller Computer Name	The computer the logon attempt was received from, after which the account was locked
Logon ID	A value you can match to recent events with the same ID, such as a 4624

Caller Computer Name is the field to act on. Microsoft’s page adds that for a computer outside your domain you still get a computer name, not an IP address.

That helps when the source is a laptop or phone, although you may need DHCP or network records to find the device.

The event carries no password, no logon type and no failure reason. For those, read the 4625 and other events around it.

Worked example. Load the sample.

The account. Maria Lopez’s account (maria.lopez) was locked out.
The source. The Caller Computer Name is WS-FIN-014.
The subject. DC01$, the domain controller’s own account, which fits the SYSTEM-triggered lockout Microsoft describes.

Go to WS-FIN-014 and find what still holds her old password.

Finding the source of the bad passwords

With the Caller Computer Name, the next step is to find the program on that computer that keeps sending a stale password.

The table lists the usual places. It reflects our own experience, not a Microsoft procedure, and none of the sources below verify it.

Where to look on the Caller Computer	Why it fails
Saved credentials in Windows Credential Manager	A stored password predates the last change
Mapped network drives set to reconnect	They reconnect with the old password at every sign-in
Services running under the user’s account	A service holds the password it was installed with
Scheduled tasks set to run as the user	Same idea, run on a timer, which makes lockouts appear at a regular hour
Mobile phones and tablets with work mail	They keep retrying in the background with the old password
A second logged-on session, such as a disconnected remote desktop session	A program in it is still using the old credentials
A browser or a script with a stored password	An application cached the old one

The timing narrows it down.

Returns after a set number of minutes. Something retries on a timer.
Returns only after the person signs in. A stored credential is used at sign-in.

What to do first, and what to skip

Confirm the event. Match the Account That Was Locked Out in the 4740 to the user report, and note the time and the Caller Computer Name.
Look at the failures before the lockout. Search the Caller Computer and the domain controllers for 4625, 4771 and 4776 on the same account around that time. Failure codes are in the next section.
Fix the source, then clear the lockout. Have the person change or remove the stored password on the Caller Computer, or fix the service or task, and only then clear the lockout. (This ordering is our advice.)
Watch for a repeat. If the account locks again within one reset window, the source is not fixed, or there is more than one.

What to skip: do not just clear the lockout again and again.

Each reset gives the same stale password another run at the threshold, and you lose the evidence that the lockout was real. If someone is guessing passwords, each reset gives them more attempts.

Do not disable lockout to stop the complaints either.

Microsoft’s own pages warn that a threshold of 0 belongs only where complex passwords are required and a dependable audit process alerts administrators to a series of failed sign-ins.

How 4740 relates to 4625, 4771 and 4776

A 4740 is the consequence. The events below are the attempts that caused it, and each is written on a different machine.

Event	Where it is written	What it adds
4625	The computer where the attempt was made	Logon type, Status and Sub Status such as 0xC000006A for a wrong password. After the lockout, further tries fail with Status 0xC0000234. See the 4625 decoder
4771	Domain controllers only	A Kerberos pre-authentication failure. A wrong password at the Kerberos stage is logged as 4771 with failure code 0x18, not as 4768
4776	The computer that is authoritative for the credentials (the domain controller for domain accounts)	An NTLM credential validation. The Source Workstation field names where it came from, and error code 0xC0000234 means the account was locked. Microsoft says it can show all NTLM attempts for domain accounts on domain controllers

Read all three, because each can show a different path.

If the 4771 events show Kerberos and the 4776 events show NTLM from the same computer, two different programs on it are failing. For background on ticket events, read the Kerberos explainer.

Lockout as a password-spraying signal

Microsoft’s lockout threshold page makes two security points:

The policy limits brute-force guessing, but it also creates a denial-of-service risk: an attacker who knows account names can lock many of them with no credentials, only network access.
It does not stop offline password attacks.

Handle a burst of 4740 events with care. One lockout from the person’s own machine is usually a stale password.

Two patterns deserve a closer look: many different accounts locked in a short window, and lockouts from a Caller Computer Name the account does not normally use.

Microsoft’s 4740 page gives the same advice:

Alert if the account should not be used from that Caller Computer Name.
Watch for Caller Computer Names outside your domain.
Consider monitoring every lockout of high-value accounts.

Password spraying tries one or a few common passwords against many accounts, so each account may stay under the threshold.

You may see failures (4625 or 4771) across many names with no 4740 at all. Credential stuffing and password spraying covers how to tell the two attacks apart.

A password policy with a banned-password list and a second sign-in factor limits the damage when a guess is right.

What is event ID 4740?

The Security log event “A user account was locked out”. It’s generated every time an account is locked out and names the locked account and the Caller Computer Name that sent the last logon attempt.

Which event ID is an account lockout?

4740. The failed attempts leading up to it are 4625 on the computer where the attempt was made, 4771 for a Kerberos wrong password and 4776 for NTLM. The lockout itself is only 4740.

Where do I find event 4740?

In the Security log. Microsoft says it’s generated on domain controllers, member servers and workstations. For a domain account, search the domain controllers. There may be several.

What does Caller Computer Name mean in 4740?

The name of the computer the logon attempt was received from, after which the account was locked. Look there for saved credentials, mapped drives, services and scheduled tasks using an old password.

Why do I not see event 4740 when users fail to sign in?

The account lockout threshold may be 0, the default in the default domain policy. That means accounts never lock. User Account Management auditing must also be on.

How long does an account stay locked out?

It depends on the Account lockout duration setting. A value from 1 to 99,999 is minutes, after which the account clears itself. 0 keeps it locked until an administrator clears it. Microsoft lists no default, so check it under Account Lockout Policy in Group Policy.

Why does my account keep getting locked out?

Usually something keeps sending an old password: a saved credential, mapped drive, service, scheduled task or phone. Read the Caller Computer Name in the 4740 event, go to that computer, and update or remove the stored password before you clear the lockout again.

Is an account lockout a sign of an attack?

It can be, but most are stale passwords. Many accounts locked at once, or a Caller Computer Name the account never uses, deserves a look as possible guessing or password spraying.

Where to go next

More diagnostics. Browse the other free tools.
The failures. Decode them with the event ID 4625 decoder.
SSOGEN’s own record. Read about the SSOGEN audit log, which is a separate record of SSOGEN’s own sign-ins and doesn’t read Windows events.

Sources, all read 2026-10-09: Microsoft Learn pages for event 4740, Account lockout threshold and Account lockout duration. The 15-minute reset value comes from Microsoft’s Reset account lockout counter after page, read 2026-10-09. The 4776 details come from Microsoft’s event 4776 page, read 2026-10-09. The 4771 behavior comes from Microsoft’s event 4771 page, read 2026-10-08. Microsoft and Windows are trademarks of their owner; SSOGEN is not affiliated with Microsoft.

An out-of-date saved password also produces an event ID 4648 each time a process tries it. Check for 4648 events from the locked-out user’s session.