| Previous | Next |
| SCHED_E_ACCOUNT_DBASE_CORRUPT | SCHED_E_UNKNOWN_OBJECT_VERSION |
SCHED_E_NO_SECURITY_SERVICES
The target platform does not provide legacy scheduler security services
SCHED_E_NO_SECURITY_SERVICES is the failure HRESULT 0x80041312 (-2147216622 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x1312. AllStat describes the result as “Task Scheduler security services are available only on Windows NT.”
Contract boundary
This is a historical platform result. Microsoft protocol documentation associates it with non-NT Windows implementations such as Windows 95, Windows 98 and Windows Millennium Edition. Modern code should treat its appearance as a clue about a legacy endpoint, compatibility path or misreported remote target. In practical terms, this result is returned when Task Scheduler 1.0 account-security functionality is requested on a platform that does not implement the required Windows NT security model. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Conditions that produce it
- A Task Scheduler 1.0 client is intentionally managing a historical non-NT Windows system.
- The caller selected a legacy API path even though current Task Scheduler 2.0 interfaces are required.
- A remote endpoint or emulator reports an old scheduler implementation without NT account services.
- The displayed computer identity differs from the endpoint that actually returned the HRESULT.
- A wrapper preserved an old symbolic code after translating a different platform failure.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Telemetry that matters
- Actual remote operating-system family and scheduler protocol version.
- Whether mstask.h Task Scheduler 1.0 or taskschd.h Task Scheduler 2.0 interfaces are in use.
- The exact account-information method and target computer.
- Raw RPC or COM error value before framework translation.
- Application compatibility settings and any emulation layer involved.
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.
Investigation workflow
- Identify the real endpoint and its Windows generation from the same network context as the scheduler call.
- Confirm whether account-security operations are being issued through deprecated 1.0 interfaces.
- For supported current Windows, migrate the workflow to Task Scheduler 2.0 instead of adding legacy fallbacks.
- If historical interoperability is intentional, document that the platform cannot provide the requested security contract.
- Remove misleading credential retries because credentials cannot create a missing operating-system security facility.
Safe remediation
There is no useful retry until the API path or target platform changes. Use an operating system and scheduler API that support the intended principal model. For a deliberately unsupported legacy target, disable the security-dependent feature and surface a clear compatibility message. 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.
Avoid the wrong conclusion
The code is not equivalent to a wrong password, missing account or stopped service. It describes absence of the security-service capability expected by the legacy scheduler operation. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.
How to distinguish related results
SCHED_E_ACCOUNT_NAME_NOT_FOUND validates a named account, and SCHED_E_ACCOUNT_INFORMATION_NOT_SET concerns stored data for one task. It is a platform capability mismatch.
Example from operations
A maintenance utility built around Task Scheduler 1.0 is pointed through an old compatibility gateway. Account configuration returns this HRESULT. Endpoint discovery reveals a non-NT legacy scheduler, so the utility blocks secure task creation instead of asking the operator to retype credentials. 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
- Microsoft: Task Scheduler error and success constants
- Microsoft: Task Scheduler protocol behavior
- Microsoft: Task Scheduler 1.0 interfaces
- Microsoft: Task Scheduler 2.0 interfaces
Looking for a different code? Search another status or error code.