What does HRESULT 0x80020008 (DISP_E_BADVARTYPE) mean?

 
Previous Next
DISP_E_NONAMEDARGS DISP_E_EXCEPTION

DISP_E_BADVARTYPE

Automation call contains an invalid VARIANT type

DISP_E_BADVARTYPE is HRESULT 2147614728 (0x80020008) from winerror.h. AllStat describes it as “Bad variable type.” The value must be interpreted at VARIANTARG validation before or during IDispatch invocation, because the same high-level symptom can come from a different contract boundary and require different cleanup.

The decisive interpretation for DISP_E_BADVARTYPE is that a VARIANT has an unsupported, reserved, inconsistent, or malformed VARTYPE encoding. The operational record for DISP_E_BADVARTYPE needs the native value, symbolic constant, component build, and call phase; the message alone is insufficient.

Where the result appears

  • DISP_E_BADVARTYPE is returned while Automation binds or executes VARIANTARG validation before or during IDispatch invocation.
  • For DISP_E_BADVARTYPE, retain the member name and DISPID, invocation flags, LCID, cArgs, cNamedArgs, and the exact VARIANTARG sequence in reverse Automation order.
  • The output contract for DISP_E_BADVARTYPE includes puArgErr, EXCEPINFO, result VARIANT, by-reference values, and SAFEARRAY lock or ownership state; inspect them before cleanup.

For DISP_E_BADVARTYPE, separate caller state from runtime and server state first; otherwise cleanup and retry may target the wrong generation of the operation.

Typical causes and interpretation boundary

Common cause categories for DISP_E_BADVARTYPE are: the VARIANT was not initialized; flags are combined illegally; the union field does not match vt; memory corruption changed the tag. Each possible cause of DISP_E_BADVARTYPE predicts different outputs and recovery behavior, which should be verified explicitly.

The check that separates DISP_E_BADVARTYPE from nearby HRESULTs is: a VARIANT has an unsupported, reserved, inconsistent, or malformed VARTYPE encoding. Without proof of the distinguishing condition for DISP_E_BADVARTYPE, the safest action is to preserve evidence and refrain from destructive cleanup.

Evidence and telemetry

  • Record DISP_E_BADVARTYPE with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
  • For DISP_E_BADVARTYPE, capture vt value; union field used; VT_BYREF and VT_ARRAY flags; initialization path; ownership and VariantClear result.
  • Log VARIANT type tags, dimensions, bounds, lengths, and null/empty distinctions for DISP_E_BADVARTYPE, but redact actual confidential argument values.
  • Preserve the caller language/runtime, generated interop version, LCID, and whether the call crossed a process boundary when DISP_E_BADVARTYPE occurs.
  • After DISP_E_BADVARTYPE, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.

A useful DISP_E_BADVARTYPE event contains ownership and shape information, not raw documents, passwords, access tokens, or full Automation values.

Diagnostic sequence

  • Capture DISP_E_BADVARTYPE (0x80020008) at IDispatch::GetIDsOfNames or IDispatch::Invoke before the language runtime converts it to a script exception.
  • For <code>DISP_E_BADVARTYPE</code>, resolve the deployed member signature from ITypeInfo and compare its DISPIDs, parameter flags, VARTYPEs, optional values, and property-put rules with the caller.
  • Prove the decisive condition for DISP_E_BADVARTYPE: a VARIANT has an unsupported, reserved, inconsistent, or malformed VARTYPE encoding.
  • Inspect the likely binding or representation causes for DISP_E_BADVARTYPE: the VARIANT was not initialized; flags are combined illegally; the union field does not match vt; memory corruption changed the tag.
  • Reconstruct DISPPARAMS exactly, including reverse positional ordering and named argument placement, then reproduce DISP_E_BADVARTYPE with the smallest value set.
  • Verify the result VARIANT, EXCEPINFO, puArgErr, by-reference arguments, SAFEARRAY lock count, and object state after DISP_E_BADVARTYPE before deciding on retry.

Correct handling and recovery

For DISP_E_BADVARTYPE, the appropriate recovery is to initialize with VariantInit, assign a supported VARTYPE and matching field, validate custom marshaling, and clear only owned values. For DISP_E_BADVARTYPE, repeat the operation only after the failed condition has changed and the caller can distinguish a duplicate effect.

When DISP_E_BADVARTYPE is returned, use the documented output contract and reconcile remote or persistent effects before replaying the request.

Practical scenario

A native caller leaves stack garbage in vt before assigning a BSTR pointer; VariantInit removes the invalid type tag.

An automated test for DISP_E_BADVARTYPE should verify raw HRESULT, output ownership, cleanup behavior, and the absence of an unsafe automatic retry.

Difference from related HRESULTs

DISP_E_TYPEMISMATCH means a valid VARIANT cannot satisfy the parameter type; DISP_E_BADVARTYPE means the VARIANT representation itself is invalid.

The comparison matters operationally for DISP_E_BADVARTYPE: one result may permit fallback while the other requires repair, cancellation, or state reconciliation.

Developer and administrator guidance

Automation adapters should handle DISP_E_BADVARTYPE at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>DISP_E_BADVARTYPE</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.

For DISP_E_BADVARTYPE, deployment owners should compare the registered type library and server binary as one versioned unit. After <code>DISP_E_BADVARTYPE</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.