| Previous | Next |
| NAP_E_INVALID_PACKET | NAP_E_CONFLICTING_ID |
NAP_E_MISSING_SOH
The expected Statement of Health is missing
NAP_E_MISSING_SOH is HRESULT 0x80270002 (signed decimal -2144927742, unsigned decimal 2150039554). winerror.h describes it as “An SoH was missing from the NAP packet.” The value has failure severity, facility 0x27, and code field 0x0002.
For legacy NAP validation, this result means the expected Statement of Health is absent at the validator boundary. Distinguish that missing input from a present-but-malformed packet and from an SHA that merely lacks a cached statement.
Absence of health data, not malformed health data
This result is used when a validation path expects a Statement of Health request but none is available. Microsoft documents a precise SHV behavior: when GetSoHRequest yields a null packet, an ordinary validator should populate a response with this error. An intrusion-detection validator may instead create its own request describing why the client is considered malicious. The code therefore reflects missing input at the SHA-to-SHV contract boundary.
How an SoH can disappear
- The client enforcement path sent a NAP envelope without the SHA-specific SoH that the server-side validator expected.
- A registered SHA was not bound or failed before producing health data, so the system-generated request did not contain normal posture attributes.
- An intermediary filtered an attribute by SystemHealthEntityId or rebuilt a packet while omitting an empty-looking SoH element.
- The SHV queried the request object before the NAP server had associated the intended statement, or used the wrong validation request instance.
- Legacy client and server configuration disagree about which SHAs and SHVs participate in the enforcement scenario.
What to capture
- Record the SystemHealthEntityId requested by the SHV and enumerate the SoH attributes that actually arrived.
- Preserve the napSystemGenerated flag from GetSoHRequest; a system-generated failure packet must be interpreted differently from a normal SHA statement.
- Correlate SHA registration, binding state, NotifySoHChange activity, enforcement-client connection ID, and server validation request ID.
- Log whether other SHAs supplied statements in the same exchange, which separates a component-specific omission from loss of the entire NAP payload.
Tracing the missing statement
- Verify that the SHA is registered with the same numeric health ID that the SHV expects.
- Confirm that the SHA binding initialized successfully and that its GetSoHRequest callback is reached when the NapAgent requests health data.
- Inspect the enforcement transport before and after encapsulation to determine whether the SoH existed on the client but was dropped later.
- On the server, retrieve the request once per documented lifecycle and avoid substituting an unrelated cached validation object.
Difference from nearby NAP results
NAP_E_INVALID_PACKET means bytes are present but invalid. NAP_E_NO_CACHED_SOH is more specific to an SHA that cannot produce fresh health information quickly and has no cached statement to return. NAP_E_NOT_INITIALIZED reports an unbound SHA rather than merely the absence observed by the SHV.
Retry and recovery
Do not manufacture a healthy response. Return or preserve this result so policy can map the component failure explicitly, then restore the SHA registration, binding, or transport path. A new validation is safe after the producer can supply a statement; repeatedly validating the same request object cannot create the missing data.
Practical scenario
A server has an antivirus SHV enabled, but the matching SHA was removed from an older client image. The NAP packet reaches the validator without that health statement. The SHV returns a response containing this result, allowing policy to distinguish unavailable posture data from an antivirus compliance failure.
References
Looking for a different code? Search another status or error code.