| Previous | Next |
| ERROR_HV_INACTIVE | ERROR_HV_FEATURE_UNAVAILABLE |
ERROR_HV_NO_RESOURCES
ERROR_HV_NO_RESOURCES is HRESULT 0xC035001D in the generic hypervisor resource exhaustion area of the Windows virtualization stack. It applies to a hypervisor-managed resource class that is not narrowed by this HRESULT to ordinary memory or a caller buffer.
Object lifecycle behind the result
The operation could not reserve one of the hypervisor resources it needs. Because the code is intentionally broad, the preceding operation and event payload are essential to identify whether the constrained object is a partition, VP, mapping, message slot, or another internal allocation.
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: Use more specific companions when present: INSUFFICIENT_MEMORY identifies memory, while the buffer statuses identify caller/message shape. Do not overwrite a specific earlier code with this generic result.
Diagnostic evidence matrix
| Evidence | Why it changes the diagnosis |
|---|---|
| First failing operation | Record the lowest-level request before management layers retry or translate it. |
| Object counts | Capture partitions, VPs, mappings, queues, and concurrent start or migration work. |
| Host pressure | Keep memory, handle, pool, and relevant Hyper-V performance counters. |
| Release behavior | Note whether deleting one controlled object frees capacity for the exact same request. |
Test one variable at a time
- Reduce one resource dimension at a time and graph the failure threshold.
- Check for leaked objects by comparing create/delete counts and generations.
- Collect host events before a restart erases the saturation pattern.
- Avoid unbounded retries that increase pressure on the same resource class.
Test the smallest supported create, lookup, initialize, or resource request that preserves the named condition. In the result reproduction, change one count, identity, or lifecycle step at a time and capture the first host event before retry.
How to read the controls
| Control | Interpretation | Hold constant |
|---|---|---|
| Fresh owned object | A clean lifecycle changing this result implicates duplicate initialization, leaked ownership, stale lookup, or incomplete rollback. | Preserve request flags and topology while changing only object instance. |
| Same request on a compatible host | If it follows one host, compare resource limits, topology, build, and inventory before altering VM data. | Use the same request and leave virtual disks unchanged in the result comparison. |
| One operation parameter | Change one count, name, identity, or state transition. If it moves, the selected condition is causal rather than the VM as a whole. | Keep host build, VM ID, and returning operation fixed. |
Scope of this status
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.
Regression proof
A repair must restore the original operation at production scale and demonstrate that resources return to baseline after teardown.
Technical references
- Microsoft Open Specifications: HRESULT values — used to interpret this result.
- Microsoft: Hyper-V architecture — used to interpret this result.
- Microsoft: Hyper-V TLFS — used to interpret this result.
- Microsoft: Hyper-V operational troubleshooting — used to interpret this result.
Looking for a different code? Search another status or error code.