| Previous | Next |
| SCHED_E_ACCOUNT_NAME_NOT_FOUND | SCHED_E_NO_SECURITY_SERVICES |
SCHED_E_ACCOUNT_DBASE_CORRUPT
Task Scheduler reset a corrupted security database
SCHED_E_ACCOUNT_DBASE_CORRUPT is the failure HRESULT 0x80041311 (-2147216623 as a signed 32-bit value). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and its facility-specific code is 0x1311. AllStat describes the result as “Corruption was detected in the Task Scheduler security database; the database has been reset.”
Where this HRESULT belongs
AllStat and Microsoft state that corruption was detected and the database was reset. The reset is part of the reported condition: callers must assume previously stored task account information may no longer be available even if task definitions themselves still exist. In practical terms, this result is returned when legacy scheduler security metadata is read or updated for a task account and integrity checks fail. Preserve it symbolically because a generic COM failure path loses its scheduler-specific recovery decision.
Typical causes
- Persistent scheduler security metadata was damaged by an interrupted write, storage failure or unsupported manipulation.
- A legacy migration or restore brought task definitions and account metadata from inconsistent points in time.
- System corruption affected the scheduler security store used by Task Scheduler 1.0 account operations.
- An image was cloned or restored without preserving the security material expected by the stored tasks.
- A third-party maintenance tool altered scheduler-owned security state outside documented APIs.
Rank these explanations for it by matching them to the exact method, target and scheduler state observed at failure time.
Evidence to preserve
- The first Task Scheduler and system events reporting corruption and reset.
- The list of tasks using stored credentials before any bulk repair.
- Disk, file-system and servicing health around the incident.
- Backup or migration timestamps for task definitions and security metadata.
- Which account-setting or save operation first returned the HRESULT.
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
- Stop automated retry loops that repeatedly rewrite credentials while the scope is unknown.
- Preserve relevant event logs and inventory tasks that require password-based legacy account information.
- Verify system storage health and identify any recent restore, clone or migration operation.
- Re-enter credentials only for known tasks and through the supported scheduler API.
- Run each repaired task under controlled conditions and confirm its principal, privileges and exit result.
Recovery and retry
The database has already been reset, so retrying with an old in-memory task object may use assumptions that are no longer true. Reopen the task, restore account information from an authorized source and save it through Task Scheduler. If corruption recurs, investigate storage and system integrity before further credential changes. 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
This HRESULT does not reveal the original password, identify which task caused corruption or guarantee that every scheduled task is unusable. It should not be answered by deleting all task definitions or by copying security databases from another machine. 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_ACCOUNT_INFORMATION_NOT_SET means a particular task has no stored account information. It reports integrity failure and reset of the broader security store.
Practical scenario
After restoring an old system image over newer task metadata, the first legacy account update reports a corrupt scheduler database. The administrator inventories credential-bearing tasks, validates disk health, then re-enters credentials task by task rather than recreating unrelated schedules. 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: IScheduledWorkItem::SetAccountInformation
- Microsoft: Task Scheduler 1.0 interfaces
Looking for a different code? Search another status or error code.