| Previous | Next |
| hrNotInitialized | hrFileAccessDenied |
hrAlreadyInitialized
Where the operation crossed the contract
hrAlreadyInitialized means initialization-only work was attempted after the instance had already entered the running state.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errAlreadyInitialized. Preserve the original value 0xC8000406 when a wrapper also exposes a signed JET_ERR.
The key comparison is: hrAfterInitialization is restore-specific; this code is the general duplicate or late initialization boundary. The first useful observation is to capture the duplicate initializer and the parameters it tried to change after JetInit. This evidence shows whether startup, normal operation, shutdown, or restore ordering is the actual boundary.
Reconstruct the engine state
A useful trace should preserve the first failing operation and the state of the ESE instance state and call ordering.
- Code-specific observation: capture the duplicate initializer and the parameters it tried to change after JetInit.
- the successful or failed JetInit/JetTerm sequence and the component that owns it; associate it with this result rather than with a later generic exception.
- all still-live sessions and child handles at the transition.
- the first request accepted after shutdown or before initialization completed.
The ESE objects in play
| Diagnostic layer | ESE instance state and call ordering |
|---|---|
| Typical API surface | JetCreateInstance, JetSetSystemParameter, JetInit, JetTerm, and restore entry points |
| Code-specific boundary | initialization-only work was attempted after the instance had already entered the running state |
| First corrective direction | centralize instance ownership and set initialization parameters before the single successful start |
Handles derived from an instance are not reusable after teardown. Restore workflows have stricter ordering than ordinary open/attach calls.
Repair without destroying evidence
- Freeze the failing request context and record
0xC8000406, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture the duplicate initializer and the parameters it tried to change after JetInit.
- Apply the targeted fix: centralize instance ownership and set initialization parameters before the single successful start.
- Before retrying the operation, reconcile instance state, admission control, and child-handle cleanup.
- 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.
Do not collapse these codes together
hrAfterInitialization | restore processing was requested after the ESE instance had already initialized |
|---|---|
hrFeatureNotAvailable | an API or option is recognized but absent from the engine build or operating mode in use |
hrTermInProgress | the instance teardown boundary: new work reached ESE after termination had begun |
Developer-facing acceptance test
Build a focused test that reproduces it at the ESE instance state and call ordering layer. The corrected test should change only the decisive condition—initialization-only work was attempted after the instance had already entered the running state—and should prove that cleanup is safe if the call still fails.
Actions that can hide or worsen the problem
- Do not reuse instance-derived handles after the lifecycle transition.
- Do not start a second initializer to work around an ordering defect.
Technical references
- ESE API functions — used to verify the ESE object model, API ordering, or error family relevant to this HRESULT.
- Using ESE and esent.h
- JET error codes
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.