LOADER_PARAMETER_BLOCK

The LOADER_PARAMETER_BLOCK (formally _LOADER_PARAMETER_BLOCK) is the structure through which the kernel and HAL learn the initialisation data that was gathered by the loader.

Historically, and for most practical purposes even in recent Windows versions, there is only ever the one instance of this structure. It is prepared by the loader as its means of handing over to the kernel. When the loader calls the kernel’s initialisation routine, the address of the loader block is the one argument. The kernel saves the address for a while in the exported variable KeLoaderBlock. At the end of the kernel’s initialisation, the structure gets freed and the variable gets cleared. During the system’s initialisation, however, knowledge of this structure can be very helpful when debugging.

Availability

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

Documentation Status

Microsoft is not known ever to have documented the LOADER_PARAMETER_BLOCK.

For many years, Microsoft’s names for the LOADER_PARAMETER_BLOCK members were known from type information in public symbol files for the kernel (and sometimes also the HAL) but 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.

Then 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_BLOCK. 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_BLOCK 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.

Archaeology

At the other end of the timeline, type information for the LOADER_PARAMETER_BLOCK turns out to have been published by Microsoft even for version 4.0, just not in symbol files but instead in statically linked libraries. One is LIBCNTPR.LIB from the Device Driver Kit (DDK) for Windows NT 4.0. For no reason that is yet understood, this library’s archive of tidtable.obj has unusually much type information (42KB, against 8KB for the next most), including for such otherwise obscure types as the LOADER_PARAMETER_BLOCK. Though this type information predates the kernel for the original Windows NT 4.0 (12th July 1996 versus 5th October), it agrees with the structure’s use as known from inspection of the binary code.

Arguably more interesting is a library that Microsoft supplied with source code for the Dr. Watson sample in a Platform Software Development Kit (SDK) from January 1998. This library is named craShlib.Lib—yes, with this mixture of upper and lower case—and was built on 12th September 1997. Its archived object files have type information for each of the processor architectures that Microsoft supported at the time. Type information for the x86 LOADER_PARAMETER_BLOCK is from 24th August 1997. This is months later than the build date for the Windows NT 4.0 SP3 kernel (11th May 1997) but more than a year earlier than SP4 (13th October 1998). From inspection of these kernels, it looks like type information from this library can be taken as reliable for Windows NT 4.0 SP3. Presumably, this library was distributed with some range of SDK editions, perhaps with type information to find for more versions.

With the archaeology broadened to type information in statically linked libraries as far afield as the SDK—which, remember, is for user-mode programming and thus nothing that anyone would ordinarily think relevant to a structure that isn’t present even for most kernel-mode execution—it turns out that type information for the LOADER_PARAMETER_BLOCK was pubilshed in CLFSMGMT.LIB for all 32-bit versions since Windows Vista and all 64-bit versions since Windows 8. For no reason yet known, this type information is gone from this library in the SDK for Version 2004.

Variability

Perhaps because the LOADER_PARAMETER_BLOCK is accessible through an exported variable and is vital as shared data between the loader, kernel and HAL, it was highly stable for many Windows versions, certainly in comparison with other undocumented structures. Version 6.0, however, reworked the loading of Windows, and then each change even of the minor version number brings a change of size:

Some of these changes in size overstate the variability. As far as concerns the structure’s own members, the growth within version 4.0 and again from 6.2 to 6.3 involves no additions, removals or rearrangements, just growth within the member that was at the time the structure’s last. Version 6.0 brought a straightforward appending of one member. The change for Version 1803 is similar but of three members. Such growth only at the end allows for backwards compatibility. A new loader can prepare the structure in its new layout but safely pass it to an old kernel. This was indeed depended on for multi-boot configurations in the days when the one NTLDR in the root directory of the bootable partition might load the kernel of any earlier Windows version (if not of a later one).

Version 6.0 separated the booting of Windows into a boot manager, e.g., BOOTMGR, and a boot loader, e.g., WINLOAD. The boot manager selects which of the installed Windows versions (or different configurations) to proceed with. Each Windows version provides its own boot loader. This, not the boot manager, is what prepares the LOADER_PARAMETER_BLOCK and it only has to do so for the matching kernel. Backwards compatibility is no longer an issue for the structure. Changes for versions 6.1, 6.2 and 10.0 are not just from growing at the end: members are inserted and removed without regard for continuity. Notably, version 6.1 inserted version numbers and a size at the structure’s very start, surely to provide some easy and reliable means for future kernels to validate that the structure received from the loader is plausibly what that kernel expects. This defence was apparently thought important enough to warrant its own bug-check, LOADER_BLOCK_MISMATCH (0x0100).

Layout

The following table of offsets, names, types for the LOADER_PARAMETER_BLOCK is from the published C-language definition in ARC.H for the original and 1511 releases of Windows 10. For these and other versions, the layout is confirmed or augmented 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 and gone.

ULONG OsMajorVersion;

ULONG OsMinorVersion;

ULONG Size;

ULONG Reserved;

ULONG OsLoaderSecurityVersion;

LIST_ENTRY LoadOrderListHead;

LIST_ENTRY MemoryDescriptorListHead;

LIST_ENTRY BootDriverListHead;

LIST_ENTRY EarlyLaunchListHead;

LIST_ENTRY CoreDriverListHead;

LIST_ENTRY CoreExtensionsDriverListHead;

LIST_ENTRY TpmCoreDriverListHead;

ULONG_PTR KernelStack;

ULONG_PTR Prcb;

ULONG_PTR Process;

ULONG_PTR Thread;

ULONG KernelStackSize;

ULONG RegistryLength;

PVOID RegistryBase;

CONFIGURATION_COMPONENT_DATA *ConfigurationRoot;

PSTR ArcBootDeviceName;

PSTR ArcHalDeviceName;

PSTR NtBootPathName;

PSTR NtHalPathName;

PSTR LoadOptions;

NLS_DATA_BLOCK *NlsData;

ARC_DISK_INFORMATION *ArcDiskInformation;

PVOID OemFontFile;

SETUP_LOADER_BLOCK *SetupLoaderBlock;

ULONG Spare1;

LOADER_PARAMETER_EXTENSION *Extension;

union {
    /*  changing members, see below  */
} u;

FIRMWARE_INFORMATION_LOADER_BLOCK FirmwareInformation;

PSTR OsBootstatPathName;

PSTR ArcOSDataDeviceName;

PSTR ArcWindowsSysPartName;

The only OsLoaderSecurityVersion that is yet known is 1. The briefly published ARC.H shows that Microsoft defines this symbolically as OSLOADER_SECURITY_VERSION_CURRENT.

The name Spare1, known with certainty from type information for version 4.0, invites the question of whether there was a Spare0 or Spare2. The latter looks impossible: it surely would follow Spare1, not precede it, but all eight bytes that follow in version 4.0 have the same use all the way back to version 3.10. If a Spare0 ever was defined, it may have been in the space that is later given to SetupLoaderBlock. This certainly is defined for version 4.0, but unlike for all other members no use is yet known of it in version 3.10 (by NTLDR, SETUPLDR or the kernel).

The three new members for the 1803 release elaborate the ancient ArcBootDeviceName and ArcHalDeviceName members, now adding ARC paths for the Boot Status Data (BSD) log and for whatever devices are given by the osdatadevice and windowssyspart boot options.

Processor-Specific Loader Blocks

The u union is of small structures for each of the different processor architectures that were supported at the time. This support was wider in the early versions, but which processors had explicit support in this union—or even if it was originally a union—cannot be known from any inspection of only the x86 and x64 binaries, and is therefore left alone for these notes. It is even a guess that there must always have been an I386 member. Other members are known with certainty only for the incomplete range of versions for which type information is available:

I386_LOADER_BLOCK I386;

MIPS_LOADER_BLOCK Mips;

ALPHA_LOADER_BLOCK Alpha;

PPC_LOADER_BLOCK Ppc;

ARM_LOADER_BLOCK Arm;

IA64_LOADER_BLOCK Ia64;