| Previous | Next |
| hrInvalidDatabaseId | hrOutOfDatabaseSpace |
hrOutOfMemory
Diagnostic boundary
For hrOutOfMemory, read this result as a boundary in the ESE state machine, not as a generic Windows failure. The decisive boundary is ESE or its caller could not reserve memory required for the operation.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errOutOfMemory. Preserve the original value 0xC80003F3 when a wrapper also exposes a signed JET_ERR.
The key comparison for this HRESULT is this: hrOutOfBuffers concerns the page cache and hrVersionStoreOutOfMemory concerns version pages, while this result is broader. The first useful observation is to collect process commit, working set, system commit limit, allocation size, and concurrent ESE activity at the first failure. This it evidence identifies the exhausted pool so a leak, long transaction, concurrency spike, and hard capacity limit are not confused.
The ESE objects in play
| Diagnostic layer | bounded engine, process, and storage resources |
|---|---|
| Typical API surface | instance system parameters, sessions, cursors, temporary tables, database attachment, and file growth |
| Code-specific boundary | ESE or its caller could not reserve memory required for the operation |
| First corrective direction | lower concurrency or memory pressure, verify configured cache limits, and retry only after capacity changes |
Resource codes should be tied to the exact exhausted pool rather than treated as generic low memory., long transactions can retain versions and indirectly amplify memory and log pressure.
Evidence that resolves the ambiguity
A useful trace for this HRESULT should preserve the first failing operation and the state of the bounded engine, process, and storage resources.
- Code-specific observation: collect process commit, working set, system commit limit, allocation size, and concurrent ESE activity at the first failure.
- relevant JET_param values and process or system capacity at first failure; associate it with this result rather than with a later generic exception.
- the oldest transaction, longest-held cursor, or file growth operation retaining the resource; associate it with it rather than with a later generic exception.
- live resource counts grouped by session and request owner; associate it with it rather than with a later generic exception.
Log lengths, hashes, IDs, flags, and redacted samples where appropriate.
Nearby results that mean something different
For this HRESULT, hrOutOfBuffers concerns the page cache and hrVersionStoreOutOfMemory concerns version pages, while it is broader. The following neighboring results belong to the same broad subsystem but mark different boundaries:
hrOutOfFileHandles | the engine could not obtain another operating-system file handle for database work |
|---|---|
hrOutOfSessions | the instance cannot allocate another JET_SESID |
hrOutOfDatabaseSpace | the database reached an engine-imposed growth ceiling rather than merely a full volume |
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.
A disciplined correction path
- Freeze the failing request context and record it,
0xC80003F3, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: collect process commit, working set, system commit limit, allocation size, and concurrent ESE activity at the first failure.
- Apply the narrow correction: lower concurrency or memory pressure, verify configured cache limits, and retry only after capacity changes.
- Before retrying it, reconcile resource counts, owner cleanup, and capacity after the correction.
- confirm both the returned HRESULT and the resulting database, cursor, or file state; then add a regression test that forces the old boundary and proves cleanup leaves no stale handles.
Actions that can hide or worsen the problem
- do not raise limits before checking ownership and release paths.
- do not create a retry storm while the exhausted resource remains unavailable.
Developer-facing acceptance test
Build a focused test that reproduces it at the bounded engine, process, and storage resources 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—ESE or its caller could not reserve memory required for the operation—and should prove that cleanup is safe if the call still fails.
Technical references
- JET_param enumeration — used to verify the ESE object model, API ordering, or error family relevant to it.
- Transactions and save points
- ESE files and storage paths
- ESE source repository
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.