| Previous | Next |
| ERROR_VID_MESSAGE_QUEUE_ALREADY_EXISTS | ERROR_VID_MB_STILL_REFERENCED |
ERROR_VID_EXCEEDED_MBP_ENTRY_MAP_LIMIT
ERROR_VID_EXCEEDED_MBP_ENTRY_MAP_LIMIT is HRESULT 0xC037000C in the VID memory-block-page map accounting area of the Windows virtualization stack. It applies to the number of mapped VID memory-block-page entries tracked for a partition or host context.
Why this result is specific
The requested mapping would exceed an internal page-entry map limit. Count active mappings and their lifetime; host free RAM alone does not explain this accounting bound.
Neighboring result: MBP_COUNT_EXCEEDED_LIMIT applies while creating a memory block with too many pages; ENTRY_MAP_LIMIT concerns mapping entries accumulated or requested later.
Records worth collecting
| Evidence | Why it changes the diagnosis |
|---|---|
| Memory block and range | Record handle, GPA start, page count, access flags, and mapping owner. |
| Active map inventory | Count mapped entries by partition and generation. |
| Unmap symmetry | Compare successful maps with unmaps, including error rollback. |
| Scale boundary | Capture the last successful and first failing map count. |
A reproducible test plan
- Coalesce adjacent mappings where the API and access semantics permit.
- Unmap on every teardown and partial-failure path.
- Reuse stable mappings instead of repeatedly mapping the same pages.
- Stress map/unmap cycles and watch the active count return to baseline.
Use a controlled partition or disposable VM when a mapping, lock, or teardown test can be destructive. During the test run, keep page units, GPA boundaries, parent object, handle generation, and release order visible.
Comparison matrix
| Control | Interpretation | Hold constant |
|---|---|---|
| Smaller exact range | Reduce only page count or mapped extent. If this result moves, range arithmetic, object limits, or reserve capacity is involved. | Keep the same block, GPA base, flags, and partition generation. |
| Balanced fresh lifecycle | Create, use, release, and destroy one object instance. If a different result appears after recreation, investigate leaked references, locks, handles, or mappings. | Preserve sizes and operation order while changing only generation. |
| Same request under lower host pressure | 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. |
Misleading shortcuts
Verification after repair
The original workload remains below the understood limit with no growth across repeated lifecycle cycles.
Technical references
- Microsoft Open Specifications: HRESULT values — used to interpret this result.
- Microsoft: WHvMapGpaRange — used to interpret this result.
- Microsoft: WHP memory data types — used to interpret this result.
- Microsoft: Hyper-V architecture — used to interpret this result.
Looking for a different code? Search another status or error code.