What does HRESULT 0x80270008 (NAP_E_MISMATCHED_ID) mean?

 
Previous Next
NAP_E_NOT_INITIALIZED NAP_E_NOT_PENDING

NAP_E_MISMATCHED_ID

The SoH request and response correlation IDs do not match

NAP_E_MISMATCHED_ID is HRESULT 0x80270008 (signed decimal -2144927736, unsigned decimal 2150039560). AllStat, using winerror.h, describes it as “The correlation id in the SoH-Request and SoH-Response do not match up.” The value has failure severity, facility 0x27, and code field 0x0008.

This is a legacy Network Access Protection result: Microsoft states that NAP is unavailable starting with Windows 10 and that current Windows Server releases do not include the former NAP, HRA, and HCAP roles; use the code for supported legacy systems, archived telemetry, compatibility components, or migrations rather than assuming a modern machine should expose the old platform.

The response belongs to a different exchange

NAP uses a CorrelationId to pair a Statement of Health response with the request that caused it. A packet can be structurally valid and still be unsafe to apply if its identifier names another connection, another request generation, or an older retry. This HRESULT protects the enforcement decision from cross-wiring concurrent or delayed health exchanges.

How correlation is lost

  • An enforcement client reuses one connection object for overlapping exchanges and overwrites the stored correlation ID.
  • A delayed server response arrives after timeout and is attached to a newer request on the same network session.
  • Serialization swaps fields or truncates the correlation structure while other SoH attributes remain valid.
  • A broker routes responses by client address rather than by the complete NAP connection and correlation identifiers.
  • Retry logic creates a new request ID but preserves the response object from the previous generation.

Correlation evidence

  • Log request and response IDs in the same canonical byte order, plus the string correlation ID intended for diagnostics.
  • Record connection ID, enforcement entity ID, request generation, send/receive timestamps, and transport session.
  • Keep a short history of completed and expired IDs so a late response can be identified without accepting it.
  • Capture where SetCorrelationId, GetCorrelationId, SetSoHRequest, and SetSoHResponse were called on the connection object.

Finding the crossed generation

  • Trace a single request from ID creation through packet serialization, server validation, deserialization, and response attachment.
  • Disable parallel exchanges temporarily; disappearance of the error points to shared mutable connection state or routing.
  • Compare the rejected response ID with recently timed-out IDs and identify whether it is late rather than corrupted.
  • Audit object pooling and connection reuse so identifiers are reset atomically with every new exchange.

Difference from nearby NAP results

NAP_E_INVALID_PACKET concerns malformed encoding, while NAP_E_MISMATCHED_ID can occur with two perfectly valid packets. NAP_E_NOT_PENDING concerns completion of a request whose asynchronous state no longer exists. A matching correlation ID is necessary but still does not prove that the health verdict is valid or current.

Retry and recovery

Reject the response and do not update isolation state from it. A fresh exchange may be started with a new identifier after the routing or lifetime defect is corrected. Never “fix” the packet by copying the current request ID into an old response; that destroys the protocol guarantee the field provides.

Practical scenario

Two VPN enforcement connections are validated concurrently, but a callback table is keyed only by user name. Their responses are reversed and one path returns NAP_E_MISMATCHED_ID. Keying the table by connection plus correlation ID restores deterministic pairing.

References

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