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 EX_X.H header at
and draws from it the following type definitions:
||16519||WDM.H loses 12
NTOSP.H loses 2
|997||struct _LOOKASIDE_LIST_EX||22401||17204||WDM.H loses 110
NTOSP.H loses 53
|2582||struct _WORK_QUEUE_ITEM||22989||18773||WDM.H loses 997
NTOSP.H loses 16
|2946||struct _OWNER_ENTRY||23058||19129||WDM.H loses 295
NTOSP.H loses 8
|3502||struct _EX_PUSH_LOCK||19630||100||NTOSP.H loses 55|
|3654||struct _EX_RUNDOWN_REF||23460||19780||NTOSP.H loses 2|
|4020||struct _EXT_DELETE_PARAMETERS||23583||20137||NTOSP.H loses 9|
The header EX_X.H is not known in any Device Driver Kit (DDK) or Windows Driver Kit (WDK).
That said, all the types that the kernel is known to pick up from EX_X.H are defined in the standard header WDM.H for kernel-mode programming or in other aggregated headers, NTOSIFS.H and NTOSP.H, that Microsoft has mostly kept for its own projects but which are available from inspection because of the disclosure in the “minwin” directory of the Windows 10 WDK for the original release and for Version 1511.
Most of the types are extracted to both the widely available WDM.H and the private NTOSP.H, but both miss at least some lines and WDM.H consistently misses more. Some accounting is possible on the assumption that although each of these headers receives only a selection of lines from EX_X.H, their selections are contiguous. Put another way, assume that WDM.H lines 21560 to 23583 and NTOSP.H lines 16296 to 20137 are generated only as extractions from EX_X.H. Then some of the EX_X.H material that goes to NTOSP.H but not to WDM.H goes to NTDDK.H or NTIFS.H instead, but most is otherwise unknown in the WDK headers.