Fix 0x80041310 Task Scheduler Account Error

Quick answer

The task is set to run under a local or domain account whose saved password is stale, or the account was renamed, disabled, or deleted. Open Task Scheduler, go to the task's properties, and re-enter the credentials — or change the task to run as NT AUTHORITY\SYSTEM if it doesn't need user profile access.

Why this error shows up

SCHED_E_ACCOUNT_NAME_NOT_FOUND (0x80041310) is Windows telling you it can't confirm the account the task is configured to use actually exists and can log on. Task Scheduler stores a username and a cached credential blob with each task. When that blob no longer matches reality — the password changed, the account got disabled, the machine was renamed, or you restored a task XML exported from another server — the scheduler refuses to run the task and drops this code in the Task Scheduler event log and in the Last Run Result column.

The most common real-world trigger: an admin changes a service account password in Active Directory, and a dozen scheduled tasks across the org silently stop running overnight. Nobody notices until a nightly backup or report job is missing three days later. The account still exists, but the cached credential inside each task is now garbage.

Other triggers I've seen in the field: a laptop gets renamed during a domain migration, so the old MACHINENAME\localuser reference is dead. A task imported from a decommissioned server carries a DOMAIN\oldservice account that was deleted six months ago. Or somebody disabled an account in AD and forgot three tasks were pinned to it.

Fix it step by step

Open Task Scheduler. Press Win+R, type taskschd.msc, hit Enter. You should see the Task Scheduler console with the task tree on the left.
Find the failing task. Click Task Scheduler Library and scan the Last Run Result column for 0x80041310. If it's not visible, right-click the column header and enable it. Double-click the task to open its properties.
Go to the General tab. Look at the When running the task, use the following user account field. Note the exact account name — including the domain or machine prefix.
Verify the account still exists. For a domain account, run net user username /domain from an elevated command prompt. You should see account details, not "The user name could not be found." For a local account, drop the /domain switch.
Check whether it's disabled. In the output above, look at Account active. If it says No, either re-enable the account or switch the task to a different one.
Re-enter the password. Back in the task's General tab, click Change User or Group, type the same account name, click Check Names, then OK. When prompted, type the current password. Click OK to save. This rewrites the cached credential.
Confirm the fix. Right-click the task and choose Run. The Last Run Result should flip to 0x0 (success) within a few seconds. If you still see 0x80041310, jump to the alternative fixes below.

If the task is set to Run whether user is logged on or not, Windows needs the stored credential. If it's set to Run only when user is logged on, no password is stored and you'll rarely hit this error at all — worth checking on the General tab.

If re-entering the password doesn't stick

Sometimes you punch in the password, click OK, and the task still fails. Here's what's actually going on and how to get past it.

The account is a Microsoft account or Azure AD account. These don't play well with stored credentials in Task Scheduler. The real fix is to create a local service account on the machine and run the task under that. Yes, it's more work. No, there's no clean workaround.
The task needs no user profile. If it's a script that just hits a network share or runs a maintenance routine, switch it to NT AUTHORITY\SYSTEM. On the General tab, click Change User or Group, type SYSTEM, click Check Names, OK. Leave the password fields blank. SYSTEM has no password to expire, so this error can't recur.
The task was imported from another machine. The stored credential blob is tied to the original machine's DPAPI keys, so it'll never validate here. Delete the task and recreate it, or export the XML, edit the <UserId> node, and re-import. Honestly, recreating is faster.
Group Policy is reapplying the broken credential. If the task was deployed via GPO preferences, your manual change gets overwritten at the next policy refresh. Check gpresult /h gpreport.html for a scheduled task preference pointing at the dead account.
Corrupted task file. Rare, but real. Navigate to C:\Windows\System32\Tasks\ and locate the file matching the task's folder path. Delete it, then re-import the task from a known-good XML. Restart the Task Scheduler service (net stop schedule && net start schedule) before retesting.

Prevention

Every scheduled task that stores a password is a future outage waiting for the next password rotation. The single best habit: for any task that doesn't need user-level access to a profile, shared drive, or user-specific certificate, run it as SYSTEM. That covers most maintenance jobs, scripts hitting UNC paths, and anything that talks to a database with its own auth.

For the tasks that genuinely need a user account — think things that touch mapped drives or user certs — use a dedicated service account with a password that never expires, and document every task pinned to it. When you rotate that password, run this from an elevated prompt to flag every affected task up front:

schtasks /query /fo LIST /v | findstr /i "TaskName RunAs"

That output gives you a full inventory of tasks and the accounts they run under. Keep it in your runbook next to the service account. Next time the password changes, you'll know exactly which tasks to update instead of waiting for the 0x80041310 errors to pile up in the event log.