| Previous | Next |
| hrTooManyIO | hrPMRecDeleted |
hrBFInUse
Where the workflow stopped
hrBFInUse means the caller attempted to abandon or repurpose a buffer page that still has an active owner or dependency.
The stored value is 0xC80000CA (negative JET error -202; -202). The legacy symbolic name comes from the Windows Directory Service backup/restore message header.
The first useful distinction is that this is an ownership conflict, not the cache-miss warning hrBFPageNotFound. Start by recording page identity, latch/reference counts, cursor and transaction owners, dirty state, and the operation requesting abandonment.
Similar-looking outcomes
This result specifically means that this is an ownership conflict, not the cache-miss warning hrBFPageNotFound. Related values below can appear in the same workflow but require a different response:
hrDeleteBackupFileFail | backup cleanup could not delete an artifact it was responsible for removing |
|---|---|
hrLogBufferTooSmall | the available recovery log buffer cannot hold the log record or sector data required for replay |
hrRestoreMapExists | a restore map is already registered for the component while the caller attempts to add another mapping |
Objects and state involved
| Diagnostic layer | buffer-page ownership, dependencies, dirty state, and safe release |
|---|---|
| Relevant API surface | internal ESE buffer-manager work beneath cursor and transaction operations |
| Code-specific condition | the caller attempted to abandon or repurpose a buffer page that still has an active owner or dependency |
| Narrow corrective direction | release the legitimate owner through normal cursor or transaction cleanup before attempting buffer disposal |
A buffer can be in use because of a legitimate cursor, transaction, latch, or I/O dependency. Forcing release around the engine breaks ownership invariants.
Minimum useful trace
- Code-specific observation: record page identity, latch/reference counts, cursor and transaction owners, dirty state, and the operation requesting abandonment.
- Page and database identity: capture the value and timestamp from the first occurrence.
- Owner/reference state: capture the value and timestamp from the first occurrence.
- Dirty and I/O status: capture the value and timestamp from the first occurrence.
- Cursor/transaction lifetime: capture the value and timestamp from the first occurrence.
Steps to resolve it
- Record it,
0xC80000CA, the API name, the current phase, and all live context or file owners. - Verify the condition by recording page identity, latch/reference counts, cursor and transaction owners, dirty state, and the operation requesting abandonment.
- Apply only the targeted fix: release the legitimate owner through normal cursor or transaction cleanup before attempting buffer disposal.
Actions that can make diagnosis worse
- Do not force-close the underlying database file to release one buffer.
- Do not treat ownership as physical page corruption.
Acceptance criteria for a fix
A useful regression test should force the condition “the caller attempted to abandon or repurpose a buffer page that still has an active owner or dependency”, call one documented API transition, and assert the exact HRESULT.
Technical references
- ESE error-code table — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- JET_ERR enumeration
- Open-source ESE implementation
Looking for a different code? Search another status or error code.