| Previous | Next |
| hrRecordDeleted | hrOutOfFileHandles |
hrReadVerifyFailure
Why this is more specific than the message text
For hrReadVerifyFailure, the diagnostic value comes from the specific ESE error family and the exact operation that returned it. The decisive boundary is a database page failed physical verification while being read.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errReadVerifyFailure. Preserve the original value 0xC80003FA when a wrapper also exposes a signed JET_ERR.
The key comparison for this HRESULT is this: hrDiskIO is an operating-system I/O failure; this code means bytes were read but failed integrity checks. The first useful observation is to preserve the file path, page/offset, expected and actual checksum data, storage events, and a copy of surrounding logs. This this result evidence distinguishes access, operating-system I/O, integrity verification, missing files, and log corruption.
Related ESE boundaries
For this HRESULT, hrDiskIO is an operating-system I/O failure; this code means bytes were read but failed integrity checks. The following neighboring results belong to the same broad subsystem but mark different boundaries:
hrPermissionDenied | the caller lacks permission for the requested ESE operation or protected resource |
|---|---|
hrTempFileOpenError | ESE could not create or open a temporary file needed for sorting, maintenance, or recovery work |
hrLogCorrupted | transaction log files required by the database fail structural or integrity validation |
Keep this result in the incident record; replacing it with “database error” hides whether the next step is handle renewal, schema correction, lock reconciliation, or file preservation.
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 | a database page failed physical verification while being read |
| First corrective direction | stop writes, secure backups and diagnostics, investigate storage, and use product-supported recovery rather than editing the file |
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.
Data for a reproducible case
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: preserve the file path, page/offset, expected and actual checksum data, storage events, and a copy of surrounding logs.
- 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 it 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.
Corrective workflow
- Freeze the failing request context and record it,
0xC80003FA, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: preserve the file path, page/offset, expected and actual checksum data, storage events, and a copy of surrounding logs.
- Apply the narrow correction: stop writes, secure backups and diagnostics, investigate storage, and use product-supported recovery rather than editing the file.
- Before retrying it, reconcile file identity, integrity evidence, and the supported recovery state.
- add a regression test that forces the old boundary and proves cleanup leaves no stale handles; then repeat the smallest read-only or disposable test that exercises the corrected precondition.
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.
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 it test should change only the decisive condition—a database page failed physical verification while being read—and should prove that cleanup is safe if the call still fails.
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.