What does HRESULT 0x8004130B (SCHED_E_TASK_NOT_RUNNING) mean?

 
Previous Next
SCHED_E_TASK_NOT_READY SCHED_E_SERVICE_NOT_INSTALLED

SCHED_E_TASK_NOT_RUNNING

No running instance exists for the scheduled task

SCHED_E_TASK_NOT_RUNNING is the failure HRESULT 0x8004130B (-2147216629 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x130B. AllStat describes the result as “There is no running instance of the task.”

Where this HRESULT belongs

The registered task may still exist and may be enabled, but the scheduler cannot match the request to a currently running instance. The result is about execution state, not task registration or the exit code of a previous run. In practical terms, this result is returned when a caller tries to control, stop, refresh or otherwise address an execution that is expected to be active. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.

Typical causes

  • The instance completed naturally between enumeration and the control call.
  • Another administrator, service or timeout policy stopped the run first.
  • The caller retained an instance GUID from an earlier execution and applied it to a later task state.
  • A monitoring cache reported running state after its IRunningTask data had become stale.
  • The task was queued or ready, but it never reached the running state assumed by the caller.

Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.

Evidence to preserve

  • Registered task path, requested instance GUID and the exact control method.
  • Fresh output from IRegisteredTask::GetInstances or ITaskService::GetRunningTasks.
  • Current action, engine process identifier and task state when an IRunningTask object is available.
  • Task Scheduler Operational events around start, completion, cancellation and timeout.
  • The time gap between enumeration and the failed control request.

The decisive question for it is not whether Task Scheduler works in general, but which object, service state, compatibility rule or execution instance owned the failed operation. Before reacting to this result, collect evidence rather than restarting services, rewriting task XML or changing security settings.

A disciplined diagnostic sequence

  1. Refresh the registered task and enumerate running instances again instead of trusting a cached collection.
  2. Compare the target instance GUID with every currently returned IRunningTask object.
  3. Check whether the run completed, failed, was stopped or was never launched after a queued request.
  4. If the caller only needs to prevent future execution, modify task policy rather than pretending a nonexistent instance can be stopped.
  5. Treat disappearance during control as an expected race when completion evidence proves the instance ended normally.

Recovery and retry

Do not retry the same stop request in a tight loop. A retry is useful only after a new running instance is discovered. If the task already completed, record its final state and continue the higher-level workflow; if a new instance started, control that new GUID explicitly. The owner of the higher-level workflow should define whether this result is terminal, retryable after a state change, or converted into an administrative action.

What the code does not establish

This HRESULT does not prove that the task is missing, disabled or broken. It also does not say that the action process never ran; a short-lived instance can finish before management code reaches it. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.

Difference from nearby Task Scheduler results

SCHED_E_TASK_NOT_READY means required task properties are missing, while it means the control path found no active execution. SCHED_S_TASK_RUNNING is the positive state result for an active instance.

Practical scenario

A deployment service enumerates a maintenance task, stores its instance GUID, then asks the task to stop after a health timeout. The maintenance action exits during that interval. Re-enumeration returns no instance, so the service records normal completion instead of repeatedly treating the stale GUID as a fatal scheduler failure. A regression test should reproduce it, assert the code-specific evidence, then change only the decisive condition and verify the expected recovery.

Official Microsoft references

Looking for a different code? Search another status or error code.