HRESULT 0x80041315 (SCHED_E_SERVICE_NOT

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

The Task Scheduler service is installed but stopped. Verify local or remote service state, startup failure and connection target.

Previous	Next
SCHED_E_UNSUPPORTED_ACCOUNT_OPTION	SCHED_E_UNEXPECTEDNODE

SCHED_E_SERVICE_NOT_RUNNING

The installed Task Scheduler service is not running

SCHED_E_SERVICE_NOT_RUNNING is the failure HRESULT 0x80041315 (-2147216619 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x1315. AllStat describes the result as “The Task Scheduler Service is not running.”

Interpretation in Task Scheduler

Microsoft documents this value for TaskService.Connect. It distinguishes an installed scheduler that is not running from an absent installation and from a service that is running but temporarily unavailable or overloaded. In practical terms, this result is returned when a client connects to or invokes Task Scheduler while the service process needed to serve the request is stopped. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.

Likely sources of the condition

The service was manually stopped for maintenance or by policy.
Service startup failed during boot because of a dependency, configuration or system-component problem.
A remote call reached the intended computer while its scheduler service was stopped.
The machine is shutting down, starting up or recovering and the client connected outside the service availability window.
A monitoring or hardening product stopped the service unexpectedly.

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

Observability checklist

Service state, start type and most recent Service Control Manager events.
Task Scheduler Operational and system events from the service startup attempt.
Local versus remote target and the identity used for TaskService.Connect.
Boot, shutdown, update or maintenance timeline.
Whether other scheduler clients can connect after the service state changes.

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.

Verification sequence

Read service state on the target computer rather than inferring it from a remote UI.
If stopped, inspect why it stopped before issuing a start request.
For startup failure, preserve the first service error and any dependency or component failure.
Start the service through supported service management when policy permits.
Reconnect with a new ITaskService object after the service is confirmed running.

Corrective action

A bounded retry after service startup is appropriate. Existing COM proxies may remain disconnected, so recreate the connection rather than repeatedly calling through a stale object. If the service stops again, treat recurrence as a service-health problem instead of extending the retry loop. 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 must not be inferred

This HRESULT does not show that a task is disabled, missing or invalid. It also does not prove the service is uninstalled; <code>SCHED_E_SERVICE_NOT_INSTALLED</code> is the separate installation-state result. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.

Comparison with similar codes

SCHED_E_SERVICE_NOT_AVAILABLE reports that the scheduler cannot currently provide service without asserting a stopped state. SCHED_E_SERVICE_TOO_BUSY means the service is responding but lacks capacity.

Worked scenario

A configuration agent starts immediately after boot and connects before the scheduler service finishes recovering from an update. The agent records stopped state, waits for the service transition, creates a fresh TaskService connection and then registers the task once. A regression test should reproduce this result, 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.