Geoff Chappell - Software Analyst
The LOADER_BLOCK_MISMATCH bug check reports that the loader and kernel disagree about their combination.
| Bug Check Code | LOADER_BLOCK_MISMATCH |
| 1st Argument | major version of loader parameter block |
| 2nd Argument | minor version of loader parameter block |
| 3rd Argument | size of loader parameter block |
| 4th Argument | size of loader parameter extension; else zero |
A LOADER_PARAMETER_BLOCK is received from the loader as the kernel’s one argument for initialisation, and contains a pointer to a separate LOADER_PARAMETER_EXTENSION. Both structures are clearly vital but both vary between Windows versions. This bug check means that at least one of the structures does not fit the kernel’s expectations. Probably, the loader and kernel are from different Windows versions or even from different builds. The point to this bug check is much reduced, however, since the kernel does not try to validate the loader until it gets round to initialising the Executive’s understanding of the boot processor. If the structures truly are mismatched, surely disaster will have struck long before.
This bug check is supported by making a significant change to the previous layout of the LOADER_PARAMETER_BLOCK. Version 6.1 introduces OsMajorVersion, OsMinorVersion and Size members at the beginning, and later versions keep them. Earlier versions begin with a LIST_ENTRY, which is extremely unlikely to fit the version numbers and size by accident. The LOADER_PARAMETER_EXTENSION has long begun with its Size (but lost its own MajorVersion and MinorVersion in version 6.1, perhaps from moving them to the loader block). The location of the Extension member that points from the one structure to the other varies with the Windows version.
The OsMajorVersion and OsMinorVersion in the supposed loader block are Windows version numbers. They must agree exactly with the one Windows version that the kernel is built for. The Size must be exactly that of the LOADER_PARAMETER_BLOCK in this Windows version. If the kernel dislikes what it finds at the beginning of the supposed loader block, the 4th argument is zero, it being unsafe even to look for the supposed extension. Conversely, a non-zero 4th argument implies that the block itself has the correct version numbers and size, and the mismatch is with the extension. Before the 1607 release of Windows 10, the extension is checked only for its Size. Later releases also check a new member that has a varying position near to the end of the extension. This MajorRelease is an NTDDI version number such as defined in SDKDDKVER.H, e.g., 0x0A000005 for the 1803 release. It looks to have been introduced because although the different releases of Windows 10 all have 10 and 0 as their major and minor version numbers, the LOADER_PARAMETER_EXTENSION varies as much from one Windows 10 release to the next as it did for successive minor versions in days gone by.
The LOADER_BLOCK_MISMATCH bug check can occur in version 6.1 and higher. It replaces one case that version 6.0 added to the much older MISMATCHED_HAL.
Microsoft’s documentation in the Windows Driver Kit (WDK) for Windows 7, dated June 2009, and in the contemporaneous Debugging Tools for Windows, is completely wrong about the arguments, apparently as a cut-and-paste error from documentation of MISMATCHED_HAL. The parameters are still wrong ten years later, on 25th December 2019, in Microsoft’s online documentation Bug Check 0x0100: LOADER_BLOCK_MISMATCH.