| Previous | Next |
| SCHED_E_SERVICE_NOT_INSTALLED | SCHED_E_INVALID_TASK |
SCHED_E_CANNOT_OPEN_TASK
Task Scheduler could not open the requested task object
SCHED_E_CANNOT_OPEN_TASK is the failure HRESULT 0x8004130D (-2147216627 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x130D. AllStat describes the result as “The task object could not be opened.”
Operation and state
The failure occurs before normal inspection or execution of the task. In legacy Task Scheduler 1.0 code this can appear around activation of a stored work item; in newer code the equivalent diagnostic boundary is opening the registered task by its folder and name. In practical terms, this result is returned when task lookup or activation has identified a name or path but cannot obtain a usable task object from persistent storage. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Failure paths to examine
- The caller used the wrong folder, task name, target computer or escaping rules.
- The task was deleted or replaced between enumeration and open.
- The caller can enumerate a folder but lacks permission to read the selected task.
- Persistent task data is unreadable because of storage corruption or incomplete deployment.
- Legacy code expects a Task Scheduler 1.0 work item while the stored object is not usable through that interface.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Data to collect before changing anything
- The exact task path and target computer passed to the opening API.
- Whether the path came from fresh enumeration or a cached configuration value.
- Caller token, elevation state and task security descriptor where authorized.
- Exported task XML or legacy work-item metadata if the object can be read by another tool.
- File-system, service and Task Scheduler Operational events at the lookup time.
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.
Step-by-step diagnosis
- Enumerate the containing folder again and compare names using the API-provided path rather than hand-built strings.
- Try read-only inspection under the intended security context before attempting modification or run operations.
- Determine whether the task disappeared during a deployment, cleanup or registration update.
- If another management tool opens it, compare API generation, remote target and credentials.
- Recreate the task from a trusted definition only after preserving the unreadable object and identifying why it cannot be opened.
Retry policy and restoration
Retry once after fresh enumeration if a concurrent registration transaction may have replaced the object. Permission changes require an explicit security decision. Corrupt or incomplete task data should be repaired by re-registering a validated definition, not by editing scheduler storage directly. 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.
Limits of this HRESULT
This HRESULT does not by itself identify malformed XML, an unsupported version or a missing executable. Those conditions have separate evidence and, in several cases, separate Task Scheduler codes. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.
Neighboring status codes
SCHED_E_INVALID_TASK says the opened or supplied object is not a valid task. SCHED_E_UNKNOWN_OBJECT_VERSION identifies its version. A not-found result should be preserved separately when the API reports that the named task does not exist.
Concrete troubleshooting case
An updater enumerates a task, deletes it, and registers a replacement under the same display name. A worker holding the old path tries to open during the replacement window. Fresh enumeration followed by opening the new registration succeeds, proving a race rather than persistent corruption. 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
- Microsoft: Task Scheduler error and success constants
- Microsoft: ITaskScheduler::Activate
- Microsoft: legacy ITask interface
- Microsoft: IRegisteredTask
Looking for a different code? Search another status or error code.
