| Previous | Next |
| hrTooManyAttachedDatabases | hrPermissionDenied |
hrDiskFull
Interpretation in ESE terms
hrDiskFull means the target volume cannot allocate space for database, log, checkpoint, or temporary growth.
This is the legacy Directory Service backup/restore HRESULT form of JET_errDiskFull (0xC8000710).
The key comparison is: hrOutOfDatabaseSpace is an engine database-size ceiling even when storage remains. The first useful observation is to record free and reserved space on every ESE path, quota, sparse/compression state, and the file being extended. This 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 condition | the target volume cannot allocate space for database, log, checkpoint, or temporary growth |
| First corrective direction | free or provision durable space and preserve logs; do not delete ESE files manually to make room |
A retry without closing owners or adding capacity often repeats the same failure and increases load. Resource codes should be tied to the exact exhausted pool rather than treated as generic low memory.
Comparison with adjacent failures
hrCurrencyStackOutOfMemory | cursor navigation state exhausted the engine resource used to preserve currency |
|---|---|
hrOutOfBuffers | the database page cache could not supply another usable buffer for the requested work |
hrVersionStoreOutOfMemory | the version store cannot retain more transactional versions under current workload and limits |
What to capture before retrying
- Code-specific observation: record free and reserved space on every ESE path, quota, sparse/compression state, and the file being extended.
- live resource counts grouped by session and request owner; associate it with this result rather than with a later generic exception.
- relevant JET_param values and process or system capacity at first failure.
- the oldest transaction, longest-held cursor, or file growth operation retaining the resource.
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.
Operational response
- Freeze the failing request context and record
0xC8000710, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: record free and reserved space on every ESE path, quota, sparse/compression state, and the file being extended.
- Apply the targeted fix: free or provision durable space and preserve logs; do not delete ESE files manually to make room.
- Before retrying the operation, reconcile resource counts, owner cleanup, and capacity after the correction.
Technical references
- JET_param enumeration.
- 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.