| Previous | Next |
| SCHED_E_CANNOT_OPEN_TASK | SCHED_E_ACCOUNT_INFORMATION_NOT_SET |
SCHED_E_INVALID_TASK
The object is invalid or is not a Task Scheduler task
SCHED_E_INVALID_TASK is the failure HRESULT 0x8004130E (-2147216626 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x130E. AllStat describes the result as “The object is either an invalid task object or is not a task object.”
Interpretation in Task Scheduler
This is stronger than a simple open failure. The selected object exists or data was supplied, yet its structure, type or internal references do not form a task object acceptable to the scheduler path in use. In practical terms, this result is returned when the scheduler has obtained object data or an interface request but cannot treat the object as a valid task definition. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Likely sources of the condition
- A legacy.JOB object is truncated, contains invalid offsets or has an unreadable application-name field.
- The caller requested a task interface for storage that belongs to another object type.
- A deployment copied task storage without completing registration through the scheduler service.
- Binary or XML task data was modified by a non-scheduler tool and no longer satisfies the expected format.
- A deserializer accepted bytes from the wrong task API generation and passed them into a legacy operation.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Observability checklist
- Task name, API generation and requested COM interface identifier.
- A byte-preserving copy or exported XML of the failing object before remediation.
- Object length, version fields and any parser or protocol validation details.
- The registration method and installer version that created the task.
- Results from opening the same task through the Task Scheduler user interface or a current 2.0 API client.
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
- Verify that the identifier points to a scheduler task rather than an arbitrary persisted COM object or file.
- Separate XML well-formedness and schema validation from legacy binary work-item validation.
- Compare the failing definition with the source manifest used by the product installer.
- Check whether the object was partially written during power loss, rollback or concurrent update.
- Register a clean definition under a temporary name and compare behavior before replacing production state.
Corrective action
A retry against unchanged invalid data is not useful. Recreate or re-register the task through the supported API from a trusted definition, preserving ownership, principal, triggers and security descriptor. Remove the old object only after the replacement is validated. 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
The result does not prove that the task action executable is damaged. It also does not mean merely that a supported task version is newer than the caller; version mismatch has <code>SCHED_E_UNKNOWN_OBJECT_VERSION</code>. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.
Comparison with similar codes
SCHED_E_CANNOT_OPEN_TASK stops at opening the object. It reaches object validation and rejects its type or structure. XML-specific failures such as SCHED_E_MALFORMEDXML provide a more precise parser diagnosis.
Worked scenario
A packaging script copies an old binary work-item file while the scheduler is active. The resulting file exists but is truncated. Capturing its bytes and registering the original source definition through the API confirms that persistence, not the task executable, caused the 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
- Microsoft: Task Scheduler error and success constants
- Microsoft: Task Scheduler protocol behavior
- Microsoft: ITaskScheduler::Activate
- Microsoft: Task Scheduler schema
Looking for a different code? Search another status or error code.