Task Scheduler result codes: 0x1, 0x41303 and what they mean
When a scheduled task does not run, the Last Run Result column is the first place you look — and the value there tells you almost nothing on its own. Rather than copy a code table, I built tasks that fail in different ways, ran them, and recorded what came back. Two things fell out of that: **0x1 covers two completely different problems** with no way to tell them apart, and the command line never shows you the hex form that every search result is written in.
If Task Scheduler is more ceremony than you need, keeping a list of programs and launch times is another way to do it.
Do not memorise codes — find out where the number came from
Most of what lands in Last Run Result is the exit code of the program your task ran, copied straight through. It is not a diagnosis the scheduler produced; it is whatever your program returned.
There are two exceptions. Anything starting 0x413 is the scheduler describing its own state (running, never run, and so on), and 0x8007 is a Windows system error code. Separating those three families gets you halfway.
Every value here came from building tasks on Windows 11, running them, reading the result, and then deleting them. Nothing is quoted from a table.
0x1 — the most common and the most ambiguous
0x1 is the most searched of these codes, and there is a good reason for that: two unrelated situations produce it.
The obvious one first. A batch file that ends with exit /b 1 gives you 1. End it with 3 and you get 3. The program's own value comes straight through.
ok.bat (exit /b 0) -> 0
fail1.bat (exit /b 1) -> 1
fail3.bat (exit /b 3) -> 3Now the other one. Point the task at a batch file that does not exist and you also get 1. I built exactly that task and ran it; the result was 1. Whether your script failed or never started at all, the code is the same.
Switching to an .exe shows why. A missing .exe returns -2147024894, which is 0x80070002, the system's file-not-found.
A .bat is not launched by the scheduler directly — cmd.exe picks it up. When cmd cannot find the file, it exits with its own code, 1. Run a missing batch file from a command prompt and you see the same thing:
cmd /c "C:\no\such\does_not_exist.bat"
echo %ERRORLEVEL%
REM -> 1So when you see 0x1, check the path before you touch the script. Copy the path out of the task's Program/script box and paste it into Explorer. If it does not open, the script was never the problem.
0x41301, 0x41303, 0x41306 — states, not failures
Values beginning 0x413 are the scheduler reporting the state of the task. They are not exit codes from anything, and reading them as errors sends people off to debug a script that is fine.
| Hex | What schtasks prints | Meaning | What to do |
|---|---|---|---|
0x41301 | 267009 | Currently running | Wait. If it never finishes, check the stop-after setting on the Settings tab |
0x41303 | 267011 | Has never run | The trigger has not fired. Check the Triggers and Conditions tabs |
0x41306 | 267014 | Task was terminated | Someone stopped it, or it hit the time limit |
0x41301 is the easy one to misread. Start a task that takes 30 seconds and query it immediately and this is what you get. It is not a failure — it has simply not finished, and the real exit code replaces it when it does.
0x41303 is not "it ran and failed" but "it never ran", which puts the cause somewhere else entirely. If the scheduled time has passed and you still see this, the trigger did not fire: check that the task is enabled and that nothing on the Conditions tab (power settings, network) is holding it back.
The command line never shows you hex
This was the most irritating part of the exercise. The value on screen and the value from the command line are written differently.
schtasks /query /tn TaskName /fo LIST /v
# Last Result: 267011
Get-ScheduledTaskInfo -TaskName TaskName | Select-Object LastTaskResult
# LastTaskResult : 267011Both print decimal. Every piece of documentation and every search result is written in hex (0x41303), so pasting 267011 into a search box finds nothing at all. They are the same number.
# decimal to hex
"0x{0:X}" -f 267011
# -> 0x41303
# negative values convert the same way
"0x{0:X}" -f -2147024894
# -> 0x80070002Codes starting with 8 come out negative in decimal. If you see something like -2147024894, run it through the conversion above. The leading 8007 marks it as a Windows system error and the last four digits are the actual cause.
Where to look, by code
- 10 but nothing happened — the program exited cleanly. If it has a window, it most likely ran in a session you cannot see. Check the security option for running only when the user is logged on.
- 20x1 — check the path first. If the path is right, run that script from a command prompt and see whether you get the same 1.
- 30x80070002 — the file is not there. A typo, a moved file, or a network drive that was not connected are the usual causes.
- 40x41301 — it is still running. Query again in a moment.
- 50x41303 — it never ran. Look at the Triggers and Conditions tabs.
- 60x41306 — something ended it. Check "Stop the task if it runs longer than" on the Settings tab.
Creating tasks in the first place, windows that never appear, and the laptop power conditions are covered in the other post on this blog, 'How to Schedule a Program on Windows — Task Scheduler and Why It Does Not Run'.
One more thing that cost me a minute
When creating a task with schtasks, the start date (/sd) follows your system's date format. On this machine 12/31/2030 was rejected and only 2030/12/31 was accepted.
schtasks /create ... /sd 12/31/2030
ERROR: Invalid Start Date (Date should be in "yyyy/mm/dd" format).The error does tell you which format it wants, so it is a quick fix — but it is a common place to get stuck when borrowing a command from someone whose machine is set up differently.
FAQ
Q. I get 0x1 but the script runs fine when I double-click it.
Usually a path or an account difference. Copy the path out of the task and open it first. If the path is right, check whether the Start in box is empty — a script that looks for files using relative paths will fail without it, because a scheduled run does not start in the folder you expect.
Q. Searching for 267011 returns nothing.
It is decimal. Search for 0x41303 instead. You can convert it in PowerShell with "0x{0:X}" -f 267011. A negative number means a 0x8007xxxx Windows system error, converted the same way.
Q. The result stays at 0x41301 and never changes.
The task is still running. Either the program never exits, or it is sitting waiting for input nobody will give it. Turning on "Stop the task if it runs longer than" on the Settings tab cleans it up when the limit passes, and the result then becomes 0x41306.
Q. The same task gives 0 some days and 0x1 on others.
The program is returning different exit codes depending on what it finds. Have the script log what it does — for a batch file, appending > C:\log.txt 2>&1 to the command captures the output so the next failure leaves evidence behind.
If Task Scheduler is more ceremony than you need, keeping a list of programs and launch times is another way to do it.