What does HRESULT 0xC80003FC (hrOutOfFileHandles) mean?

 
Previous Next
hrReadVerifyFailure hrDiskIO

hrOutOfFileHandles

Locate the failure in the Jet call chain

hrOutOfFileHandles means the engine could not obtain another operating-system file handle for database work.

This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errOutOfFileHandles. Preserve the original value 0xC80003FC when a wrapper also exposes a signed JET_ERR.

The key comparison is: hrTooManyOpenDatabases counts ESE database opens, while this result reaches the OS handle layer. The first useful observation is to measure process and system handle counts and identify leaked database, log, temporary, or backup files. 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 layerbounded engine, process, and storage resources
Typical API surfaceinstance system parameters, sessions, cursors, temporary tables, database attachment, and file growth
Code-specific boundarythe engine could not obtain another operating-system file handle for database work
First corrective directionclose leaked handles, reduce parallel file activity, and verify handle counts fall before retrying

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.

Questions the logs must answer

A useful trace should preserve the first failing operation and the state of the bounded engine, process, and storage resources.

  • Code-specific observation: measure process and system handle counts and identify leaked database, log, temporary, or backup files.
  • the oldest transaction, longest-held cursor, or file growth operation retaining the resource; associate it with this result rather than with a later generic exception.
  • 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.

Response and verification

  1. Freeze the failing request context and record 0xC80003FC, the Jet API name, and the current instance/session ownership.
  2. Verify the code-specific precondition: measure process and system handle counts and identify leaked database, log, temporary, or backup files.
  3. Apply the targeted fix: close leaked handles, reduce parallel file activity, and verify handle counts fall before retrying.
  4. Before retrying the operation, reconcile resource counts, owner cleanup, and capacity after the correction.
  5. Confirm both the returned HRESULT and the resulting database, cursor, or file state; then add a regression test that reproduces the old failure and proves cleanup leaves no stale handles.

Developer-facing acceptance test

Build a focused test that reproduces it at the bounded engine, process, and storage resources layer. The corrected test should change only the decisive condition—the engine could not obtain another operating-system file handle for database work—and should prove that cleanup is safe if the call still fails.

Distinguishing signals

hrOutOfDatabaseSpacethe database reached an engine-imposed growth ceiling rather than merely a full volume
hrOutOfMemoryESE or its caller could not reserve memory required for the operation
hrOutOfCursorsthe process exhausted table cursor resources because cursors were opened faster than they were closed

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.

Technical references


Looking for a different code? Search another status or error code.