| Previous | Next |
| DISP_E_TYPEMISMATCH | DISP_E_NONAMEDARGS |
DISP_E_UNKNOWNNAME
Automation member name is unknown
DISP_E_UNKNOWNNAME is HRESULT 2147614726 (0x80020006) from winerror.h. AllStat describes it as “Unknown name.” The value must be interpreted at IDispatch::GetIDsOfNames resolving a method, property, or named parameter, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the dispatch object cannot map one of the requested names to a DISPID in the selected locale and interface version. A diagnostic event for it should retain both representations of the HRESULT and the exact API boundary that produced it.
Where the result appears
- This result is returned while Automation binds or executes IDispatch::GetIDsOfNames resolving a method, property, or named parameter.
- retain the member name and DISPID, invocation flags, LCID, cArgs, cNamedArgs, and the exact VARIANTARG sequence in reverse Automation order.
- The output contract for it includes puArgErr, EXCEPINFO, result VARIANT, by-reference values, and SAFEARRAY lock or ownership state; inspect them before cleanup.
Before assigning cause to this result, identify the responsible thread, apartment, process, library generation, and server instance rather than relying on the final dialog text.
Typical causes and interpretation boundary
Common cause categories for it are: the member was renamed; the wrong object is used; the locale-specific name is unavailable; stale generated bindings call an older API. The candidate causes for it are alternatives, so test one precondition at a time instead of applying several broad repairs together.
The check that separates this result from nearby HRESULTs is: the dispatch object cannot map one of the requested names to a DISPID in the selected locale and interface version. When the boundary condition behind it has not been proven, avoid retries or repairs that assume a different neighboring HRESULT.
Evidence and telemetry
- Record this result with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture all requested names; LCID; object version; type-library registration; case and spelling; first unresolved name.
- Log VARIANT type tags, dimensions, bounds, lengths, and null/empty distinctions for it, but redact actual confidential argument values.
- Preserve the caller language/runtime, generated interop version, LCID, and whether the call crossed a process boundary when it occurs.
- After it, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.
Telemetry for it should be reproducible without copying secret values: prefer GUIDs, lengths, flags, sanitized names, and correlation IDs.
Correct handling and recovery
The appropriate recovery is to regenerate bindings from the deployed type library, use documented invariant names, and treat optional capabilities as unavailable when lookup fails. Before retrying it, specify which precondition changed and how duplicate effects or stale outputs will be detected.
Inspect every output before cleanup because interfaces, buffers, server effects, or metadata handles may be partially initialized.
Practical scenario
A macro targets a property introduced in a newer application version and disables that feature after name resolution fails.
Test it by reproducing the smallest failing contract, recording postconditions, and then changing a single input or state transition.
Difference from related HRESULTs
DISP_E_MEMBERNOTFOUND generally follows a known DISPID that cannot be invoked; it occurs during name-to-DISPID resolution.
Keeping it separate from its neighbor improves retry, cleanup, and user messaging because the two results imply different postconditions.
Developer and administrator guidance
Automation adapters should handle it at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>it</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.
Deployment owners should compare the registered type library and server binary as one versioned unit. After <code>it</code>, re-registering arbitrary DLLs or changing locale system-wide is inappropriate unless the captured metadata proves registration or LCID drift.
References
- Microsoft: IDispatch::GetIDsOfNames
- Microsoft: DISPPARAMS
- Microsoft: VARIANT structure
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.