| Previous | Next |
| DISP_E_PARAMNOTFOUND | DISP_E_UNKNOWNNAME |
DISP_E_TYPEMISMATCH
Automation argument type does not match the member contract
DISP_E_TYPEMISMATCH is HRESULT 2147614725 (0x80020005) from winerror.h. AllStat describes it as “Type mismatch.” The value must be interpreted at IDispatch::Invoke coercing VARIANTARG values to the parameter types declared by the target, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that at least one supplied VARIANT cannot be converted to the required Automation type. Keep the symbolic name beside the raw hexadecimal value so later analysis does not collapse the result into an unrelated COM family.
Where the result appears
- This result is returned while Automation binds or executes IDispatch::Invoke coercing VARIANTARG values to the parameter types declared by the target.
- 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.
Determine the object and lifecycle phase that owned this result; a UI symptom cannot establish whether the origin was the caller, proxy, runtime, server, or metadata producer.
Typical causes and interpretation boundary
Common cause categories for it are: a string is not parseable as the required number; VT_BYREF is missing; SAFEARRAY element type differs; null and empty are confused. Evaluate these branches independently and require evidence from the owning API before promoting one branch to the root cause.
The check that separates this result from nearby HRESULTs is: at least one supplied VARIANT cannot be converted to the required Automation type. If the decisive fact for it is unknown, keep the result unresolved and collect the missing state instead of inferring it from wording.
Evidence and telemetry
- Record this result with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture arg-error index; original VARTYPE; expected VARTYPE; by-reference flags; locale; array element type.
- 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.
Log identifiers, sizes, type tags, states, and hashes while excluding credentials, tokens, document payloads, and complete user arguments.
Correct handling and recovery
The appropriate recovery is to inspect puArgErr, convert explicitly with the correct locale, preserve by-reference semantics, and update the interop signature to the type library. The owner of retry for it must define idempotency, refreshed state, maximum attempts, backoff, and cancellation responsibility.
After it, apply the API-specific validity rules to outputs and release only resources whose ownership transferred during this attempt.
Practical scenario
A date string works under one locale but fails under another; the client sends VT_DATE instead of relying on locale-sensitive coercion.
A regression test for it should force the decisive precondition, assert native outputs, fix only that condition, and confirm the expected neighboring result.
Difference from related HRESULTs
TYPE_E_TYPEMISMATCH describes type-library construction or metadata; it occurs while binding a live Automation call.
Represent this distinction for it directly in control flow and dashboards instead of grouping it under a single COM-failure label.
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::Invoke
- Microsoft: IDispatch::GetIDsOfNames
- Microsoft: EXCEPINFO
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.