Site icon EfmSoft

What does HRESULT 0x800B0002 (TRUST_E_ACTION_UNKNOWN) mean?

 
Previous Next
TRUST_E_PROVIDER_UNKNOWN TRUST_E_SUBJECT_FORM_UNKNOWN

TRUST_E_ACTION_UNKNOWN

The important part of TRUST_E_ACTION_UNKNOWN is its scope: trust action dispatch. The GUID supplied to WinVerifyTrust does not map to an installed trust provider capable of performing that verification action. Keep the hexadecimal value 0x800B0002 with the returning API, because higher-level software may translate it into a message that loses this distinction.

Locate the first failing boundary

WinVerifyTrust dispatches by an action GUID to a trust provider and then interprets the subject through the WINTRUST_DATA union choice. Provider installation, action support, and subject form are separate contracts; capture both the GUID and the union member selected by dwUnionChoice.

Useful observations, not generic logs

  1. 1. Action GUID and installed provider capable of handling it
    Log the action GUID byte-for-byte and identify the component that registered or selected it.
  2. 2. WINTRUST_DATA structure size, union choice, subject fields, and state-action flags
    Check provider registration and process architecture on the failing machine.
  3. 3. A known-good subject verified with the same action and a known action for the same subject
    Use a documented action such as the generic verify-v2 policy when that matches the subject.

For trust action dispatch, these observations are deliberately nonsecret: identifiers, lengths, provider names, policy selections, and state transitions usually support comparison without recording private keys, passwords, PINs, or plaintext.

Build a timeline before changing state

In the path, trust verification is a pipeline, not one Boolean check. Align artifact acquisition, signature decoding, signer selection, countersignature or timestamp processing, chain construction, revocation retrieval, and final action policy. Preserve provider state before closing it so the generic top-level result can be connected to the stage that actually rejected the subject.

Reproduction without destructive cleanup

First call the documented standard action with its documented subject form., then change only the action GUID or union choice to match the production integration. This PINpoints dispatch versus subject representation in a trust action dispatch investigation.

  1. Preserve the original input, identity, provider or protocol selection, and first return Value.
  2. Use one known-good control that changes only the suspected part of the trust action dispatch path.
  3. reverse the comparison with known-good input on the failing layer where that can be done safely.
  4. Record where behavior first diverges in the trust action dispatch path instead of judging only by the final application message.

How this differs from similar failures

The subject may be well formed; the failure occurs before subject-specific policy because no action handler was selected. Trying random action GUIDs until one returns success changes the trust policy being asked, not merely the mechanism used to answer it in a trust action dispatch investigation.

For trust action dispatch, also retain the original numeric value; neighboring constants can encode materially different remediation paths even when an application presents all of them as an authentication, certificate, or security failure.

Regression check

The intended action must be handled by the intended provider using a supported subject form, and state data must be closed according to the API contract. Keep a regression case that uses nonsecret identifiers and expected outcomes, including one negative control that must continue to fail.

Technical references

These sources define the HRESULT and the relevant trust action dispatch interface, protocol, or data format.

Looking for a different code? Search another status or error code.

Exit mobile version