0X0004131C

Task Scheduler error 0X0004131C: batch logon failure

Windows Errors Intermediate 👁 6 views 📅 Jun 9, 2026

This SCHED_S_BATCH_LOGON_PROBLEM means the task is registered but can't start because of a bad logon token. Most often it's a stale or blank password in the task's stored credentials.

1. The task's stored password is stale or wrong

This is the fix that works 90% of the time. What's actually happening is that Task Scheduler stores a password hash when you create a task that runs under a specific user account — even if you check "Run whether user is logged on or not". That hash can expire or get out of sync if the user changes their password, or if the account was recently reset by an admin.

The error code 0X0004131C (SCHED_S_BATCH_LOGON_PROBLEM) gets thrown when the scheduler tries to create a logon session for that task and the token validation fails. Windows doesn't tell you the password is bad — it just refuses to start the task and logs this generic-looking error.

  1. Open Task Scheduler (taskschd.msc).
  2. Locate the failing task in the task list.
  3. Right-click it → Properties → General tab.
  4. Under Security options, you'll see the user account. Re-enter the password in both fields, even if you think it's correct — the dialog won't tell you if it's stale.
  5. Click OK. Windows will prompt you again for the password for confirmation.
  6. Now right-click the task → Run to test it immediately.

If the task runs now, it's fixed. The reason step 4 works is that Task Scheduler hashes the password at that moment and stores a fresh token. The old token didn't match the current domain or local SAM hash, so the logon failed.

Real-world trigger: A domain user's password expires, or an admin resets it via Active Directory Users and Computers. The task that ran for months suddenly throws 0X0004131C the next night.

2. The account lacks the "Log on as a batch job" right

If re-entering the password didn't help, the problem is almost certainly that the user account doesn't have the Log on as a batch job user right. This is way more common on Windows Server than on Windows 10/11, but it can happen on any system locked down by group policy or local security policy.

Here's the nuance: Task Scheduler uses a different logon type than interactive logon. When you check "Run whether user is logged on or not", the scheduler tries to log the user on in batch mode. If the user right isn't granted, the logon fails immediately — and you get 0X0004131C.

To check and fix this:

  • On a domain-joined machine: Group Policy Management Console → Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Log on as a batch job. Add the user or a group the user belongs to. Then run gpupdate /force on the target machine.
  • On a standalone machine: secpol.msc → Local Policies → User Rights Assignment → same setting.

After applying the policy change, reboot the Task Scheduler service (net stop schedule && net start schedule) or reboot the machine. Then test the task again.

Why this works: Granting the right doesn't change the task itself — it changes whether Windows Security allows that user to create a non-interactive logon session. Without it, the scheduler can't even start the logon process, so the token never gets created.

3. Corrupted task definition or orphaned SID

Less common, but when you've ruled out passwords and user rights, the task XML itself might be corrupt. This happens after domain migrations, machine renames, or when a user account gets deleted and re-created with the same name but a different SID.

Task Scheduler identifies users by SID, not by username. If the SID stored in the task doesn't match any current account on the system (or in the domain), you get 0X0004131C because Windows can't resolve the logon target.

The fix:

  1. Export the task: schtasks /query /tn "TaskName" /xml > task.xml
  2. Delete the task from Task Scheduler.
  3. Re-create it manually with the correct user account — don't import the XML, because the corrupt SID would come back.
  4. If the task is complex (multiple triggers, actions), consider using schtasks /create /xml task.xml /tn "TaskName" /ru "DOMAIN\User" /rp — but this only helps if the XML is structurally fine and just the SID is stale. I'd still recommend manual re-creation for reliability.

Real-world trigger: A server was migrated from an old domain to a new one, and the scheduled tasks still reference the old domain's SID. The user appears to exist (same name), but the SID mapping is broken.

Quick-reference summary

Cause What to check Fix
Stale password Task Properties → password fields Re-enter password, test
Missing batch logon right secpol.msc or GPO → Log on as a batch job Add user, gpupdate, restart service
Corrupt SID or XML Task might refer to deleted/resolved user Delete and re-create the task manually

Was this solution helpful?

0X0004131C SCHED_S_BATCH_LOGON_PROBLEM Task Scheduler logon failure scheduled task batch logon error task won't run credentials Windows Task Scheduler password error fix 0X0004131C task scheduler task registered but might fail batch logon token expired Task Scheduler password update Windows Server task scheduler error 0x0004131c group policy restricted logon domain user task failed