LOADER_PARAMETER_EXTENSION

The LOADER_PARAMETER_EXTENSION structure is part of the mechanism through which the kernel and HAL learn the initialisation data that was gathered by the loader. It exists only as data that is pointed to from the LOADER_PARAMETER_BLOCK whose address the loader passes to the kernel for the latter’s initialisation.

Variability

The architectural point to having two structures is that the LOADER_PARAMETER_BLOCK should be relatively stable across Windows versions, which indeed it was before Windows 7, but the LOADER_PARAMETER_EXTENSION can vary significantly and often has.

This is not just theoretical. Before version 6.0, the LOADER_PARAMETER_BLOCK really did need to be stable enough that the one NTLDR in the root directory of the bootable partition might load a kernel from a different Windows version, certainly any earlier version if not also any later one. Variability between versions was more for things that the LOADER_PARAMETER_BLOCK points to from its stable offsets. The LOADER_PARAMETER_EXTENSION is one such thing. It may have been a far-sighted allowance or a way to overcome having allowed too little. The version 4.0 LOADER_PARAMETER_BLOCK is known to have defined a Spare1, and earlier versions perhaps had a Spare or Spare0. An expansion of the LOADER_PARAMETER_BLOCK for Windows NT 4.0 SP3 caused compatibility problems with new kernels assuming new information that an old NTLDR did not know to provide. The goal that one NTLDR could load a kernel from a future Windows version was broken. If problems of this sort were not to recur, it may have seemed better that all future variability in what’s pointed to from the LOADER_PARAMETER_BLOCK be wrapped into one LOADER_PARAMETER_EXTENSION. Or so goes my current best attempt at inferring a history. The first loader that is known to create a LOADER_PARAMETER_EXTENSION is from Windows 2000.

Compatibility considerations changed with Windows Vista. It split NTLDR in two. A boot manager, e.g., BOOTMGR, enumerates the installed Windows versions and chooses which to boot. The remaining work is done by a boot loader, e.g., WINLOAD, within the chosen Windows installation. The boot loader should always match the kernel of whatever Windows is being booted. Since it is the boot loader that prepares the LOADER_PARAMETER_BLOCK, considerations for backwards compatibility (in Windows Vista and higher) have essentially disappeared. Subsequent changes are not just from growth at the end: members are removed, changed and inserted without regard for continuity. Especially notable among the changes is that Windows 7 does away with the MajorVersion and MinorVersion—or, if you prefer, moves them to the LOADER_PARAMETER_BLOCK. Within the LOADER_PARAMETER_EXTENSION, all that remains for identifying which version did the preparation is the Size at the start.

It cannot be stressed enough that the LOADER_PARAMETER_EXTENSION, however vital as shared data between the loader, kernel and HAL, is highly variable. Though early versions (before 6.1) change organically, i.e., by adding only to the end so that the Size at the start differentiates the layouts, they change even between builds. The structure is greatly expanded in later versions and successive releases of Windows 10 vary the structure more than ever before, including to insert and delete:

Beware that changes within version 5.1 date to Windows XP Service Pack 1. On numerous other pages at this website, the abbreviation “late 5.1” means version 5.1 starting with Windows XP SP2. This is because many advances and fixes that came with the introduction of the amd64 architecture for the version 5.2 from Windows Server 2003 SP1 found their way into the roughly contemporaneous Windows XP SP2. But none of this affected the LOADER_PARAMETER_EXTENSION: its changes for version 5.1 had already happened.

Documentation Status

Microsoft is not known ever to have documented the LOADER_PARAMETER_EXTENSION.

For many years, Microsoft’s names for the LOADER_PARAMETER_EXTENSION and the definitions of its members were known from type information in public symbol files for the kernel (and sometimes also the HAL), though only for occasional Windows versions: first for Windows 2000 SP3 and SP4, and then for all releases of Windows Vista and Windows 7. How the type information gets into the public symbols for some versions but not others is not known.

Windows 10 brought something new. For the original Windows 10 and its 1511 revision, the Windows Driver Kit (WDK) supplies a header file named arc.h which contains a C-language definition of the LOADER_PARAMETER_EXTENSION. This appears to be Microsoft’s first formal disclosure of the structure’s layout. It comes with no conditional compilation blocks for accommodating earlier versions. As supplied, it is immediately useful only for programming that targets a specific release of Windows 10, yet doesn’t say so. Add that the header is beneath a subdirectory named “um”, presumably to mean user-mode, but that the LOADER_PARAMETER_EXTENSION is long gone by the time any user-mode software gets to execute, and one might wonder if this structure’s definition was published by mistake.

Still, published it is. Then, just as that seemed to be the end of disclosure, perhaps forever, Microsoft’s names and types returned to the public symbol files for the kernel in the 1803 release of Windows 10.

Though this apparently continuing provision of type information in symbol files is welcome, it still leaves the historian with some difficulty for versions 5.1 and 5.2, and then for 6.2 and 6.3, and then again for the 1607 to 1709 releases of version 10.0. It turns out that type information is published for these too—well, for most of them—but a little obscurely, being in a statically linked library instead of in symbol files. The library is named CLFSMGMT.LIB. Microsoft distributes it with the Software Development Kit (SDK) for user-mode programming. It has type information for the LOADER_PARAMETER_EXTENSION in 32-bit versions starting with Windows Vista and 64-bit starting with Windows 8. For no reason yet known, this type information is gone from this library in the SDK for Version 2004.

Layout

The following table of offsets, names, types for the LOADER_PARAMETER_EXTENSION is from the published C-language definition in ARC.H for the original and 1511 releases of Windows 10. For other versions, the layout is from type information in public symbols and libraries, if available, as described above. Names, types and offsets for all other versions are something of a guess from assuming continuity except where inspection of the loader or kernel shows that members have come or gone.

ULONG Size;

PROFILE_PARAMETER_BLOCK Profile;

ULONG MajorVersion;

ULONG MinorVersion;

PVOID EmInfFileImage;

ULONG EmInfFileSize;

PVOID TriageDumpBlock;

Appended for Windows XP

ULONG_PTR LoaderPagesSpanned;

HEADLESS_LOADER_BLOCK *HeadlessLoaderBlock;

SMBIOS_TABLE_HEADER *SMBiosEPSHeader;

SMBIOS3_TABLE_HEADER *SMBiosEPSHeader;

PVOID DrvDBImage;

ULONG DrvDBSize;

PVOID DrvDBPatchImage;

ULONG DrvDBPatchSize;

NETWORK_LOADER_BLOCK *NetworkLoaderBlock;

Appended for Windows Server 2003

PUCHAR HalpIRQLToTPR;

PUCHAR HalpVectorToIRQL;

LIST_ENTRY FirmwareDescriptorListHead;

PVOID AcpiTable;

ULONG AcpiTableSize;

Appended for Windows Vista

struct {
    /*  changing bit fields, see below  */
};

LOADER_PERFORMANCE_DATA *LoaderPerformanceData;

LOADER_PERFORMANCE_DATA LoaderPerformanceData;

LIST_ENTRY BootApplicationPersistentData;

PVOID WmdTestResult;

GUID BootIdentifier;

Appended for Windows 7

ULONG ResumePages;

PVOID DumpHeader;

PVOID BgContext;

PVOID NumaLocalityInfo;

PVOID NumaGroupAssignment;

LIST_ENTRY AttachedHives;

ULONG MemoryCachingRequirementsCount;

PVOID MemoryCachingRequirements;

TPM_BOOT_ENTROPY_LDR_RESULT TpmBootEntropyResult;

BOOT_ENTROPY_LDR_RESULT BootEntropyResult;

ULONGLONG ProcessorCounterFrequency;

Appended for Windows 8

LOADER_PARAMETER_HYPERVISOR_EXTENSION HypervisorExtension;

GUID HardwareConfigurationId;

LIST_ENTRY HalExtensionModuleList;

LARGE_INTEGER SystemTime;

ULONGLONG TimeStampAtSystemTimeRead;

ULONGLONG BootFlags;

union {
    ULONGLONG BootFlags;
    struct {
        /*  changing bit fields, follow link  */
    };
};

ULONGLONG InternalBootFlags;

union {
    ULONGLONG InternalBootFlags;
    struct {
        /*  bit fields, follow link  */
    };
};

PVOID WfsFPData;

ULONG WfsFPDataSize;

LOADER_PARAMETER_KD_EXTENSION KdExtension;

LOADER_BUGCHECK_PARAMETERS BugcheckParameters;

PVOID ApiSetSchema;

ULONG ApiSetSchemaSize;

LIST_ENTRY ApiSetSchemaExtensions;

UNICODE_STRING AcpiBiosVersion;

UNICODE_STRING SmbiosVersion;

UNICODE_STRING EfiVersion;

Appended for Windows 8.1

DEBUG_DEVICE_DESCRIPTOR *KdDebugDevice;

OFFLINE_CRASHDUMP_CONFIGURATION_TABLE OfflineCrashdumpConfigurationTable;

Appended for Windows 10

UNICODE_STRING ManufacturingProfile;

PVOID BbtBuffer;

ULONG64 XsaveAllowedFeatures;

ULONG XsaveFlags;

PVOID BootOptions;

ULONG IumEnablement;

ULONG IumPolicy;

NTSTATUS IumStatus;

ULONG BootId;

LOADER_PARAMETER_CI_EXTENSION *CodeIntegrityData;

ULONG CodeIntegrityDataSize;

Appended for Version 1511

LOADER_HIVE_RECOVER_INFO SystemHiveRecoveryInfo;

Appended for Version 1607

ULONG SoftRestartCount;

LONGLONG SoftRestartTime;

PVOID HypercallCodeVa;

PVOID HalVirtualAddress;

ULONGLONG HalNumberOfBytes;

LEAP_SECOND_DATA *LeapSecondData;

ULONG MajorRelease;

ULONG Reserved1;

The MajorRelease is an NTDDI version number as defined in the SDKDDKVER.H header. It adds to the kernel’s validation of the LOADER_PARAMETER_EXTENSION for the LOADER_BLOCK_MISMATCH bugcheck. Do not miss the irony that the version numbering that was removed for Windows 7 is brought back, with elaboration, now that Windows 10 makes the extension more variable than ever before.

Appended for Version 1703

CHAR NtBuildLab [0xE0];

CHAR NtBuildLabEx [0xE0];

LOADER_RESET_REASON ResetReason;

Appended for Version 1803

ULONG MaxPciBusNumber;

Appended for Version 1809

ULONG FeatureSettings;

Appended for Version 1903

ULONG HotPatchReserveSize;

ULONG RetpolineReserveSize;

struct {
    PVOID CodeBase;
    ULONGLONG CodeSize;
} MiniExecutive;

VSM_PERFORMANCE_DATA VsmPerformanceData;

Appended for Version 2004

NUMA_MEMORY_RANGE *NumaMemoryRanges;

ULONG NumaMemoryRangeCount;

ULONG IommuFaultPolicy;

Bit Fields

Version 6.0 introduced a single bit-wide flag, then at offsets 0x58 and 0x84, apparently within an anonymous structure. A likely anticipation is that there would soon be more, which indeed there were:

ULONG BootViaWinload : 1;

ULONG LastBootSucceeded : 1;

ULONG LastBootShutdown : 1;

ULONG IoPortAccessSupported : 1;

ULONG BootDebuggerActive : 1;

ULONG StrongCodeGuarantees : 1;

ULONG HardStrongCodeGuarantees : 1;

ULONG SidSharingDisabled : 1;

ULONG TpmInitialized : 1;

ULONG VsmConfigured : 1;

ULONG IumEnabled : 1;

ULONG IsSmbboot : 1;

ULONG BootLogEnabled : 1;

ULONG DriverVerifierEnabled : 1;

ULONG SuppressMonitorX : 1;

ULONG KernelCetEnabled : 1;

ULONG SuppressSmap : 1;

ULONG FeatureSettings : 7;

ULONG Unused : 8;

ULONG Unused : 7;

ULONG Unused : 5;

ULONG FeatureSimulations : 6;

ULONG MicrocodeOptedOut : 1;

ULONG MicrocodeSelfHosting : 1;

ULONG XhciLegacyHandoffSkip : 1;

ULONG DisableInsiderOptInHVCI : 1;

ULONG MicrocodeMinVerSupported : 1;

ULONG GpuIommuEnabled : 1;

ULONG Reserved : 31;

ULONG Reserved : 29;

ULONG Reserved : 28;

ULONG Reserved : 25;

ULONG Reserved : 22;

ULONG Reserved : 21;

ULONG Reserved : 20;

ULONG Reserved : 5;