| Previous | Next |
| E_OUTOFMEMORY | E_PROP_ID_UNSUPPORTED |
E_INVALIDARG
The short system message identifies the immediate outcome, but the useful interpretation is narrower: argument validation. In this case, one or more supplied values violate the called method’s documented range, combination, structure version, or object-state precondition.
Start with the failing layer
COM activation is a sequence rather than a single operation: registration lookup, SCM or surrogate selection, process startup, class-factory publication, marshaling, and finally the requested interface call when diagnosing argument validation. The useful evidence is the evidence from the first stage that fails; a later RPC or cleanup message can otherwise hide the original activation problem for an incident involving argument validation.
Do not collapse this result into a nearby status. Do not translate every failure with bad input into E_INVALIDARG; access, state, and unsupported-operation codes identify different contracts. For argument validation, compare the lifecycle stage, object identity, caller context, and first returning API—not only the English wording or the final dialog shown to the user.
Preserve before retrying
| Incident evidence | Question it answers |
|---|---|
| The exact API signature and every argument value before wrapper conversion | Separates a contract or configuration defect from a transient environmental failure in an incident involving argument validation. |
| Structure size/version fields, flags, reserved members, counts, and pointer/count pairs | Provides a stable comparison point for a controlled reproduction before changing the state involved in argument validation. |
| The object state and thread/apartment from which the call was made | Shows whether the proposed correction changes the first failing boundary during verification of argument validation. |
| A minimal known-good call assembled from the same SDK version | Locates the exact attempt and prevents evidence from a later retry from being mixed into it when diagnosing argument validation. |
Identifiers, timestamps, versions, counts, state flags, hashes, and redacted paths normally provide enough correlation when diagnosing argument validation. Keep credentials, private keys, message bodies, recovery material, and personal data out of routine incident logs for an incident involving argument validation.
Three useful comparisons
- Start from the minimal valid argument set and add one option at a time; keep every other input fixed and record the first event that differs from the failing run.
- Hold data constant while changing only structure version or flag combination; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Assert ranges and pointer/count invariants immediately before the call; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
For argument validation, a retry becomes evidence only when one controlled variable changes. In the argument validation case, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
Decision points
The following decision points keep the investigation tied to the returning operation for argument validation:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | For argument validation, the platform path is available; concentrate on the production object, arguments, identity, policy, or lifecycle state described above. |
| The control fails at the same first operation | For argument validation, failure of the control points below application-specific data; preserve service, provider, operating-system, or host evidence before changing the environment. |
| A different HRESULT appears after one controlled change | The argument validation boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
A defensible fix
Repair the failed contract rather than the surrounding system: Correct the caller contract and add validation at the closest boundary; retries with unchanged arguments cannot repair this result. For argument validation, preserve the pre-change export or trace and document the exact configuration, build, identity, object, or policy that changed.
Close the incident only when unit tests cover lower/upper bounds, null/count combinations, unknown flags, and the exact production argument set. For argument validation, repeat the original supported operation under the original identity and object state, then retain one deliberate boundary or negative test. A result from a different account, simplified input, replacement object, or unrelated machine is useful comparison data for argument validation, but it is not regression proof.
Technical references
These references define the HRESULT family and the subsystem contract used above for argument validation:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: COM clients and servers.
- Microsoft: CoGetClassObject.
- Microsoft: COM elevation moniker.
Looking for a different code? Search another status or error code.