| Previous | Next |
| SCHED_S_TASK_READY | SCHED_S_TASK_DISABLED |
SCHED_S_TASK_RUNNING
Scheduled task currently has a running instance
SCHED_S_TASK_RUNNING is HRESULT 267009 (0x00041301) from winerror.h. AllStat describes it as “The task is currently running.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the Task Scheduler state query, this result means that the task is currently running. Treat it as a distinct branch whose postcondition must be proven before subsequent operations begin.
Where the status is encountered
- Task Scheduler status monitoring; log the exact method and object state instead of interpreting the constant outside that contract.
- Deployment or maintenance task validation; log the exact method and object state instead of interpreting the constant outside that contract.
- Automation that reads task state before starting work; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
Evidence and telemetry
- preserve running instance GUID.
- preserve engine process identifier.
- preserve start time and duration.
- preserve multiple-instance policy.
- preserve current action and task history event.
Also record sched_s_task_running_operation, sched_s_task_running_state_before, sched_s_task_running_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Evidence for it should be reproducible but sanitized, with sensitive buffers represented by length and hash.
What must be true before accepting it
Verify that the returned instance is genuinely active and the caller does not confuse queued, ready, or stale historical state with execution. The caller should make the acceptance test for it explicit in code and telemetry.
Inspect the current generation of every affected object before deciding what happens next.
Correct handling and recovery
Inspect running instances, start time, engine PID, and last heartbeat or operational event. Wait, monitor, or stop through Task Scheduler APIs rather than launching a duplicate instance outside the service.
Retry it only when a documented input or state has changed. Distinguish protocol continuation from retrying the entire high-level operation.
Difference from nearby results
SCHED_S_TASK_READY is idle and eligible; SCHED_S_TASK_TERMINATED describes the previous run ending by user action.
Exact handling of it matters because a generic success path cannot express its required next action.
Practical scenario
An administrator checks a maintenance task before deploying an update. The status is running, so deployment waits for the instance ID to finish instead of starting a second maintenance process.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: Task Scheduler error and success constants — official Microsoft material used to interpret it.
- Microsoft: Task Scheduler reference
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.