Quick answer for advanced users: Error 0x41306 is informational—it just logs that the task was stopped by a user or a script. Check who ran taskkill or clicked "End" in Task Scheduler. No real fix needed unless it keeps happening.
You see SCHED_S_TASK_TERMINATED (0x00041306) in the Task Scheduler's "Last Run Result" column. Your first thought: something broke. But what's actually happening here is the task ran, started doing its job, and then got stopped before it finished. That stop came from outside—someone clicked the "End" button in the Task Scheduler GUI, or ran schtasks /end from a command prompt, or a script called taskkill on the process. Windows just logs that event with this code.
I've seen this on Windows 10 and 11, usually after a user accidentally kills a task while trying to close a different window. It's also common when IT pushes remote scripts that stop tasks before maintenance windows close. The error code itself doesn't mean the task failed—it means it didn't complete naturally, which can leave your task's work half-done. For example, a backup task terminated mid-copy might leave a corrupted file.
Fix Steps: Find and Stop the Killer
- Check Event Viewer for the termination source.
Open Event Viewer (eventvwr.msc). Go to Windows Logs > System. Filter by Event ID 129 (Task Scheduler terminated task). The log tells you the process ID and the user account that initiated the termination. If it's SYSTEM, a system policy or script did it. If it's your own user, you probably clicked the wrong thing. - Look at the task's settings.
Open Task Scheduler (taskschd.msc). Find the task. Right-click > Properties. Go to the "Settings" tab. Check "If the running task does not end when requested, force it to stop". If that's checked, the system will kill the task after the timeout. Uncheck it to let tasks finish naturally even if something tries to stop them. - Check for conflicting scheduled tasks.
If two tasks try to run the same program, one might kill the other. Open Task Scheduler, look at the Trigger and Actions of the failing task. Also check if there's another task with the same program path. Right-click each > Export as XML, compare them. If they share an executable, one might include a/terminateflag in the arguments. - Review your startup scripts and group policies.
Rungpresult /h gp.htmlto export your applied group policies. Search for "scheduled task" policies. Look for settings like "Terminate tasks that run longer than X minutes". If you find one, either adjust the timeout or reconfigure the task to finish faster. - Test the task manually without interference.
Right-click the task > Run. Don't touch anything. Let it finish. After it completes, check Last Run Result. If it shows 0x0, the task works fine. If it shows 0x41306 again, something outside the task is killing it—likely a script or policy.
Alternative Fixes If the Main Steps Fail
If you still see the error after all that, the cause is probably a service or scheduled task that runs on a timer and calls taskkill. A common culprit is third-party antivirus or system optimization tools. Temporarily disable any such tool one at a time. Reboot after each disable, then run the failing task again. I've seen Norton and CCleaner do this.
Another option: recreate the task from scratch. Export the old task as XML (schtasks /query /xml /tn "TaskName" > backup.xml). Delete the task. Create a new one with the same settings but a different name. Sometimes the task's internal record gets corrupted and Windows misinterprets a normal completion as a termination.
Prevention Tip
Don't use the "End" button in Task Scheduler unless you really mean it. If you need to stop a task temporarily, disable it instead by right-clicking > Disable. That prevents accidental kills. Also, avoid running taskkill /f /im mytask.exe in scripts unless you specifically want to stop that task—and if you do, make sure the script doesn't run at the same time as the task.
If the error appears on a server with multiple admins, set up an audit policy to log who ends tasks. Run auditpol /set /subcategory:"Other Object Access Events" /success:enable and then check Security logs for Event 4663 with access mask "Terminate". That tells you exactly which user did it.