The public symbol file NTKRPAMP.PDB for the original release of Windows 10 says nothing of any header named DBGK.H, yet one certainly does exist and surely is included by source files that contribute to the kernel’s binary code. Whether it’s included by the separate source file ntsym.c whose compilation merges type information into the public symbols is not known, but if it is included it’s to no effect. Indeed, no type information attributed to DBGK.H shows in any of the symbol files from the downloadable package of public symbols for the original Windows 10.

Type information from a DBGK.H for Windows 10 shows instead in a statically linked library named CLFSMGMT.LIB which Microsoft publishes with the Software Development Kit (SDK). This library archives an object file that was produced as a side-effect of creating a pre-compiled header. it plausibly is a complete record of user-defined types in DBGK.H because much of the point to a pre-compiled header is that it carries the definitions of all types that might be used in any other compilation (with the same options and macro definitions). Where this library got its DBGK.H from is


Names and line numbers of user-defined types from this header are tablulated below. There are only two, not counting an anonymous sub-type. One has its definition duplicated into two headers that Microsoft published with the Windows Driver Kit (WDK) for Windows 10 in the original and Version 1511 editions only. The line numbers on the left are deduced from type information in the library. Those on the right are from the (accidentally) published headers.

Line Number Name NTOSIFS.H NTOSP.H
37 struct _DEBUG_OBJECT    
256 union DBGK_LIVEDUMP_FLAGS 3167 53250
257 anonymous struct in
3168 53251

In case it’s not clear, let it be stressed that no header named DBGK.H is known from any WDK for any Windows version or, earlier, from any Device Driver Kit (DDK). For some measure of its obscurity, consider that asking Google today, 7th February 2023, for what’s known on the Internet about “DBGK_LIVEDUMP_FLAGS” gets that the search “did not match any documents.”

The DEBUG_OBJECT is less obscure, but apparently only for dating from long enough ago that it (and the header, by the way) are known to many “reverse engineers” from source code that Microsoft distributed as the Windows Research Kernel (WRK) under conditions that can’t reasonably be counted as publication. As the kernel-mode structure that is the debug object such as can be created from user mode through the NtCreateDebugObject function, the DEBUG_OBJECT is not without importance.