| Previous | Next |
| hrMissingPreviousLogFile | hrBadLogVersion |
hrLogWriteFail
What this return value changes
hrLogWriteFail means the write-ahead log could not durably accept a required record.
The stored value is 0xC80001FE (negative JET error -510; -510). Current ESE documentation uses JET_errLogWriteFail for the corresponding published JET condition.
The first useful distinction is that database-page writes cannot substitute for a failed log write because ESE durability depends on write-ahead ordering. Start by capturing the log path, generation, offset, byte count, Win32 error, free space, volume state, and first failing transaction.
Objects and state involved
| Diagnostic layer | durable write-ahead-log I/O and capacity of the log volume |
|---|---|
| Relevant API surface | transaction commit, log flush, generation creation, recovery undo, and backup truncation |
| Code-specific condition | the write-ahead log could not durably accept a required record |
| Narrow corrective direction | freeze further updates, correct storage, and let the owning service perform supported recovery |
ESE must log changes before corresponding database pages become durable. Log storage is often separate from database storage and must be diagnosed independently.
Evidence worth preserving
- Code-specific observation: capture the log path, generation, offset, byte count, Win32 error, free space, volume state, and first failing transaction.
How to distinguish nearby results
It specifically means that database-page writes cannot substitute for a failed log write because ESE durability depends on write-ahead ordering. Related values below can appear in the same workflow but require a different response:
hrLogDiskFull | the volume hosting transaction logs cannot allocate the next required log write or generation |
|---|---|
hrInvalidBackupSequence | backup APIs were called in an order that violates the ESE external-backup state machine |
hrMissingRestoreLogFiles | hard recovery cannot reach consistency because one or more mandatory restore logs are absent |
A safe response sequence
- Record it,
0xC80001FE, the API name, the current phase, and all live context or file owners. - Verify the condition by capturing the log path, generation, offset, byte count, Win32 error, free space, volume state, and first failing transaction.
- Apply only the targeted fix: freeze further updates, correct storage, and let the owning service perform supported recovery.
Actions that can make diagnosis worse
- Do not delete required log generations to free space.
- Do not keep accepting writes after durable logging has failed.
Acceptance criteria for a fix
A useful regression test should force the condition “the write-ahead log could not durably accept a required record”, call one documented API transition, and assert the exact HRESULT.
Technical references
- ESE log files and reserves — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- Transaction-log parameters
- ESE error codes
- Microsoft JET_ERR enumeration
Looking for a different code? Search another status or error code.