| Previous | Next |
| ERROR_NO_BROWSER_SERVERS_FOUND | ERROR_LOG_SECTOR_INVALID |
SCHED_E_SERVICE_NOT_LOCALSYSTEM
The Task Scheduler service must be configured to run in the System account to function properly. Individual tasks may be configured to run in other accounts.
SCHED_E_SERVICE_NOT_LOCALSYSTEM is Win32 error 6200 (0x1838) and belongs to Task Scheduler 1.0 service identity. The system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.
Interpret this result at the API boundary that returned it. Capture it before logging, cleanup, or another Windows call can replace the thread-local last-error value. Compare the recorded inputs with the documented precondition for Task Scheduler 1.0 service identity rather than starting with a broad system repair.
Where the result appears
- This result can surface during legacy Task Scheduler service startup.
- This result can surface during Task Scheduler 1.0 interfaces on older systems.
- It can surface during service-account hardening that changes the scheduler identity.
- It can surface during migration of scheduled tasks from a legacy installation.
Likely causes
- The Task Scheduler service is configured under an account other than LocalSystem.
- Service configuration was changed by policy or manual hardening.
- An image captured an unsupported legacy service identity.
- A security template altered the service logon account.
Diagnostic sequence
Diagnosis of it starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. Identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. This ordering matters in Task Scheduler 1.0 service identity because a blind retry can hide stale state or repeat a non-idempotent change.
- Record Task Scheduler service account and startup type.
- Record Windows version and scheduler API generation.
- Record System and TaskScheduler event logs.
- Record service configuration change history.
- Record individual task principals, which are separate from service identity.
Correlate it with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for it should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 6200, hexadecimal 0x1838, and the producing API even when a localized message is also shown.
State boundary to prove
The decisive boundary for it is whether the Task Scheduler service is configured under an account other than LocalSystem. Prove or disprove that proposition using Task Scheduler service account and startup type together with Windows version and scheduler API generation. When observations for it disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.
A focused validation for it should recreate the relevant part of this situation: a hardening script changes the legacy scheduler service to a custom account. Reverting the service identity while leaving task-specific accounts intact restores operation. The negative case should keep the scheduler service under the unsupported account and confirm error 6200; the recovery case should change only the service logon identity and verify the same task operation.
Handling, retry, and recovery
Restore the Task Scheduler service to its supported LocalSystem identity for the affected legacy implementation, then configure individual tasks with their intended principals. Back up task definitions before changing service configuration.
Retry it only after evidence shows a change in Task Scheduler 1.0 service identity. Initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after it, query completion state explicitly.
What to log for support and telemetry
- Log decimal 6200, hexadecimal
0x1838, and the producing API. - Log the target object and observed Task Scheduler 1.0 service identity state.
- Log caller identity, process and thread IDs, machine or node identity, and UTC time.
- Log attempt number, elapsed time, previous result, and any partial side effect.
- Retain the first lower-level or component-specific error before Win32 translation.
Difference from nearby codes
The error concerns the account running the scheduler service itself; it does not require every scheduled task to run as LocalSystem.
Practical example
A hardening script changes the legacy scheduler service to a custom account.
Developer and administrator guidance
Code that handles it should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. Administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 6200, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.
References
- Microsoft: System Error Codes (6000–8199) — reference for error 6200.
- Microsoft: Task Scheduler service — reference for error 6200.
- Microsoft: Task Scheduler security contexts — reference for error 6200.
Looking for a different code? Search another status or error code.