| Previous | Next |
| MK_E_NOINVERSE | MK_E_NOPREFIX |
MK_E_NOSTORAGE
Moniker does not refer to storage
MK_E_NOSTORAGE is the failure HRESULT 2147746285 (0x800401ED, signed -2147221011) from winerror.h. The documented description is “Moniker does not refer to storage”. In practical terms, the moniker does not refer to an object that exposes the requested storage. Interpret it in the context of calling BindToStorage for a moniker that identifies only a live object or nonstorage resource.
Relevant contract
Diagnostic focus: For MK_E_NOSTORAGE, preserve the distinction between BindToObject and BindToStorage for the concrete moniker class. Record the exact IMoniker method, requested interface, bind options and concrete moniker class from the failing call; those details determine whether retry, a different bind operation, or a different moniker is appropriate.
- Confirm that this result came from calling BindToStorage for a moniker that identifies only a live object or nonstorage resource, rather than from cleanup or a wrapper that ran afterward.
Likely cause branches
- It can result when the target class has no IStorage/IStream representation.
- It can result when the caller chooses storage binding although object binding is the supported contract.
- It can result when the named subobject exists but is not independently persistent.
Evidence to preserve
- Record requested storage IID and whether BindToObject succeeds.
- Inspect the moniker class and target persistence interfaces.
- Avoid assuming every file-like display name maps to IStorage.
Diagnostic sequence
- Identify the exact object, method, and lifecycle phase involved in calling BindToStorage for a moniker that identifies only a live object or nonstorage resource.
Recovery and retry
Correction. bind to the object and use its documented persistence/export API, or choose a moniker that identifies actual storage. Retry condition. Retry only after changing the target or requested interface; availability changes cannot add unsupported storage semantics. Before repeating the operation, release partial monikers and bound interfaces, unregister only owned Running Object Table entries, and abandon a bind context whose deadline or parameters no longer match the retry.
Practical scenario
A moniker names a live data feed; object binding succeeds, but storage binding does not, so the application uses the feed’s snapshot API.
Difference from related HRESULTs
MK_E_NOOBJECT concerns object binding; it specifically rejects the requested storage representation.
Developer and administrator guidance
References
Looking for a different code? Search another status or error code.