Fix SCHED_E_ACCOUNT_INFORMATION_NOT_SET (0X8004130F)

You're staring at 0X8004130F and the task won't run. I've been there. It's frustrating when a task that ran yesterday suddenly breaks. The fix is straightforward: the stored account password for that task got corrupted or wasn't saved properly. We're going to delete the cached credentials and re-apply them.

Step-by-Step Fix: Reset Task Credentials

1. Open Task Scheduler – Press Win + R, type taskschd.msc, hit Enter. You'll see the Task Scheduler Library.
   Expected outcome: The console opens with a list of tasks.
2. Find the broken task – In the left pane, click 'Task Scheduler Library'. Look in the middle pane for your task. If you know the task name, use the search bar at top right (but that's optional).
   Expected outcome: You see the task. Its status column might say 'Disabled' or 'Ready'.
3. Export the task – Right-click the task, choose 'Export'. Save the XML file to your Desktop with a name like broken-task.xml. This gives us a backup and allows us to see the account info.
   Expected outcome: A .xml file appears on your Desktop.
4. Delete the task – Right-click the same task, select 'Delete'. Confirm 'Yes' when asked.
   Expected outcome: The task disappears from the list.
5. Import the task – In the right pane, click 'Import Task...'. Browse to your Desktop, select broken-task.xml, click Open.
   Expected outcome: The 'Create Task' dialog opens, pre-filled with your settings.
6. Re-enter credentials – Click the 'Change User or Group' button. Type the account name (e.g., CONTOSO\User or SYSTEM), click 'Check Names' to validate, then OK. Now check 'Run whether user is logged on or not'. If it's a service account, also check 'Do not store password' – but for regular accounts, leave it unchecked.
   Expected outcome: User field updates. If you checked 'Run whether user is logged on or not', a password prompt appears.
7. Enter password – Type the account password twice exactly. Click OK.
   Expected outcome: Task is created, no error. You return to the Task Scheduler list.
8. Run it – Right-click the task, choose 'Run'. Wait 10 seconds.
   Expected outcome: The 'Last Run Result' column shows 0x0 (success) or another result. If you still get 0X8004130F, double-check the password – it's case-sensitive.

Why This Works

The error code 0X8004130F translates to SCHED_E_ACCOUNT_INFORMATION_NOT_SET. Task Scheduler stores account info in a secure portion of the registry (under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree). When that data gets corrupted – from a password change, a domain trust issue, or a buggy update – the task can't authenticate. Deleting and re-importing forces Windows to re-encrypt and store fresh credentials. It's the nuclear option, but it works 99% of the time.

Less Common Variations

1. The 'Do Not Store Password' Option

If your task runs as SYSTEM or NETWORK SERVICE, you should always check 'Do not store password'. These accounts don't need one – they use the machine account. If you leave it unchecked, Windows may try to save a blank password, which triggers the error. To fix, export-import and check that box.

2. Multiple Tasks with the Same Credential

Sometimes you have dozens of tasks using the same service account. Re-importing each one is tedious. Instead, use PowerShell. Open PowerShell as Admin and run:

$taskName = "YourTaskName"
$user = "CONTOSO\ServiceAccount"
$password = "YourPassword"
$task = Get-ScheduledTask -TaskName $taskName
Set-ScheduledTask -TaskPath $task.TaskPath -User $user -Password $password

This resets the credential without deleting. If the task name has spaces, wrap it in quotes. Expected outcome: The task updates silently. Then test with Start-ScheduledTask -TaskName "YourTaskName".

3. Domain Trust Gone Bad

If the account is from a domain that's no longer trusted (e.g., you migrated to a new domain), the local machine can't validate the SID. Solution: Change the task to use a local account or a different domain account. Export, edit the XML in Notepad – find the <UserId> tag and replace the old domain with the new one. Then import. For example, change OLD\user to NEW\user.

How to Prevent This

• Use service accounts with non-expiring passwords. Domain policies often force password changes every 90 days. If you don't update the task, you get this error. Set the account's password to never expire, or create a scheduled task to re-apply the password monthly.
• Monitor task status. Use a simple script to check for non-0x0 results and email you. Here's a quick one:

$tasks = Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'}
foreach ($t in $tasks) {
    $result = (Get-ScheduledTaskInfo $t).LastTaskResult
    if ($result -ne 0) {
        Write-Host "$($t.TaskName) failed with $result"
    }
}

Run that weekly. It'll catch issues before they cause outages.

One last tip: Always keep a backup of your task exports. When you create a new task, export the XML and save it to a shared folder. If the credential blinks, you can restore in 30 seconds instead of rebuilding from scratch.