| Previous | Next |
| SCHED_E_START_ON_DEMAND | SCHED_E_DEPRECATED_FEATURE_USED |
SCHED_E_TASK_NOT_UBPM_COMPAT
The task is incompatible with the unified scheduling engine
SCHED_E_TASK_NOT_UBPM_COMPAT is the failure HRESULT 0x80041329 (-2147216599 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x1329. AllStat describes the result as “The combination of properties that task is using is not compatible with the scheduling engine.”
Where this HRESULT belongs
Microsoft describes this code as a property-combination incompatibility with the scheduling engine. The Task Scheduler feature documentation explains that unified-engine support excludes particular logon types, instance policies, actions, settings and trigger features; the complete combination must be examined. In practical terms, this result is returned when registration or validation requests the unified scheduling engine for a definition whose combined properties that engine cannot support. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Typical causes
- UseUnifiedSchedulingEngine is enabled with the interactive-token-or-password logon type.
- The task requests the stop-existing multiple-instance policy, which the unified engine does not support.
- A send-email or display-message action is combined with unified-engine execution.
- Network settings, hard-termination restrictions or unsupported trigger features are present.
- A generator merges individually valid fragments into a combination rejected by the selected engine.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Evidence to preserve
- Task XML including UseUnifiedSchedulingEngine and every Settings element.
- Principal logon type and multiple-instance policy.
- Complete action and trigger collections, not only the first item.
- Target Windows version and the tool that generated the definition.
- Registration HRESULT and nearby Task Scheduler Operational events.
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.
A disciplined diagnostic sequence
- Export the exact definition rejected by the target machine.
- List every feature documented as unsupported by the unified engine.
- Map each unsupported feature to a real product requirement before changing it.
- Either disable unified-engine use or redesign the conflicting property with equivalent reviewed behavior.
- Register the revised task under a test name and verify triggering, concurrency and security semantics.
Recovery and retry
A retry is valid after the property combination changes. The least disruptive fix is often to leave the task on the regular Task Scheduler engine when the unsupported feature is required. If unified-engine behavior is mandatory, replace each incompatible feature deliberately and test the new operational contract. 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 the code does not establish
The HRESULT does not say that the XML is malformed or that the task cannot run under any scheduler engine. It is also distinct from V1 compatibility; a task can be modern and valid yet incompatible with the unified engine. Logging only the decimal value without task path, method and target computer is insufficient to explain this result.
Difference from nearby Task Scheduler results
SCHED_E_TASK_NOT_V1_COMPAT addresses the older Task Scheduler 1.0 model. SCHED_E_DEPRECATED_FEATURE_USED reports a deprecated feature even when unified-engine selection is not the immediate compatibility boundary.
Practical scenario
A deployment enables UseUnifiedSchedulingEngine while retaining a stop-existing instance policy and a monthly trigger feature. Registration fails. The team keeps the required policy, disables unified-engine selection and verifies that ordinary Task Scheduler execution preserves the intended single-instance behavior. 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: Task Scheduler feature changes
- Microsoft: Task Scheduler schema
- Microsoft: task definitions and APIs
Looking for a different code? Search another status or error code.