Fix SCHED_E_SERVICE_NOT_LOCALSYSTEM (0x00001838) on Windows

You double-click a task, hit Run, and Windows spits back 0X00001838 with that mouthful of a message: the Task Scheduler service must be configured to run in the System account to function properly. Annoying, because nothing about your task changed. Something changed the service.

Here's the short version: the Task Scheduler service (its internal name is just Schedule) refuses to do anything unless its logon account is LocalSystem. If someone — a hardening script, a GPO, a well-meaning admin following a CIS benchmark — switched it to NetworkService or a domain service account, every task call fails with 0x1838. The service might even show as Running in services.msc. It's lying to you.

I've hit this on Server 2016 boxes after a security audit, on Windows 10 21H2 after a third-party "optimizer" ran, and once on a Citrix VDA where an image-prep script did it. Same fix each time.

Cause 1: The service logon account isn't LocalSystem (the usual suspect)

This accounts for roughly 9 out of 10 cases. Check it fast: open an elevated Command Prompt and run

sc qc Schedule

Look at SERVICE_START_NAME. If it says anything other than LocalSystem, you've found your problem.

To fix it, you can go through services.msc (find Task Scheduler, Log On tab, select Local System account) — but I prefer the command line because the GUI sometimes greys out the option when a GPO is pushing the setting.

sc config Schedule obj= LocalSystem
net stop Schedule
net start Schedule

Note the space after obj=. That trips people up constantly. Without it, sc throws a syntax error and you'll be staring at it wondering why nothing worked.

Restart the service and try your task again. If it fires, you're done. If the error comes right back within a minute or two, something is resetting the account — go to Cause 2.

Cause 2: A Group Policy or hardening baseline keeps reverting it

This is the one that makes people pull their hair out, because the fix from Cause 1 works for about 90 seconds and then breaks again. Classic sign: you check sc qc Schedule, it's LocalSystem, you blink, check again, it's NetworkService.

Two GPOs are usually responsible:

• Computer Configuration → Windows Settings → Security Settings → System Services — someone set Task Scheduler to a startup mode or account via policy.
• Computer Configuration → Administrative Templates → Windows Components → Task Scheduler — less common, but I've seen a custom ADMX do it.

Run gpresult /h gpreport.html from an admin prompt and search the output for "Schedule". If a GPO shows up, that's your culprit. Either edit the GPO at the domain level (if you control it) or — on a standalone box — check the local policy:

gpedit.msc

Then drill into the System Services path above and set Task Scheduler to Not Configured, or explicitly to Automatic / LocalSystem.

On Server 2019 and 2022, Microsoft's own security baselines shipped with some builds set Task Scheduler's startup to Manual, which is technically fine as long as the account is still LocalSystem. Don't confuse startup type with logon account. They're separate settings and only the account matters for this error.

If you're in a domain and can't touch the GPO, open a ticket with whoever owns your baseline. This one isn't fixable locally long-term.

Cause 3: Registry permissions on the Task Scheduler keys got mangled

Rare, but when it happens it's ugly. The Schedule service reads its config from HKLM\SYSTEM\CurrentControlSet\Services\Schedule. If an installer or a botched ACL script stripped SYSTEM's Full Control on that key, the service can't even read its own account setting, and Windows reports 0x1838 because from the service's perspective the account looks invalid.

Check the key's permissions:

reg query HKLM\SYSTEM\CurrentControlSet\Services\Schedule /s

If you get an access denied or the output is empty, fire up regedit.exe, right-click the Schedule key, Permissions, and make sure SYSTEM has Full Control. If SYSTEM isn't even listed, add it and grant Full Control. Also confirm Start is set to 2 (Automatic) and ObjectName is LocalSystem. If the ObjectName value is missing entirely, create it as a REG_SZ with value LocalSystem.

Reboot after this one — service restarts alone don't always pick up a fixed ACL.

One thing not to bother with

I've seen people suggest re-registering the task scheduler DLLs or running sfc /scannow for this error. Skip it. 0x1838 is a configuration problem, not a corruption problem, and SFC will burn 20 minutes finding nothing. Save that for actual file corruption errors.

Quick reference

Nine times out of ten, one sc config line and a service restart puts you back in business. If it keeps reverting, look upstream at policy — that's where the real fight is.