Geoff Chappell, Software Analyst
The public symbol file NTKRPAMP.PDB for the original release of Windows 10 tells that the kernel is built with the NTI386_X.H header at
and draws from it the type definitions that are tabulated below. The header NTI386_X.H is not known in any Device Driver Kit (DDK) or Windows Driver Kit (WDK), but all the types that the kernel is known to pick up from it are defined in the standard header NTDDK.H. The line numbers on the left are from the unseen NTI386_X.H but are known from the symbol file. Those on the right are from the NTDDK.H that is readily available in the WDK for Windows 10.
It is not known whether NTI386_X.H is the source of the definitions in NTDDK.H or whether both are constructed from some script or master header. The difference seems unlikely to matter in practice and it’s convenient to speak of NTI386_X.H as the master from which content is extracted to the standard headers. WDM.H, NTDDK.H and some others each have a contiguous set of lines that can with good confidence be identified as having been extracted in broken sequences from NTI386_X.H:
The immediately preceding lines in WDM.H are similarly from NTKEAPI_X.H. For NTDDK.H, NTI386_X.H is the first known input. NTI386_X.H is, of course, specific to the i386 processor architecture. Its contributions to both WDM.H and NTDDK.H are followed in turn by extracts from NTAMD64_X.H, NTARM_X.H and presumably an NTARM64_X.H. For who knows what reason, the order is different in MINIPORT.H and WINNT.H, which have their extractions from NTI386_X.H last.
The arm and arm64 architectures are ordinarily irrelevant to this study, but it happens that Microsoft has published NTARM_X.H. It is in the WDK for Windows 10 from the original release up to and including the 1803 edition, but apparently not since. It’s in the “um” subdirectory for user-mode programming and is included from only one other header, named NTARM.H, which is in turn not included from any other. Still, published it is.
Though the public symbol files for the kernel make no mention of it, there is an NTI386.H in the same directory. This is known from private symbol files that Microsoft has distributed in packages of otherwise public symbol files. All these private symbols are for user-mode modules. Some, such as URLMON.DLL from Internet Explorer, are very far removed from kernel-mode programming, but let’s leave that wonder for some other time. If NTI386.H for the i386 processor architecture follows the pattern of NTARM.H and NTARM_X.H, then NTI386.H includes NTI386_X.H. It’s not impossible, and may even be likely, that the kernel’s source code includes NTI386.H but just doesn’t use any of its contents in a way that survives into the public symbol files.