Advapi Logon Failure | Fix 4625 And Service Logins Fast

You’ll usually see this tied to Windows Security Event ID 4625, “An account failed to log on.” In many records the Logon Process shows Advapi, which is a common Windows API path apps and services use when they ask the Local Security Authority to authenticate a user or service account.

The phrase sounds scary because it’s vague. The event record is not vague. The account name, caller process, logon type, and the hex status codes tell you what broke and where to fix it.

What Advapi Logon Failure Means In Event 4625

Event 4625 is generated on the computer where the failed logon was attempted. It records “who tried,” “how they tried,” and “why it failed.” Microsoft’s audit event reference for 4625 explains each field and how to use it during investigation.

“Advapi” does not mean “web login” by itself. It means the request flowed through an API route that many components use. You can still have IIS, a scheduled task, a Windows service, a mapped drive, or a user sign-in behind it. The other fields decide the story.

Advapi Logon Failure Triage Steps

Open one fresh 4625 event that matches the time the issue occurred. Then collect these fields before you change anything. This keeps you from fixing the wrong place.

1. Verify the event — Confirm it is Security log Event ID 4625 and note the timestamp.
2. Capture the account — Copy Account Name and Domain, plus the Target User Name fields if present.
3. Read the codes — Write down Status and Sub Status (hex). These usually name the failure reason.
4. Check the logon type — Logon Type tells you whether this was interactive, network, service, batch, or remote desktop.
5. Identify the caller — Caller Process Name often points to the component that stored the bad credential.
6. Note network fields — Workstation Name and Source Network Address can identify the source device, when populated.

After that, pull a small time window around the event and check for a matching 4624 success event for the same account. A success right after a failure often means something retried with a corrected password or a second auth path.

Status And Substatus Codes That Explain The Failure

Status and Sub Status are the fastest route to the root cause. Microsoft documents 4625, and Microsoft’s audit references for related auth events list many of the common NTSTATUS codes you’ll see during logon failures.

Code	What It Usually Means	First Fix To Try
0xC000006A	Valid username, wrong password	Reset the password, then update stored credentials
0xC000006D	Generic logon failure	Confirm username format and where it authenticates
0xC0000064	User account does not exist	Fix the account name in the app, task, or service
0xC0000234	Account locked out	Unlock it, then find the device still trying old creds
0xC0000072	Account disabled	Enable it or replace it with an active account
0xC0000071	Password expired	Set a new password, then update every dependency
0xC000006F	Logon outside allowed hours	Adjust logon hours or change when the job runs
0xC0000070	Workstation restriction	Allow the host or run the job from an allowed host
0xC000005E	No logon servers available	Check DC reachability, DNS, and time sync

Logon Type Cheat Sheet

Logon Type makes the fix faster because it points to where credentials live.

• 2 (Interactive) — A user typed credentials at the console.
• 3 (Network) — A remote access attempt to a resource like a share.
• 4 (Batch) — A scheduled task style logon.
• 5 (Service) — A Windows service started under an account.
• 10 (RemoteInteractive) — Remote Desktop sign-in.

Fixes By Scenario

Use the event’s Logon Type, Caller Process Name, and status code to pick the right path. Most advapi logon failure cases match one of these patterns.

Wrong Password Or Stale Stored Credentials

This is the most common pattern for 0xC000006A and 0xC000006D. A password changed, then something kept using the old one.

1. Change the password once — Update it in Active Directory or Local Users, then confirm it works with a direct sign-in.
2. Update services — In Services, check “Log On As” accounts, update the password, then restart the service.
3. Update scheduled tasks — In Task Scheduler, update the stored password for tasks that run under the account, then run them manually.
4. Clean stored credentials — On the source machine, remove saved entries in Credential Manager, then try again.

If failures occur at a steady interval, that rhythm often matches a task trigger or a service retry loop. Use the timestamp pattern to narrow your search.

Locked Out, Disabled, Or Expired Accounts

Lockouts usually mean repeated bad passwords from one device. Disabled and expired accounts often point to retired service accounts that were never removed from a service or app.

1. Confirm the account state — Check whether it is locked, disabled, or expired.
2. Locate the source — Use Workstation Name and Source Network Address when present. If they are blank, use the Caller Process Name and Logon Type.
3. Remove the dependency — Update the service, task, app pool, or connector that still references the old account.
4. Retest and watch the log — Look for a 4624 success, then confirm 4625 events stop for that account.

In Microsoft Q&A examples, 4625 records with Advapi and codes like 0xC0000072 are tied to accounts that are disabled, with a local process listed as the caller. That pattern fits services, scheduled tasks, and desktop apps that still store old credentials.

Service Logons Blocked By User Rights

If Logon Type is 5 and the password is correct, check user rights assignment. A service account needs “Log on as a service,” and it must not be listed under the deny right.

1. Identify the service — Find the service that runs under the account and note its name.
2. Grant the right — In Local Security Policy or Group Policy, add the account to “Log on as a service” for that host.
3. Check deny policies — Remove the account from “Deny log on as a service” if it appears there.
4. Restart and validate — Restart the service and confirm a 4624 success appears.

Network Logons That Fail From Another System

If Logon Type is 3, the request is a network logon. It can be a file share, printer access, remote management tool, or an app connection.

1. Confirm the source host — Use Workstation Name and Source Network Address when available.
2. Check access to the target — Validate share permissions and NTFS permissions for the account.
3. Review account restrictions — Fix logon hours and workstation restrictions if the code points to them.
4. Audit for attack patterns — A sudden spike across many accounts can be password spraying, not misconfig.

Finding The Source When There’s No IP Address In The Event

Some 4625 events show “-” for network fields, which is common when the request is local, or when the path does not record network details. You can still pinpoint the source by switching to process-first investigation.

1. Follow the process name — w3wp.exe points to IIS app pools and web apps. services.exe points to Windows services. taskeng.exe points to tasks.
2. Correlate with task history — Turn on task history and match the failure timestamp to task runs.
3. Check IIS and app logs — Match the timestamp to repeated auth failures or app startup errors.
4. Search for all uses of the account — Services, scheduled tasks, run-as shortcuts, mapped drives, and saved credentials are the usual places.

Once you’ve found the storing location, the fix is normally a password update or an account swap. After that, confirm the failures stop.

Reducing Repeat Failures And Noise

After you stop the first wave, take a few steps to keep it from coming back next week. Most repeat 4625 storms come from password rotations that didn’t touch every dependency, or from accounts that were retired while services still referenced them.

Advapi Logon Failure patterns are easier to control when you standardize how accounts are used and where credentials are stored.

• Separate user and service accounts — Keep services and scheduled tasks off personal accounts so a user password change doesn’t break automation.
• Track where service accounts run — Maintain a short inventory of which services, tasks, and app pools use each account.
• Rotate credentials in one pass — When you change a password, update services, tasks, app pools, and saved credentials in the same session.
• Limit logon rights — Grant “Log on as a service” only to the hosts that need it, and remove the right when a service is decommissioned.
• Watch for spikes — A sharp rise in 4625 events across many usernames can be password spraying. Filter by Logon Type and source fields to separate a single broken task from a broad attack.

If you’re tracing domain authentication, pair the member server’s 4625 events with relevant domain controller logs. Event 4776 is often useful for NTLM credential validation attempts, and Microsoft’s audit reference lists the common error codes that show up during those validations.

In Event Viewer, open the event, switch to Details, then view Friendly View or XML. Copy the fields into notes so you can compare multiple failures side by side quickly later.

Verification Steps After The Fix

Don’t stop at “I changed something.” Prove the change worked with logs and a quick functional test. This avoids the cycle where the error returns during the next service restart or scheduled run.

1. Trigger the action — Start the service, run the scheduled task, or retry the app sign-in that caused the failure.
2. Look for a 4624 success — In the Security log, confirm a successful logon event for the same account and logon type.
3. Confirm 4625 stops — Filter Security logs for the same account name and confirm new 4625 events no longer appear.
4. Check dependent systems — If the source host was another server or a client device, confirm it no longer retries with old credentials.
5. Document the storage spot — Note where the credential was stored so the next password rotation is clean.

If you still see failures after a clean update, treat it as a second hidden dependency or a second source host. Expand your search window and look for a second Caller Process Name or a second Logon Type tied to the same account.

Advapi Logon Failure can feel vague at first glance. Once you anchor it to Event 4625 and read Status, Sub Status, Logon Type, and Caller Process Name, you can turn it into a short checklist and a fast fix.