Additional Data: Error Value: 2147943726 | Fix It Fast

If a scheduled task says it “failed to start” and shows additional data: error value: 2147943726, the task didn’t get far enough to launch your program. It stopped at the “who runs this task” layer: logon, token creation, or handing off the start request.

You might see it after a password change, a service account change, or a policy refresh. Many reports tie the message to account credentials and Task Scheduler logon behavior. Stack Overflow discussion and Microsoft Q&A are solid starting points.

Additional Data: Error Value: 2147943726 In Task Scheduler

Task Scheduler is picky about how it stores and uses credentials. When you set a task to run in the background, Windows often needs a stored password (or a managed credential type) to create the logon session that will run the task.

When that stored credential is missing, stale, blocked by policy, or no longer matches the account, the task can fail before the action runs. That’s why you can see the error even when your script, EXE, or command works fine if you double-click it.

On servers, the message often appears in Event Viewer under Microsoft-Windows-TaskScheduler/Operational. The event text may mention LogonUserExEx or “failed to log on,” matching reports from admins troubleshooting the same code. Super User thread

What The Code Means In Plain Terms

The decimal value 2147943726 maps to the HRESULT 0x800705B4. Microsoft commonly describes 0x800705B4 as “This operation returned because the timeout period expired.” Microsoft Q&A thread on 0x800705B4

In Task Scheduler cases, the “timeout” angle can be misleading. The task often isn’t timing out because your script is slow. It can time out because Windows can’t finish the logon flow, can’t reach a domain controller in time, can’t decrypt stored credentials, or can’t get the right token because a required right is missing.

So treat this error like a “task could not start under that identity” signal. Fix the identity, the stored credentials, and the rights first. Then, if the task starts but fails later, you can move on to script and path issues.

Most Common Causes That Trigger The Error

Several root causes recur across Windows versions. The list below matches what admins report most often when the task action never launches.

• Password changed — The task still has the old password stored, so the background logon fails. Many fixes boil down to re-entering credentials or reselecting the account. Reference
• Account renamed or moved — UPN, SAM account name, or domain details changed, and the stored identity no longer matches what Task Scheduler expects.
• Missing logon rights — Local security policy or GPO removed “Log on as a batch job” (SeBatchLogonRight) from the account, blocking scheduled tasks from creating a logon session.
• Credential storage blocked — Settings that stop Windows from storing passwords for scheduled tasks, or tasks configured with “Do not store password,” can break “run whether user is logged on or not” tasks.
• Network or DC reachability lag — Domain accounts may fail if the server can’t reach a domain controller quickly during task startup, which can present as a timeout in the scheduler layer.
• Running as a managed service account — gMSA and MSA setups need the right principal configuration. If the task is registered with the wrong logon type or missing rights, it can fail to start. PowerShell discussion

Fix Steps That Work In Most Setups

Work from identity and logon settings outward. These steps target the layer that throws additional data: error value: 2147943726 most often.

1. Confirm the task runs interactively — Sign in as the same account (or use Run as different user) and launch the exact command line. If it fails here, fix paths, permissions, or dependencies first.
2. Re-enter the account on the General tab — Open Task Scheduler, open the task, select Change User or Group, reselect the same account, then save. This forces Task Scheduler to refresh identity binding that can get stale after account changes. Reference
3. Update the stored password — If the task uses a normal domain or local user and is set to run in the background, retype the password when saving. If the password was rotated, this step often clears the error. Reference
4. Check “Run whether user is logged on or not” — If you need background execution, keep this enabled. If you do not need it, switch to “Run only when user is logged on” as a test, since it removes the stored-password requirement.
5. Grant Log on as a batch job — On the target machine, open Local Security Policy, go to Local Policies → User Rights Assignment, then add the account to Log on as a batch job. In domains, check the linked GPO that manages this right so it persists.
6. Review task settings that block credentials — In task properties, verify Do not store password is not selected for a task that must run while you are signed out.
7. Retry with a clean principal — Create a new simple task that runs cmd.exe /c whoami > C:\Temp\task-test.txt under the same account and settings. If even that fails, the issue is identity, rights, or policy, not your script.

What to do if the task is created by script

If you register tasks through PowerShell or schtasks.exe, the logon type and principal fields matter. A task created with one set of flags can run on your machine and fail on another where policy differs.

• Match the logon type to the account — For normal user accounts, “Password” logon types tend to be reliable for background tasks. For gMSA, use the service account pattern that does not rely on a typed password.
• Set RunLevel explicitly — If you need admin context, set “Run with highest privileges.” If you do not need it, leave it off to avoid UAC-related friction.
• Use absolute paths — A task running in session 0 may not inherit the same working directory. Use full paths for EXEs, scripts, and output files.

Server And Domain Scenarios That Need Extra Checks

On domain-joined servers, this error can pop up after changes that look unrelated. Below are checks that matter more on servers than on a single-user PC.

Service accounts with password rotation

If your org rotates passwords on a schedule, stored credentials in Task Scheduler go stale fast. You can reduce breakage by using a group managed service account (gMSA) when it fits, since gMSA passwords are handled by Active Directory and not typed into the task.

If you must use a normal account, plan a reset step after each rotation. That can be as simple as re-saving tasks with the new password, or recreating tasks through automation that updates the credential at the same time.

DC connectivity and slow start windows

A task triggered “At startup” or right after boot can fail if the machine is still bringing up networking. If the account is a domain account, Task Scheduler may try to reach a domain controller during logon, hit delays, then surface 0x800705B4.

• Add a startup delay — In the trigger settings, set a delay of a few minutes so networking is ready before logon is attempted.
• Test with a local account — If a local account starts cleanly, the path is clear: this is a domain logon timing issue, not a script issue.
• Check DNS and time sync — Kerberos is sensitive to time drift. If the server clock is off or DNS can’t resolve DCs, logon can stall and fail.

BITS, downloads, and network access under the task token

Some tasks run fine until they need network access, then they hang at start or shortly after. Some BITS scheduled tasks fail with error value 2147943726 when the task identity, token rights, or access path is wrong for the transfer context

If your task pulls from a share or web endpoint, confirm the account has access, and confirm it can reach the resource under the same token the scheduler uses. A quick test is to run a one-line task that writes dir \\server\share output to a file. If it can’t list the share, fix permissions or use a credential method that matches your org’s access rules.

Use This Table To Diagnose Faster

If you want a fast route, match what you see to the rows below, then apply the fix and rerun the task.

What You See	Likely Cause	Fast Fix
Task fails right away; action never starts	Stored password is wrong or missing	Open task, re-enter credentials, save, run again
Event mentions LogonUserExEx	Logon rights or policy blocks batch logon	Grant Log on as a batch job to the account
Fails only after password rotation	Task still holds the old password	Update the password in the task or move to gMSA
Fails at boot but works later	Domain logon stalls early in startup	Add a trigger delay and confirm DC reachability
Works manually, fails on schedule	Different token, working dir, or rights in session 0	Use full paths, set Start in, review RunLevel

Confirm The Root Cause Before You Move On

Run the task manually, then check History for both “Task started” and “Action started.” If action never starts, it’s still a logon issue.

• Review TaskScheduler Operational — Match event time stamps to your run.
• Run a tiny test action — whoami to a file confirms the token.
• Set Start in — Avoid System32 as the working folder.

Prevent Repeat Failures And Confirm The Fix

Once you get past additional data: error value: 2147943726, lock in a setup that stays stable across updates and account changes.

Keep the task action line short and fully explicit.

• Prefer managed identities where possible — gMSA removes the “typed password stored in task” weak spot for many domain scenarios.
• Write a log on every run — Have the script write a timestamped line to a file at the first line of execution. If the log never appears, you know the scheduler layer is still failing.
• Use Task History and the Operational log — Turn on Task History, then compare “Task started” events to “Action started” events. A gap points back to identity and logon.

If you still get the same message after the steps above, rebuild the task from scratch with the same command and a fresh principal. Then run the task on demand, and let the next scheduled trigger fire. If both runs work, you’re set now.