What does HRESULT 0x800401ED (MK_E_NOSTORAGE) mean?

MK_E_NOSTORAGE

Moniker does not refer to storage

MK_E_NOSTORAGE is the failure HRESULT 2147746285 (0x800401ED, signed -2147221011) from winerror.h. AllStat defines it as “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.

The high bit in 0x800401ED is set, so this is a failure rather than a success or informational result. Its facility field is 4 (FACILITY_ITF) and its low 16-bit code is 493 (0x01ED). Those bit fields classify the value, but they do not identify the failing object by themselves; the native method, object identity, and first producer of MK_E_NOSTORAGE remain essential.

Contract boundary

Understanding MK_E_NOSTORAGE requires this subsystem context: A moniker is an object with class-specific parsing, comparison, composition, and binding behavior. For MK_E_NOSTORAGE, display-name text alone does not establish what operations a particular moniker implementation supports.

• Associate MK_E_NOSTORAGE with one exact operation in IMoniker methods, IBindCtx state, display-name parsing, composite monikers, the Running Object Table, deadlines, and object or storage binding.
• Confirm that MK_E_NOSTORAGE 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.
• Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded MK_E_NOSTORAGE; the HRESULT alone should not erase a more specific cause.

Likely cause branches

• MK_E_NOSTORAGE can result when the target class has no IStorage/IStream representation.
• MK_E_NOSTORAGE can result when the caller chooses storage binding although object binding is the supported contract.
• MK_E_NOSTORAGE can result when the named subobject exists but is not independently persistent.

Evidence to preserve

A useful MK_E_NOSTORAGE incident records the moniker class, display name with secrets removed, bind options and deadline, pmkToLeft, requested IID, ROT result, file identity, composite components, and object lifetime registrations in IBindCtx. For MK_E_NOSTORAGE, also retain the application and component build, architecture, process and thread IDs, COM apartment, operation correlation ID, elapsed time, and the first state-changing event before the failure. When logging MK_E_NOSTORAGE, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.

• For MK_E_NOSTORAGE, record requested storage IID and whether BindToObject succeeds.
• For MK_E_NOSTORAGE, inspect the moniker class and target persistence interfaces.
• For MK_E_NOSTORAGE, avoid assuming every file-like display name maps to IStorage.

Diagnostic sequence

1. Capture MK_E_NOSTORAGE at the first native return before a wrapper maps it to a generic exception.
2. Identify the exact object, method, and lifecycle phase involved in calling BindToStorage for a moniker that identifies only a live object or nonstorage resource.
3. Record requested storage IID and whether BindToObject succeeds.
4. Inspect the moniker class and target persistence interfaces.
5. Avoid assuming every file-like display name maps to IStorage.
6. Reproduce MK_E_NOSTORAGE with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

Recovery and retry

Correction. For MK_E_NOSTORAGE, bind to the object and use its documented persistence/export API, or choose a moniker that identifies actual storage. Retry boundary. Retry only after changing the target or requested interface; availability changes cannot add unsupported storage semantics. Before repeating the MK_E_NOSTORAGE 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. This isolates MK_E_NOSTORAGE within COM moniker parsing, composition, binding, and storage resolution and provides a regression test for the stated correction.

Difference from related HRESULTs

MK_E_NOOBJECT concerns object binding; MK_E_NOSTORAGE specifically rejects the requested storage representation. For MK_E_NOSTORAGE, keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.

Developer and administrator guidance

For MK_E_NOSTORAGE, preserve the concrete moniker class, compose through IMoniker methods rather than string concatenation, set realistic bind deadlines, and request object versus storage interfaces deliberately. Regression coverage for MK_E_NOSTORAGE should include malformed and class-specific display names, absent left-hand context, expired deadlines, unsupported inverse or enumeration operations, unavailable ROT objects, file access, and storage-only targets.

Operational repair for MK_E_NOSTORAGE must target the evidence-backed owner: verify the named resource, file, server, or registration identified by the concrete moniker; do not infer a machine-wide COM fault from one provider-specific display name. Retain before-and-after traces for MK_E_NOSTORAGE so the change can be attributed and reversed.

References

• Microsoft: generic COM error codes — official Microsoft documentation relevant to MK_E_NOSTORAGE.
• Microsoft: HRESULT values — official Microsoft documentation relevant to MK_E_NOSTORAGE.
• Microsoft: IMoniker — official Microsoft documentation relevant to MK_E_NOSTORAGE.
• Microsoft: IBindCtx — official Microsoft documentation relevant to MK_E_NOSTORAGE.
• Microsoft: MkParseDisplayName — official Microsoft documentation relevant to MK_E_NOSTORAGE.
• Microsoft: IMoniker::BindToStorage — official Microsoft documentation relevant to MK_E_NOSTORAGE.

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