| Previous | Next |
| DISP_E_BADVARTYPE | DISP_E_OVERFLOW |
DISP_E_EXCEPTION
Automation target raised an exception
DISP_E_EXCEPTION is HRESULT 2147614729 (0x80020009) from winerror.h. AllStat describes it as “Exception occurred.” The value must be interpreted at IDispatch::Invoke returning component-provided failure details through EXCEPINFO, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the invoked method or property executed far enough to raise an application exception rather than an argument-binding error. Treat this result as a contract result from its owning subsystem and retain the unmodified HRESULT in logs and test assertions.
Where the result appears
- This result is returned while Automation binds or executes IDispatch::Invoke returning component-provided failure details through EXCEPINFO.
- 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.
Map this result to one concrete invocation and one concrete object or metadata identity before interpreting the human-readable description.
Typical causes and interpretation boundary
Common cause categories for it are: application validation fails; a script exception escapes; a server translates its internal error into EXCEPINFO; property code throws. The evidence should distinguish configuration, lifetime, input, identity, resource, and version failures rather than grouping them.
The check that separates this result from nearby HRESULTs is: the invoked method or property executed far enough to raise an application exception rather than an argument-binding error. The text of it narrows the search, but the owning API state must confirm the condition before automation changes the system.
Evidence and telemetry
- Record it with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture EXCEPINFO source, description, help context and scode; member DISPID; inputs; component logs; deferred-fill callback result.
- 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.
For privacy-safe diagnosis of it, capture the call schema and state transitions but hash or omit confidential payloads.
Correct handling and recovery
The appropriate recovery is to preserve EXCEPINFO before freeing BSTRs, report the component-specific message safely, and correct the underlying application condition rather than changing dispatch syntax. Recovery from it should name the component responsible for retry and the evidence that makes another attempt safe.
The failure path for it should leave outputs in a known state and avoid double release, double commit, or reuse of stale pointers.
Practical scenario
A report server throws a domain exception for a closed accounting period; the client displays the sanitized EXCEPINFO description and does not retry.
To prevent recurrence of it, preserve a minimal fixture that asserts both the failing condition and the state after recovery.
Difference from related HRESULTs
DISP_E_BADCALLEE indicates a broken callee contract; it is the normal Automation container for an application-level exception.
Classify it by the stated contract difference, since severity bits alone do not determine the correct response.
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: VARIANT structure
- Microsoft: VariantClear
- Microsoft: IDispatch::Invoke
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.