| Previous | Next |
| ERROR_ACCESS_DISABLED_WEBBLADE_TAMPER | ERROR_ALREADY_FIBER |
ERROR_RECOVERY_FAILURE
Transaction recovery did not complete.
ERROR_RECOVERY_FAILURE is Win32 error 1279 (0x4FF). It indicates that a transaction recovery operation failed. In a Kernel Transaction Manager context, recovery rebuilds transaction-manager, resource-manager, enlistment, and transaction state from durable log records after interruption or restart.
Typical causes
- a missing, truncated, unreadable, or inconsistent transaction log stream
- storage failure while the transaction manager reads restart information
- a resource manager that cannot reenlist or reconcile an in-doubt transaction
- restored data files that do not correspond to the restored transaction log
- incorrect sequencing that opens transactional objects before recovery finishes
Evidence to collect
Record the transaction-manager identity, log path or CLFS stream, resource-manager GUIDs, transaction identifiers, last known virtual clock, recovery API, and the immediately preceding status. Preserve storage and event-log entries from the crash or restart window. If a database or service wraps KTM, also capture its own recovery journal and version.
Diagnostic sequence
Determine whether the transaction manager is volatile or durable and identify the exact recovery boundary. Verify that the log stream and the data protected by each resource manager came from a consistent backup point. Check access rights, free space, volume health, filter drivers, and whether another process has the recovery log open in an incompatible mode.
Examine every resource manager’s reenlistment outcome instead of focusing only on the first client transaction that fails. A participant may be unable to decide commit or rollback because its private recovery record is absent. Do not delete transaction logs merely to make the manager start; that can convert a recoverable in-doubt state into silent data inconsistency.
Recovery strategy
Restore a consistent set of logs and protected data, repair the underlying storage problem, and run the subsystem’s documented recovery procedure. If the product supports roll-forward to a known virtual clock, use that only with a verified recovery plan. New transactions should remain blocked until the manager and all required resource managers report a stable state.
Difference from an ordinary rollback
A transaction abort can be an expected outcome caused by a participant rejecting work. Error 1279 means the infrastructure could not reconstruct the durable state needed to decide or finish outstanding transactions. Retrying the business operation before recovery succeeds can duplicate effects or obscure the original failure.
Example
A server loses power while two resource managers are preparing a transaction. After restart, one data directory is restored from backup but the KTM log remains newer. Recovery cannot reconcile the enlistment records and returns 1279. Restoring the matching data snapshot and rerunning recovery brings the transaction manager online.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Kernel Transaction Manager
- Microsoft: RecoverTransactionManager
- Microsoft: KTM transactions
Looking for a different code? Search another status or error code.