| Previous | Next |
| NAP_E_CONFLICTING_ID | NAP_E_STILL_BOUND |
NAP_E_NO_CACHED_SOH
The health agent has no cached Statement of Health
NAP_E_NO_CACHED_SOH is HRESULT 0x80270004 (signed decimal -2144927740, unsigned decimal 2150039556). AllStat, using winerror.h, describes it as “No cached SoH is present.” The value has failure severity, facility 0x27, and code field 0x0004.
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.
A time-sensitive SHA callback condition
Microsoft documents this value in the GetSoHRequest callback path. That callback must return immediately and must not perform slow health monitoring. If fresh computation will take time, the SHA should return a cached SoH; if no cached statement exists, it should return a failure-category packet containing NAP_E_NO_CACHED_SOH and later call NotifySoHChange when current health data is ready.
Why the cache is empty
- The SHA has just started, has not completed its first posture evaluation, and no previous result was persisted by NapAgent.
- FlushCache was called during a configuration or remediation change before the replacement SoH was generated.
- The NapAgent removed the SHA from the bound list and cleared its cache after an RPC server-unavailable failure.
- A component version or health-ID change made an older cached statement inapplicable to the current SHA.
- The SHA incorrectly performs all monitoring inside GetSoHRequest and reaches the callback before any background result exists.
Cache and generation telemetry
- Log cache generation, age, SystemHealthEntityId, and the reason the previous entry was absent or flushed.
- Record callback duration separately from the background health-check duration; a fast callback with no cache is different from a blocked callback.
- Capture the time of the following NotifySoHChange and whether a subsequent exchange obtains a valid statement.
- Preserve service restart, SHA rebind, policy update, and remediation timestamps that could invalidate cached posture.
Restoring the producer pipeline
- Move expensive health inspection to a worker or service and let the callback read an immutable completed result.
- Create an initial explicit “health unavailable” state rather than waiting indefinitely for the first scan.
- Confirm that NotifySoHChange is emitted only after the new statement is fully built and visible to the callback thread.
- Test startup, cache flush, NapAgent restart, and rapid policy-change sequences independently.
Difference from nearby NAP results
This code does not mean that the NAP packet itself omitted an expected SoH in transit; that server-observed condition is NAP_E_MISSING_SOH. It also is not a health verdict. The failure category says the client component cannot currently provide posture data, and policy decides how that infrastructure failure affects access.
Retry and recovery
Return promptly with the documented failure packet, finish health evaluation asynchronously, then trigger a new SoH exchange. A tight retry from the caller can amplify load while the cache is still empty. The useful retry boundary is the new generation announced by NotifySoHChange, not a timer that repeatedly calls the same callback.
Practical scenario
After a policy update, an SHA flushes its cache and begins a full compliance scan. NapAgent requests an SoH before the scan completes. The SHA immediately reports NAP_E_NO_CACHED_SOH, publishes the completed statement later, and calls NotifySoHChange to initiate a fresh exchange.
References
- Microsoft: NAP error constants
- Microsoft: GetSoHRequest and cached SoH behavior
- Microsoft: FlushCache
- Microsoft: SHA binding interface
Looking for a different code? Search another status or error code.