| Previous | Next |
| DISP_E_MEMBERNOTFOUND | DISP_E_TYPEMISMATCH |
DISP_E_PARAMNOTFOUND
Automation parameter or named argument was not found
DISP_E_PARAMNOTFOUND is HRESULT 2147614724 (0x80020004) from winerror.h. AllStat describes it as “Parameter not found.” The value must be interpreted at IDispatch::Invoke argument binding and optional-parameter processing, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that a named parameter DISPID or required argument reference does not exist in the invoked member signature. For reliable triage of this result, store the native HRESULT and symbolic identity before generic error handling rewrites either one.
Where the result appears
- This result is returned while Automation binds or executes IDispatch::Invoke argument binding and optional-parameter processing.
- 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.
The root-cause boundary for it is the component that returned it, not the application screen on which the result was eventually displayed.
Typical causes and interpretation boundary
Common cause categories for it are: the named argument spelling maps to no DISPID; the caller uses a parameter from another version; optional arguments are encoded incorrectly. Investigate this result through falsifiable cause hypotheses and keep the first lower-level failure that explains the observed HRESULT.
The check that separates this result from nearby HRESULTs is: a named parameter DISPID or required argument reference does not exist in the invoked member signature. Use the decisive condition for it as a test assertion; if it cannot be asserted, diagnosis is not complete.
Evidence and telemetry
- Record it with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture member DISPID; named DISPIDs; cArgs and cNamedArgs; argument order; type-library signature; arg-error index.
- 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.
Logs for it should expose enough structure to reproduce the failure without becoming a secondary store of sensitive input data.
Correct handling and recovery
The appropriate recovery is to resolve names against the current type library, build DISPPARAMS in reverse positional order, and represent omitted optional values as documented. Do not loop on it; retry only under a documented transient condition with bounded delay and post-operation reconciliation.
After observing it, separate local resource cleanup from server-side reconciliation and perform each only for the failing activity ID.
Practical scenario
A script calls a renamed optional argument by its old DISPID; reading the current type information identifies the replacement name.
The acceptance test for it should prove that the proposed repair changes the predicted contract fact rather than merely hiding the message.
Difference from related HRESULTs
DISP_E_BADPARAMCOUNT reports the wrong number of arguments; it points to an argument identifier that cannot be bound.
Preserve the neighboring-result distinction for it in metrics and incident reports to avoid applying the wrong remediation.
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
Looking for a different code? Search another status or error code.