| Previous | Next |
| hrOutOfFileHandles | hrInvalidPath |
hrDiskIO
Where the operation crossed the contract
For hrDiskIO, the symbolic name points to a precise ESE precondition that should be verified before any retry. The decisive boundary is the storage stack failed an ESE read, write, flush, or metadata operation.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errDiskIO. Preserve the original value 0xC80003FE when a wrapper also exposes a signed JET_ERR.
The key comparison for this HRESULT is this: hrReadVerifyFailure is data-integrity verification after a read; this result is the I/O operation itself failing. The first useful observation is to capture the underlying Win32 error, file, offset, byte count, access type, latency, and storage/system events. This evidence distinguishes access, operating-system I/O, integrity verification, missing files, and log corruption.
Reconstruct the engine state
A useful trace for this HRESULT should preserve the first failing operation and the state of the database, log, checkpoint, or temporary files and the Windows storage/security boundary.
- Code-specific observation: capture the underlying Win32 error, file, offset, byte count, access type, latency, and storage/system events.
- storage, filter-driver, antivirus, and system events from the same time window; associate it with this result rather than with a later generic exception.
- the exact file, offset, length, access mode, and underlying Win32 status; associate it with this result rather than with a later generic exception.
- database, log, checkpoint, and temporary-file generations present at the first event; associate it with it rather than with a later generic exception.
Log lengths, hashes, IDs, flags, and redacted samples where appropriate.
The ESE objects in play
| Diagnostic layer | database, log, checkpoint, or temporary files and the Windows storage/security boundary |
|---|---|
| Typical API surface | database open/attach, log recovery, temporary sort/maintenance, and file rename paths |
| Code-specific boundary | the storage stack failed an ESE read, write, flush, or metadata operation |
| First corrective direction | stabilize storage and preserve evidence before allowing recovery or repeated writes |
Database and log files should not be manually fabricated, renamed, or deleted as a first response. Integrity failures require evidence preservation before repair or replay changes the on-disk state.
Repair without destroying evidence
- Freeze the failing request context and record it,
0xC80003FE, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture the underlying Win32 error, file, offset, byte count, access type, latency, and storage/system events.
- Apply the narrow correction: stabilize storage and preserve evidence before allowing recovery or repeated writes.
- Before retrying it, reconcile file identity, integrity evidence, and the supported recovery state.
- Repeat the smallest read-only or disposable test that exercises the corrected precondition; then confirm both the returned HRESULT and the resulting database, cursor, or file state.
Do not collapse these codes together
For this HRESULT, hrReadVerifyFailure is data-integrity verification after a read; it is the I/O operation itself failing. The following neighboring results belong to the same broad subsystem but mark different boundaries:
hrCannotRename | ESE could not complete the temporary-to-final rename used by a database or maintenance operation |
|---|---|
hrFileAccessDenied | ESE could not open or manipulate a database-related file with the requested access |
hrAccessDenied | ESE rejected access at an object or operation boundary under the current identity/mode |
Keep it in the incident record; replacing it with “database error” hides whether the next step is handle renewal, schema correction, lock reconciliation, or file preservation.
Developer-facing acceptance test
Build a focused test that reproduces it at the database, log, checkpoint, or temporary files and the Windows storage/security boundary layer. Record the precondition, execute one API call, and assert the HRESULT plus the resulting handle and transaction state. The corrected test should change only the decisive condition—the storage stack failed an ESE read, write, flush, or metadata operation—and should prove that cleanup is safe if the call still fails.
Actions that can hide or worsen the problem
- Do not delete, rename, replace, or fabricate ESE files before preserving the complete set.
- Do not run destructive repair while a storage or access fault is still active.
Technical references
- ESE files — used to verify the ESE object model, API ordering, or error family relevant to it.
- JET error codes
- ESE database anatomy
- ESE source repository
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.