TYPE_OF_MEMORY

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.

Availability

The TYPE_OF_MEMORY is ancient, being already well established for Windows NT 3.1.

Documentation Status

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.

Values

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.

Value Name Versions
0x00000000 LoaderExceptionBlock all
0x00000001 LoaderSystemBlock all
0x00000002 LoaderFree all
0x00000003 LoaderBad all
0x00000004 LoaderLoadedProgram all
0x00000005 LoaderFirmwareTemporary all
0x00000006 LoaderFirmwarePermanent all
0x00000007 LoaderOsloaderHeap all
0x00000008 LoaderOsloaderStack all
0x00000009 LoaderSystemCode all
0x0000000A LoaderHalCode all
0x0000000B LoaderBootDriver all
0x0000000C LoaderConsoleInDriver all
0x0000000D LoaderConsoleOutDriver all
0x0000000E LoaderStartupDpcStack all
0x0000000F LoaderStartupKernelStack all
0x00000010 LoaderStartupPanicStack all
0x00000011 LoaderStartupPcrPage all
0x00000012 LoaderStartupPdrPage all
0x00000013 LoaderRegistryData all
0x00000014 LoaderMemoryData all
0x00000015 LoaderNlsData all
0x00000016 LoaderSpecialMemory all
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
0x0000001C (6.0);
0x0000001D (6.1 to 6.3);
0x00000021 (10.0);
0x00000022 (1511);
0x00000023 (1607);
0x00000024 (1703 to 1803);
0x00000025 (1809);
0x00000029
LoaderMaximum  

While LoaderMaximum looks to be just a programming convenience that leaves no trace in the code, which version first defines it is not known.