| Previous | Next |
| ERROR_HV_INVALID_PROXIMITY_DOMAIN_INFO | ERROR_HV_INACTIVE |
ERROR_HV_NO_DATA
ERROR_HV_NO_DATA is HRESULT 0xC035001B in the hypervisor debug data retrieval area of the Windows virtualization stack. It applies to a debug or diagnostic read against a hypervisor connection that currently has no record available.
State and ownership model
The transport or debug interface is reachable enough to answer, but there is no data to return for this read. That can be a normal empty condition or evidence that capture was never enabled; it is not by itself proof that the hypervisor failed.
This result belongs to the hypervisor facility rather than the higher-level VM management UI. The TLFS and WHP documentation provide the surrounding partition, message, memory, and virtual-processor model, but the first low-level operation and any nested status remain the authoritative incident evidence.
Neighboring result: ERROR_HV_INACTIVE concerns lack of receive activity on the physical debugging connection. NO_DATA is about the current read result even when the connection exists.
Capture before changing anything
| Evidence | Why it changes the diagnosis |
|---|---|
| Debug channel identity | Record transport, target, session generation, and whether capture was enabled. |
| Read timing | Keep polling interval, timeout, last successful record, and expected producer event. |
| Producer state | Confirm the target reached the point that should emit debug data. |
| Consumption history | Record whether another reader drained the same channel or ring first. |
Reduce the case safely
- Trigger one known diagnostic event and correlate its timestamp with the read.
- Distinguish nonblocking empty reads from timeout or disconnect results.
- Ensure only the intended consumer owns the stream.
- Do not restart the VM solely to manufacture data; first prove the expected producer path ran.
Test this result with one known event, one known idle interval, and one known-good transport path. During the comparison, keep session generation and reader ownership explicit so empty data is not confused with a dead connection.
What comparison can tell you
| Control | Interpretation | Hold constant |
|---|---|---|
| Known-good transport path | Using the same debugger against a known-good target can localize it to target configuration versus physical/network transport. | Preserve debugger version and endpoint settings. |
| Idle versus disconnected interval | An intentional idle interval should not look identical to a broken link. Compare timestamps and keepalive activity around it. | Hold polling interval and timeout fixed in the test. |
| Known diagnostic event | Trigger one controlled event. Its presence or absence distinguishes it empty data, liveness, and capture-configuration paths. | Keep the same target, transport, session generation, and reader. |
Do not erase the evidence
Do not equate it with a failed VM before separating an empty read, inactive physical transport, missing producer event, and a second reader that drained the channel. Keep that distinction explicit in the incident record.
Keep the hexadecimal result value and any nested hypervisor status. Higher layers can map distinct resource, buffer, message, or state failures to the same generic start or migration message.
Closure criteria
The path is healthy when a controlled event yields one expected record and an intentionally idle interval returns NO_DATA without being treated as fatal.
Technical references
- Microsoft Open Specifications: HRESULT values — used to interpret this result.
- Microsoft: Hyper-V TLFS — used to interpret this result.
- Microsoft: Hyper-V operational troubleshooting — used to interpret this result.
- Microsoft: Hyper-V event-log collection guidance — used to interpret this result.
Looking for a different code? Search another status or error code.