| Previous | Next |
| ERROR_HV_PROPERTY_VALUE_OUT_OF_RANGE | ERROR_HV_PARTITION_TOO_DEEP |
ERROR_HV_INSUFFICIENT_MEMORY
ERROR_HV_INSUFFICIENT_MEMORY is HRESULT 0xC035000B in the hypervisor pool capacity area of the Windows virtualization stack. The built-in message names the immediate result; the useful custom context is the exact boundary: memory owned or reserved by the hypervisor for partition, virtual-processor, mapping, or virtualization bookkeeping. Record the first returning operation and host-side event before a management layer retries or translates it.
Why this HRESULT is specific
The host can have ordinary free memory while the specific hypervisor pool or allocation class needed by the operation cannot satisfy the request. Treat this as a host-capacity and fragmentation question at the exact operation boundary.
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 boundary.
Neighboring result: Unlike a caller output-buffer error, increasing a user-mode byte array does not address this result. Unlike ERROR_HV_NO_RESOURCES, this status identifies memory as the constrained class.
Records worth collecting
| Evidence | Why it changes the diagnosis |
|---|---|
| Host memory state | Capture committed bytes, available memory, Hyper-V dynamic-memory pressure, and the set of running partitions. |
| Requested operation | Record whether the failure occurred while creating a partition, mapping GPA, adding a VP, starting, restoring, or migrating. |
| Scale parameters | Keep requested VM memory, vCPU count, mappings, and concurrent VM starts. |
| Fragmentation timeline | Note host uptime, repeated create/delete cycles, checkpoints, and the last successful request of the same size. |
Preserve identifiers and counts without dumping guest secrets or unrelated memory. Useful this result timestamps include the last successful operation, first failure, any automatic retry, and the object-generation change that followed.
A reproducible test plan
- Repeat on the same host after stopping one controlled VM, without changing the failing VM.
- Try a smaller supported memory or processor configuration to establish the capacity slope.
- Check host and Hyper-V event logs before restarting services or the host.
- Do not interpret guest free memory as evidence about the host hypervisor pool.
Use a controlled partition or disposable VM when a mapping, lock, or teardown test can be destructive. During the result run, keep page units, GPA boundaries, parent object, handle generation, and release order visible.
Comparison matrix
Across these controls for it, preserve memory owned or reserved by the hypervisor for partition, virtual-processor, mapping, or virtualization bookkeeping as the boundary under test.
| Control | Interpretation | Hold constant |
|---|---|---|
| Same request under lower host pressure — this result | If it changes after controlled pressure is removed, quantify host/pool capacity; if not, focus on caller bookkeeping. | Do not modify guest disks or unrelated VM devices during the result comparison. |
| Smaller exact range — it | Reduce only page count or mapped extent. If it moves, range arithmetic, object limits, or reserve capacity is involved. | Keep the same block, GPA base, flags, and partition generation for it. |
| Balanced fresh lifecycle — it | Create, use, release, and destroy one object generation. A different it exposes leaked references, locks, handles, or mappings. | Preserve sizes and operation order while changing only generation. |
Misleading shortcuts
Restarting can release the exact lock, reference, mapping, or opaque handle behind it without fixing the lifecycle defect. Before recovering from it, preserve the object graph and acquire/release counts.
Keep the hexadecimal it 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.
Verification after repair
The correction is proven when the original allocation succeeds repeatedly at the required scale and host pressure remains within an understood operating margin. Repeat the original operation under the original supported conditions and retain one deliberate negative control. A management command succeeding on a different object is not sufficient to close this incident.
Technical references
These sources define it and the public Hyper-V architecture surrounding the internal state. They do not create a public user-mode VID API for the named object.
- Microsoft Open Specifications: HRESULT values — used to interpret the boundary.
- Microsoft: WHvMapGpaRange — used to interpret the boundary.
- Microsoft: WHP memory data types — used to interpret the boundary.
- Microsoft: Hyper-V architecture — used to interpret the boundary.
Looking for a different code? Search another status or error code.