| Previous | Next |
| NAP_E_ID_NOT_FOUND | NAP_E_SERVICE_NOT_RUNNING |
NAP_E_MAXSIZE_TOO_SMALL
The connection cannot carry an SoH packet of the required size
NAP_E_MAXSIZE_TOO_SMALL is HRESULT 0x8027000B (signed decimal -2144927733, unsigned decimal 2150039563). AllStat, using winerror.h, describes it as “The maximum size of the connection is too small for an SoH packet.” The value has failure severity, facility 0x27, and code field 0x000B.
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.
Transport capacity is below the health payload requirement
An enforcement client supplies ProtocolMaxSize for its connection, and the NAP exchange must fit within that transport limit. NAP_E_MAXSIZE_TOO_SMALL means the available maximum cannot contain the required Statement of Health packet. It is a capacity negotiation failure, not evidence that the SoH fields are malformed or that the endpoint failed policy.
Why the size budget is insufficient
- The enforcement transport advertises a very small payload limit or subtracts headers twice.
- Too many SHAs contribute large statements to one exchange and the aggregate exceeds the connection budget.
- A custom health attribute carries verbose text, certificates, or diagnostic data that does not belong in the compact SoH.
- The caller initializes ProtocolMaxSize in the wrong units or truncates it through a narrower integer type.
- A changed network encapsulation adds overhead but the enforcement client continues using an older maximum.
Size accounting
- Record ProtocolMaxSize, serialized SoH size, transport overhead, attribute count, and each attribute’s encoded length.
- Capture which enforcement client set the maximum and whether the value changed between connection generations.
- Compare the same health payload over another enforcement transport to separate payload growth from transport limits.
- Log pre-serialization logical sizes and final wire size so alignment and framing overhead are visible.
Reducing or increasing the correct quantity
- Validate that SetMaxSize receives bytes and the complete unsigned structure expected by the API.
- Remove redundant or non-policy data from custom SoH attributes without dropping required identity or failure fields.
- Confirm the enforcement protocol’s real maximum before increasing the value; advertising more than the transport can carry causes later truncation.
- Retest with the exact serialized packet and verify it fits after all encapsulation.
Difference from nearby NAP results
NAP_E_INVALID_PACKET reports invalid structure, whereas this code can occur for a perfectly valid packet that is simply too large. NAP_E_MISSING_SOH should not be used as a fallback after silently dropping oversized health data. A transport-level fragmentation error may occur later and must not be mislabeled as this NAP capacity result without the call site.
Retry and recovery
A retry with unchanged maximum and unchanged packet size will fail again. Recovery requires a supported larger transport budget, a smaller standards-compliant SoH, or fewer optional attributes. Never truncate the serialized packet at the byte limit because that converts a clear capacity error into an invalid or misleading health message.
Practical scenario
A custom SHA adds a diagnostic certificate chain to its SoH, increasing the aggregate packet beyond a VPN enforcement client’s ProtocolMaxSize. NAP returns NAP_E_MAXSIZE_TOO_SMALL. Moving the chain to a separate diagnostic channel and keeping only a compact result code restores the exchange.
References
- Microsoft: NAP error constants
- Microsoft: SetMaxSize
- Microsoft: enforcement connection interface
- Microsoft: SoH validation
Looking for a different code? Search another status or error code.