Stop-ScheduledTask leaves child processes running; Start-ScheduledTask is ignored while the task shows Running

Restarting scheduled tasks: two behaviours that break scripted restarts

These two behaviours were found while scripting restarts of long-running services that run as scheduled tasks. They are separate from the default 72-hour execution limit on tasks, which is covered in another article.

Stop-ScheduledTask ends the supervisor, not the process it started

A task whose action is a supervisor script (a PowerShell loop or a small launcher) that spawns a worker, for example a Python process, was stopped with Stop-ScheduledTask. The supervisor ended; the worker process kept running. Starting the task again then launched a second worker alongside the first.

Two projects saw this:

• A recorder with a supervisor and a processing child: Stop-ScheduledTask stopped only the supervisor. The fix was to give the child the supervisor's process id in an environment variable (a variable such as PARENT_PID) and have the child check periodically whether that process still exists, exiting when it does not.
• A worker started by a PowerShell loop that restarts its Python process 20 seconds after the process dies: after Stop-ScheduledTask, a stray run appeared. The note attributes the stray run to the loop surviving the stop and relaunching Python; it describes this as the likely cause, not a confirmed one. The workaround was to stop the task and then also kill the loop's PowerShell process and the Python process by matching command-line text (a result-file name).

A web service run the same way behaved similarly: stopping its task left the virtual-environment Python processes alive, so the restart procedure kills those processes explicitly.

Why the child survives was not investigated. Windows has no automatic kill-on-parent-exit for ordinary child processes unless the task or parent uses a job object with that setting, so a supervisor that is ended abruptly leaves its children orphaned. That explanation is an assumption consistent with the observations.

Pattern that worked

The child polls for the parent:

• The supervisor sets PARENT_PID=<its own pid> in the child's environment before launching.
• The child's main loop tests whether a process with that id still exists (for example, a periodic check in the same loop that does its work) and exits when it does not.

This makes "stop the task" also stop the child within one polling interval.

Start-ScheduledTask is ignored while the task still shows Running

After killing a service's processes, Start-ScheduledTask was called immediately. It was ignored twice and the service stayed down. The task's state still read Running because Task Scheduler had not yet noticed that the processes had gone, and a start request against a task in that state does not start a new instance with the task's default "do not start a new instance" behaviour.

The second explanation is inference; the observation is that the immediate start did nothing and the service stayed down.

Restart procedure that fixed it

A small script did the steps in order:

• Move the new file into place.
• Kill the service's processes (the venv Python processes, since stopping the task leaves them).
• Poll (Get-ScheduledTask -TaskName <name>).State until it is no longer Running.
• Call Start-ScheduledTask.
• Poll until the service's listening port accepts connections, and treat a timeout as a failure.

The result was checked afterwards by comparing the deployed file's MD5 hash with the local copy.

LastTaskResult 267014

The same hosts showed LastTaskResult 267014 (0x41306, SCHED_S_TASK_TERMINATED) when a task was killed by its execution time limit; that case, and the 72-hour default, are described in the existing article on silent 72-hour termination. A task that has been stopped by Stop-ScheduledTask or whose processes were killed by hand may show the same code; this was not checked separately.