Geoff Chappell - Software Analyst
The TYPE_OF_MEMORY enumeration (formally _TYPE_OF_MEMORY) distinguishes different blocks of physical memory that the kernel learns about from the loader and then puts to use, including to break them into smaller blocks or to disregard them. Each memory block is described by a MEMORY_ALLOCATION_DESCRIPTOR. The TYPE_OF_MEMORY is thought to have no lasting meaning except as this descriptor’s member that’s named MemoryType.
The TYPE_OF_MEMORY is ancient, being already well established for Windows NT 3.1.
Microsoft is not known ever to have documented the TYPE_OF_MEMORY. For many years, it was known from Microsoft only through type information in public symbol files for the kernel. Even this started only as recently as Windows Vista. After roughly another decade, Microsoft published a C-language definition. This is in a header named ARC.H which Microsoft distributed with the Windows Driver Kit (WDK) for Windows 10 in its original and Version 1511 editions. This disclosure was very likely a mistake. The header is in a subdirectory, named “minwin”, of a directory named “um” as if for user-mode programming even though many of the headers in the subdirectory define types that no user-mode software has any access to. Oversight or not, the header was gone from the WDK for Version 1607.
Where a memory block comes from and what use it has yet been put to has ever more possibilities in ever later versions. Microsoft’s names are known from public symbol files for the kernel, starting with Windows Vista. What’s known for earlier versions comes from inspecting the binaries for continuity with the later versions. Nearly two dozen types look to be ancient: the kernel in version 3.50 (only) has plain-text descriptions which all match the names that are known from later symbol files.
|0x00000017||LoaderBBTMemory||5.0 and higher|
|0x00000018||LoaderReserve||5.0 to 6.3|
|LoaderZero||10.0 and higher|
|0x00000019||LoaderXIPRom||5.1 and higher|
|0x0000001A||LoaderHALCachedMemory||5.1 and higher|
|0x0000001B||LoaderLargePageFiller||5.1 and higher|
|0x0000001C||LoaderErrorLogMemory||6.1 and higher|
|0x0000001D||LoaderVsmMemory||10.0 and higher|
|0x0000001E||LoaderFirmwareCode||10.0 and higher|
|0x0000001F||LoaderFirmwareData||10.0 and higher|
|0x00000020||LoaderFirmwareReserved||10.0 and higher|
|0x00000021||LoaderEnclaveMemory||1511 and higher|
|0x00000022||LoaderFirmwareKsr||1607 and higher|
|0x00000023||LoaderEnclaveKsr||1703 and higher|
|0x00000024||LoaderSkMemory||1809 and higher|
|0x00000025||LoaderSkFirmwareReserved||1903 and higher|
|0x00000026||LoaderIoSpaceMemoryZeroed||1903 and higher|
|0x00000027||LoaderIoSpaceMemoryFree||1903 and higher|
|0x00000028||LoaderIoSpaceMemoryKsr||1903 and higher|
0x0000001D (6.1 to 6.3);
0x00000024 (1703 to 1803);
While LoaderMaximum looks to be just a programming convenience that leaves no trace in the code, which version first defines it is not known.