What does HRESULT 0x80020012 (DISP_E_DIVBYZERO) mean?

 
Previous Next
DISP_E_NOTACOLLECTION DISP_E_BUFFERTOOSMALL

DISP_E_DIVBYZERO

Automation expression attempted division by zero

DISP_E_DIVBYZERO is HRESULT 2147614738 (0x80020012) from winerror.h. AllStat describes it as “Division by zero.” The value must be interpreted at an Automation expression, property calculation, script engine, or dispatch server numeric operation, because the same high-level symptom can come from a different contract boundary and require different cleanup.

The decisive interpretation for DISP_E_DIVBYZERO is that the divisor evaluated to zero in the target’s numeric semantics. A diagnostic event for DISP_E_DIVBYZERO should retain both representations of the HRESULT and the exact API boundary that produced it.

Where the result appears

  • DISP_E_DIVBYZERO is returned while Automation binds or executes an Automation expression, property calculation, script engine, or dispatch server numeric operation.
  • For DISP_E_DIVBYZERO, 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_DIVBYZERO includes puArgErr, EXCEPINFO, result VARIANT, by-reference values, and SAFEARRAY lock or ownership state; inspect them before cleanup.

Before assigning cause to DISP_E_DIVBYZERO, 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 DISP_E_DIVBYZERO are: input validation permits zero; a denominator underflows or rounds to zero; empty input coerces to zero; calculation order is wrong. The candidate causes for DISP_E_DIVBYZERO are alternatives, so test one precondition at a time instead of applying several broad repairs together.

The check that separates DISP_E_DIVBYZERO from nearby HRESULTs is: the divisor evaluated to zero in the target’s numeric semantics. When the boundary condition behind DISP_E_DIVBYZERO has not been proven, avoid retries or repairs that assume a different neighboring HRESULT.

Evidence and telemetry

  • Record DISP_E_DIVBYZERO with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
  • For DISP_E_DIVBYZERO, capture member or expression; numerator and divisor values; VARTYPE; rounding path; input provenance; locale parsing.
  • Log VARIANT type tags, dimensions, bounds, lengths, and null/empty distinctions for DISP_E_DIVBYZERO, 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_DIVBYZERO occurs.
  • After DISP_E_DIVBYZERO, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.

Telemetry for DISP_E_DIVBYZERO should be reproducible without copying secret values: prefer GUIDs, lengths, flags, sanitized names, and correlation IDs.

Diagnostic sequence

  • Capture DISP_E_DIVBYZERO (0x80020012) at IDispatch::GetIDsOfNames or IDispatch::Invoke before the language runtime converts it to a script exception.
  • For <code>DISP_E_DIVBYZERO</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_DIVBYZERO: the divisor evaluated to zero in the target’s numeric semantics.
  • Inspect the likely binding or representation causes for DISP_E_DIVBYZERO: input validation permits zero; a denominator underflows or rounds to zero; empty input coerces to zero; calculation order is wrong.
  • Reconstruct DISPPARAMS exactly, including reverse positional ordering and named argument placement, then reproduce DISP_E_DIVBYZERO with the smallest value set.
  • Verify the result VARIANT, EXCEPINFO, puArgErr, by-reference arguments, SAFEARRAY lock count, and object state after DISP_E_DIVBYZERO before deciding on retry.

Correct handling and recovery

For DISP_E_DIVBYZERO, the appropriate recovery is to validate the denominator before invocation, define the product behavior for zero, and preserve the original inputs for diagnosis. Before retrying DISP_E_DIVBYZERO, specify which precondition changed and how duplicate effects or stale outputs will be detected.

For DISP_E_DIVBYZERO, inspect every output before cleanup because interfaces, buffers, server effects, or metadata handles may be partially initialized.

Practical scenario

A pricing method divides by an optional quantity that defaults to zero; the client requires a positive quantity before calling.

Test DISP_E_DIVBYZERO by reproducing the smallest failing contract, recording postconditions, and then changing a single input or state transition.

Difference from related HRESULTs

DISP_E_OVERFLOW reports an out-of-range result; DISP_E_DIVBYZERO identifies the undefined divisor condition.

Keeping DISP_E_DIVBYZERO 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 DISP_E_DIVBYZERO at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>DISP_E_DIVBYZERO</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.

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