| Previous | Next |
| hrBFInUse | hrFLDTooManySegments |
hrPMRecDeleted
State represented by this code
For hrPMRecDeleted, this code narrows the investigation to one engine boundary and should not be flattened into a generic exception. The decisive boundary is a legacy page/record-manager path found that the target record had already been deleted.
The stored Value is 0xC800012E (negative JET error -302; -302). The HRESULT carries failure severity, so output state must be treated according to the individual API contract. The legacy this result name comes from the Windows Directory Service backup/restore message header.
The first useful distinction is that the code is about record lifetime, not a missing database page or malformed bookmark by itself. Start by capture bookmark or key, page identity, transaction snapshot, delete owner, and whether the cursor was refreshed after concurrent work. That separates a reproducible incident from a later generic cleanup or service error.
Data for a reproducible incident
Preserve the first result before retries, cleanup, service restart, or file replacement changes the evidence. The diagnostic record should identify the exact API phase and the owner of every handle or artifact involved.
- Code-specific observation: capture bookmark or key, page identity, transaction snapshot, delete owner, and whether the cursor was refreshed after concurrent work.
- Concurrent delete or migration owner: record it together with this result and the timestamp of the first occurrence.
- Key/bookmark and index: record it together with this result and the timestamp of the first occurrence.
- Transaction snapshot: record it together with this result and the timestamp of the first occurrence.
- Schema segment list: record it together with it and the timestamp of the first occurrence.
Use hashes, lengths, IDs, generation numbers, and redacted samples instead of copying directory contents or sensitive database values into routine logs. For this it investigation, a complete provenance chain is often more useful than a second automatic retry.
Objects and state involved
| Diagnostic layer | record lifetime and index key-definition constraints |
|---|---|
| Relevant API surface | cursor seeks, bookmarks, deletes, schema creation, and index maintenance |
| Code-specific boundary | a legacy page/record-manager path found that the target record had already been deleted |
| Narrow corrective direction | reseek from a stable key and make concurrent deletion an explicit branch in the caller |
Record deletion is a normal concurrency outcome that must be distinguished from structural corruption., index segment count and key byte size are separate limits.
Actions that can make diagnosis worse
- do not remove arbitrary key columns without checking query semantics.
- do not reuse a stale bookmark without reseeking.
- do not discard the first lower-level Win32, RPC, or JET result merely because a later cleanup call returned a more familiar error.
Nearby ESE or AD backup states
It specifically means that the code is about record lifetime, not a missing database page or malformed bookmark by itself. Related values below can appear in the same workflow but require a different response:
hrFLDTooManySegments | an index key definition contains more segments than the legacy record manager supports |
|---|---|
hrCircularLogging | the Directory Service component is using circular logs, so the historical range needed for an incremental backup is not guaranteed to remain |
hrBadLogVersion | the transaction log format is incompatible with the ESE version attempting to read it |
Keep the original constant and hexadecimal value in telemetry. Replacing it with “backup failed” or “database warning” removes the state information needed to select the next legal API call.
Next actions
- Record it,
0xC800012E, the API name, the current phase, and all live context or file owners. - Verify the decisive condition by capture bookmark or key, page identity, transaction snapshot, delete owner, and whether the cursor was refreshed after concurrent work.
- Apply only the narrow correction: reseek from a stable key and make concurrent deletion an explicit branch in the caller.
- After it, recreate any context invalidated by the failure; do not carry stale HBC, cursor, file, or restore-map state into the retry.
- repeat the smallest non-destructive test that reaches the same boundary, then verify both the return value and the resulting file, cursor, backup, or database state.
Acceptance criteria for a fix
A useful regression test for this HRESULT should force the condition “a legacy page/record-manager path found that the target record had already been deleted”, call one documented API transition, and assert the exact HRESULT. The corrected the case should change only the decisive precondition and should verify cleanup as well as the primary output. For the result backup or restore path, also prove that the resulting set can be enumerated and that no file handle or context remains active after finalization.
Technical references
- ESE errors — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to it.
- JET_ERR enumeration
- Open-source ESE implementation
Looking for a different code? Search another status or error code.