Geoff Chappell - Software Analyst
The MI_VAD_ALLOCATION_CELL structure (formally _MI_VAD_ALLOCATION_CELL) was introduced for the 1511 release of Windows 10. The only known use of the structure is that the MI_USER_VA_INFO structure has an array of them as its VadCell member. There are variously two or three in the array, indexed by the MI_VAD_ALLOCATION_CELL_TYPE enumeration.
Up to and including the original Windows 10, the MI_USER_VA_INFO (and before it, the MMWSL) provided for managing bottom-up and top-down allocations from one region of virtual address space. For the 1511 release to have bottom-up allocations from two regions, relevant members were reproduced within the MI_USER_VA_INFO by moving them into a new MI_VAD_ALLOCATION_CELL for each region. Version 1803 elaborated so that top-down allocations join in.
The MI_VAD_ALLOCATION_CELL is not just an internal structure with little, if any, visibility outside the kernel: it is one that exists only to have extracted members from another such internal structure. Though the members are few, variability cannot surprise. The following changes of size mark the additions and rearrangements:
Version | Size (x86) | Size (x64) |
---|---|---|
1511 to 1709 | 0x1C | 0x28 |
1803 to 1809 | 0x24 | 0x38 |
1903 to 2004 | 0x24 | 0x48 |
These sizes in the previous table and the offsets, names and types in the next are from public symbol files for the Version 1511 kernel. What’s shown for later versions is something of a guess because no known public symbol files for later releases of Windows 10 have type information for this structure.
Offset (x86) | Offset (x64) | Definition | Versions | Remarks |
---|---|---|---|---|
0x00 | 0x00 |
RTL_BITMAP AllocationBitMap; |
1511 to 1809 | |
RTL_BITMAP_EX AllocationBitMap; |
1903 and higher | |||
0x08 | 0x10 |
ULONG BitMapHint; |
1511 and higher | |
0x0C | 0x14 |
ULONG LastAllocationSize; |
1511 and higher | |
0x10 | 0x18 |
ULONG LastAllocationSizeHint; |
1511 and higher | |
0x14 (1511 to 1709) | 0x1C (1511 to 1709) |
ULONG LowestBottomUpVadBit; |
1511 to 1709 | next at 0x20 and 0x30 |
0x14 | 0x1C (1803 to 1809); 0x28 |
ULONG HighestTopDownVadBit; |
1803 to 1809 | |
ULONG_PTR HighestTopDownVadBit; |
1903 and higher | |||
0x18 | 0x20 (1803 to 1809); 0x30 |
PVOID HighestTopDownAllocationAddress; |
1803 and higher | |
0x18 (1511 to 1709); 0x1C |
0x20 (1511 to 1709); 0x28 (1803 to 1809); 0x38 |
PVOID LowestBottomUpAllocationAddress; |
1511 and higher | |
0x20 | 0x30 (1803 to 1809); 0x40 |
ULONG LowestBottomUpVadBit; |
1803 to 1809 | previously at 0x14 and 0x1C |
ULONG_PTR LowestBottomUpVadBit; |
1903 and higher |
The BitMapHint (as VadBitMapHint), LastAllocationSize, LastAllocationSizeHint, LowestBottomUpVadBit and LowestBottomUpAllocationAddress all have previous life as MI_USER_VA_INFO members.
Version 1803 brought into each MI_VAD_ALLOCATION_CELL what had been the one HighestTopDownAllocationAddress in the MI_USER_VA_INFO. It is here supposed that the name and type would naturally have come too. Although the MI_USER_VA_INFO never had a HighestTopDownVadBit, this name is obvious as a partner for LowestBottomUpVadBit and is proposed above while Microsoft’s name for it is unknown.