CMDATA.H

The public symbol file NTKRPAMP.PDB for the original release of Windows 10 tells that the kernel is built with the CMDATA.H header at

d:\th\minkernel\ntos\inc

and draws from it the following type definitions:

Line Number	Type
57	struct _CM_KEY_HASH
64	struct _CM_NAME_HASH
71	struct _CM_KEY_HASH_TABLE_ENTRY
240	struct _CM_NAME_CONTROL_BLOCK
255	struct _CM_INDEX_HINT_BLOCK
261	struct _CACHED_CHILD_LIST
306	struct _CHILD_LIST
315	struct _CM_KEY_REFERENCE
353	struct _CM_INDEX
367	struct _CM_KEY_INDEX
470	struct _CM_KEY_NODE
537	struct _CM_KEY_VALUE
565	struct _CM_BIG_DATA
579	struct _CM_KEY_SECURITY
593	struct _CM_KEY_SECURITY_CACHE
602	struct _CM_KEY_SECURITY_CACHE_ENTRY
618	struct _CELL_DATA
619	union _u
682	struct _CM_CACHED_VALUE_INDEX
684	unnamed union Data in _CM_CACHED_VALUE_INDEX
719	struct _CM_INTENT_LOCK
793	struct _CM_KEY_CONTROL_BLOCK

The header CMDATA.H is not known in any Device Driver Kit (DDK) or Windows Driver Kit (WDK).

Incidentally, although the public debugging support for the kernel hasn’t disclosed full pathnames of source files (in contrast to object files) since Windows NT 4.0, the public symbol files do show that the source files are written in C. An easy example comes from _CELL_DATA and _u. Type information for these implies the nesting

typedef struct _CELL_DATA {
    union _u {
        /*  members omitted  */
    } u;
} CELL_DATA;

but the decorated name of _u is not .?AT_u@_CELL_DATA@@, as would model the scoping rules of C++, but is instead .?AT_u@@, as from compiling C.