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 I386_X.H header at
and draws from it the type definitions that are tabulated below.
The header I386_X.H is not known in any Device Driver Kit (DDK) or Windows Driver Kit (WDK), but all except one of the types that the kernel is known to pick up from I386_X.H are defined in the NTOSP.H which is in the “minwin” subdirectory of the Windows 10 WDK for the original release and for Version 1511. One is defined in the standard header NTDDK.H. The line numbers on the left are from the unseen I386_X.H but are known from the symbol file. Those on the right are from NTDDK.H and NTOSP.H that are readily available in the WDK for Windows 10.
|612||unnamed union for HighWord in _KGDTENTRY||2254|
|613||unnamed struct for Bytes in HighWord in _KGDTENTRY||2255|
|619||unnamed struct for Bits in HighWord in _KGDTENTRY||2261|
To go by the line numbers, the several hundred lines from _HARDWARE_PTE to _KPRCB look to be copied exactly from I386_X.H to NTOSP.H. The _KPRCB definition in NTOSP.H, however, is not the full definition. It ends after what a comment describes as the “architecturally defined section of the PRCB.” Presumably, the comment is in I386_X.H too, but is there followed by an “end_ntosp” comment that ends the extraction to NTOSP.H, and then by something like five hundred lines of non-architectural _KPRCB members and a “begin_ntosp” comment to resume the extraction, at least to close the definition.
The smaller _KPCR structure is similarly affected, though without an explanatory comment. Some of the roughly twenty lines, mostly if not entirely for _KPCR members, that are not get extracted to NTOSP.H turn up in NTDDK.H. This is a rare case in which the public NTDDK.H has more of a definition than does the private NTOSP.H. Neither of these headers, however, has the full definition from I386_X.H which is knowable from type information in public symbol files for the kernel.