Kernel
Debugger Extensions Specification (Phase 3)
Last Updated: 12/25/99
This document specifies a set of debugger extensions for use with kernel debuggers when debugging Windows NT 4.0 and Windows 2000 systems and crash dumps. The debugger extensions operate similarly to the “standard” kdextx86.dll extensions. Familiarity with Windows NT kernel debugging procedures is assumed herein.
The debugger extensions are packaged as kdex2x86.dll, for x86 debug targets being debugged on x86 hosts. Note that the host can be running either Windows NT 4.0 or Windows 2000, as the host platform is unimportant as long as the debugger runs on it successfully.
All service pack revisions of Windows NT 4.0 are supported, though primary testing will focus on, and therefore correct operation is only guaranteed on, SP3 and above. For Windows 2000, only the golden release is supported; compatibility with future service packs cannot be guaranteed.
Following is the list of extensions to be provided in phase 3.
!apc,!dpc — dump APC/DPC or all APCs/DPCs
!ethread/!kthread — display thread structure
!idt — dump information about IDT and handlers
!ip — dissection and dump of IP packets
!kqueue — display queue of worker thread
!lastlivetime — display system last live time
!list,!singlelist — chain display of LIST_ENTRY and SINGLE_LIST_ENTRY
!s — cool searching capability
!smb — display SMB structure from header
!stack — stack analysis
!strct — cool structure dumping, to contain most structures in ntddk.h
!xpool — prints maps of pool usage
These are described in detail in the sections that follow.
Table of Contents Ý
These extensions dump APC and DPC structures at a given address, or all the APCs and DPCs in the system.
!apc is invoked as follows:
!apc [expression]
expression — optionally supplies the address of a KAPC structure. If not specified, all KAPC structures in the system are dumped.
The output is a nicely formatted !strct-style dump, with named values and bitfields printed out symbolically.
!dpc is invoked as follows:
!dpc [expression]
expression — optionally supplies the address of a KDPC structure or a processor ordinal. If not specified, all KDPC structures in the system (for all processors) are dumped. If this value is specified as a small integer in the range 0 to the number of processors minus 1, then all KDPCs for that processor are dumped.
The output is a nicely formatted !strct-style dump, with named values and bitfields printed out symbolically.
Also see the !apc implementation note and the !dpc implementation note.
Table of Contents Ý
These extensions dump the fields of the undocumented ETHREAD and KTHREAD structures.
!ethread and !kthread are invoked as follows:
!ethread expression
!kthread expression
expression — Supplies the address of an ETHREAD structure (for !ethread) or a KTHREAD structure (for !kthread).
The output is a nicely formatted !strct-style dump, with named values and bitfields printed out symbolically.
Table of Contents Ý
This extension dumps the IDT for a given processor, including the handler for each interrupt. A pointer to the IDT for a processor is located in its PCR.
!idt is invoked as follows:
!idt [processornumber [interruptnumber]]
processornumber — optionally specifies the 0-based processor number. If not specified, the entire IDT for all processors is dumped.
interruptnumber — if processornumber is specified, then a particular interrupt vector (as opposed to the entire table) can be dumped by specifying an additional number (0-based, maximum value is platform-dependent).
The output shows the processor number, the vector number within the table, the address it points to, and a symbolic name for the address if one can be found. A sample (using entirely arbitrary addresses and symbolic names) follows.
IDT
for processor #0
00: 80801000
(hal!_HalClockInterrupt)
01: 00000000
02: 84000100
(ntoskrnl!_UnhandledInterrupt)
Table of Contents Ý
This extension interprets memory as an IP packet and dumps the headers and data contained therein.
!ip is invoked as follows:
!ip address address …
address — Supplies one or more addresses of IP headers in memory.
Only TCP
and UDP packets are interpreted. For other IP packet types, the raw data is
displayed without interpretation.
Table of Contents Ý
This extension dumps the fields of the undocumented KQUEUE structure.
!kqueue is invoked as follows:
!kqueue expression
expression — Supplies the address of a KQUEUE structure.
The output is a nicely formatted !strct-style dump, with named values and bitfields printed out symbolically.
Table of Contents Ý
The !lastlivetime kernel debugger extension displays the last time of system activity, in GMT and the local time in effect on the system being debugged (the local time has nothing to do with the time zone of the system hosting the debugger). The extension takes no parameters.
KDx86>!lastlivetime
Thursday, July 16, 1998, 11:51:45 AM (GMT)
Thursday, July 16, 1998, 2:51:45 AM (Local Time)
Also see the implementation note for this extension.
Table of Contents Ý
These extensions understand the kernel-style (LIST_ENTRY and SINGLE_LIST_ENTRY, respectively) and can dump chains of structures starting from a given node forward (in the case of singly-linked lists) or forward and/or backward (in the case of doubly-linked lists).
Chaining data for each list node (next pointer, and in the !list case, the previous pointer) is presented as a binary dump of 1 or 2 dwords. In the case where a structure definition exists in the !strct database, a !strct-style dump of the actual data in the structure of which the LIST_ENTRY or SINGLE_LIST_ENTRY is a part is provided.
!list and !singlelist are invoked as follows:
![single]list expression [count] [structname[.listnodemembername]]
expression — supplies the address where the LIST_ENTRY or SINGLE_LIST_ENTRY structure is, or where the structure containing the LIST_ENTRY or SINGLE_LIST_ENTRY is. The interpretation depends on whether structname is specified.
count — optionally specifies the maximum number of chained entries to dump. If not specified, the entire list that can be accessed from the given node (forwards and backwards for !list, forwards only for !singlelist) is dumped. For !list, this value can be a negative number, which specifies to dump going backwards through the (doubly-linked) list. Otherwise the list is dumped chaining forward through the list.
structname — optionally specifies a structure name . If the structure is contained in the !strct database, then this structure is used to dump the data and the LIST_ENTRY or SINGLE_LIST_ENTRY is assumed to be a member of this structure with name “ListEntry.” The optional listnodemembername can be used to override this default. If structname is not specified then only the link data (next and previous pointers, as appropriate) in each node is dumped.
Table of Contents Ý
This extension provides expanded search capability. The set of terms to be searched for can include any combination of strings, characters, and hex values (bytes, words, dwords, and 64-bit values). The hex values can include wildcarding for individual nibbles. The search terms can be treated as an ANDed list or an ORed list for maximum flexibility.
!s is invoked as follows:
!s [-o] startaddress [endaddress | l rangelength] term [term [term …]]
-o — if this flag is specified,
then the search terms are considered as an ORed list.
In this case, the extension searches for memory containing any of the terms. If
this flag is not specified, then the terms
list forms a pattern that must exist contiguously in memory for a match to
occur.
startaddress — supplies the start address of the range to be searched, interpreted as a hex number.
endaddress — supplies the end address of the range to be searched. Either an end address or the character L followed by the length of the range to be searched must be specified. If the argument following the start address is not an L character by itself, the extension assumes that the next argument is the end address.
l rangelength — supplies the length of the range to be searched. Either an end address or the character L followed by the length of the range to be searched must be specified. If the L character exists by itself following the start address then the extension assumes that the next argument is the range length.
term — specifies one or more terms. If –o was specified, the extension searches for occurrences of *any* of the terms. If –o was not specified, then the terms are concatenated together to form a search pattern. The syntax for a term is as follows.
character: a single quote, followed by a single character, followed by a single quote (for example, ‘a’). When searching, matching is case-insensitive.
wide character: same as a character, except prefixed by an L (for example, L’a’). When searching, matching is case-insensitive.
string: a double quote, followed by one or more characters, followed by a terminating double quote (for example, “abcd”). When searching, matching is case-insensitive.
wide string: same as a string, except prefixed by an L (for example, L“abcd”). When searching, matching is case-insensitive.
8-bit byte: 2 valid hex digits, for example a9.
16-bit word: 4 valid hex digits, for example 0067.
32-bit dword: 8 valid hex digits, for example abcd1234.
64-bit int: 16 valid hex digits, for example 12345678abcdef00.
Note carefully the specification of scalar terms: the number of digits in the term determines the size of the term. Thus ABCD searches for a 16-bit value; to search for a 32-bit value, 0000ABCD must be specified.
For scalar terms, the ? character can be specified to wildcard one nibble. For example AB?D will match AB0D, AB1D, …, ABFD. Multiple ? can be specified, i.e., ???? matches any 16-bit value, etc.
Due to
certain limitations in the debugger, the semi-colon cannot be specified as a
character or wide character search term (i.e., ‘;’ and L’;’ are illegal). Also,
there is no way to ‘escape’ the terminating single or double quote for
character and string terms (i.e., ‘’’ and L’’’ are illegal character
specifiers, and strings/wide strings cannot contain double quotes).
If matches are located, the memory containing them is dumped byte-wise. Memory is always dumped starting on paragraph boundaries. Also, in some cases a given block of memory may be dumped more than once in certain cases if the search pattern is short.
Table of Contents Ý
This extension dumps Windows NT/Lanman-style network communication blocks, starting at an SMB header and chaining through all the commands associated with it (i.e., ANDX chains). There is no provision for starting at an arbitrary point in the command chain, or dumping out a particular command structure at an arbitrary place in memory. The dump output is similar to that of !strct, consisting of a dump of the NT_SMB_HEADER, followed by an identification of the command, and then a dump of its associated SMB command structure. If there is a chain of commands (i.e., ANDX), the last 2 items are repeated as necessary.
Nested structures are not handled specially and are dumped using a default DWORD-based format. Named values/bitfields are not dumped symbolically. Data in buffers associated with the various structures can be optionally dumped.
!smb is invoked as follows:
!smb [-d] expression
-d — if specified, indicates that data in buffers associated with SMB command structures is to be dumped. The dump occurs as a binary dump of bytes, 16 per line, including the hex values and character values.
expression — supplies the address of an SMB header.
Table of Contents Ý
This extension provides expanded stack tracing capability. It can be useful in situations where the standard debugger stack trace is unable to provide accurate traces. The stack trace algorithm uses a decompile and filter algorithm to establish trust levels that indicate the relative accuracy of the trace.
!stack is invoked as follows.
!stack [-a[0|1] | -0 | -1] [address]
-a — if specified, indicates verbose mode (the default is a stack trace display similar to the standard one provided by the debugger). The optional 0 or 1 numeric argument specifies a filter level. If 0 is specified, all frames are displayed (same as if –a is not specified at all). If 1 is specified, only frames with a non-0 trust level are displayed; the frames in the trace that are felt to be the least reliable are filtered out. Only one of –0, -1, and –a may be specified.
-0 — specifies that all frames should be displayed regardless of trust level (this is the default). Only one of –0, -1, and –a may be specified.
-1 — specifies that frames in the trace that are felt to be the least reliable (trust level 0) are filtered out. Only one of –0, -1, and –a may be specified.
address — optionally supplies the address of a thread (ETHREAD object) whose stack is to be traced. If not specified, the current thread is traced.
Note that the implementation for this extension is highly x86-specific. For platforms other than x86, this extension may not be provided at all or if it is, may simply wrap the standard stack trace routines provided by imagehlp.
Table of Contents Ý
This extension provides the ability to show structure definitions, and to get nicely formatted dumps of instantiated structures and unions.
The set of structures that can be dumped include those defined in ntddk.h. In addition, a mechanism for loading user-defined structures is also provided. The ntddk.h structures plus user-supplied structures together comprise the structure database. When structures in the structure database are dumped using !strct, enumerated types, bit flags, NTSTATUS values, and the like are printed out in symbolic form to help eliminate the need to switch back and forth between the debugger and a listing of NT header files. The ntddk.h portion of the structure database is actually compiled into the relevant extension dll; it is not a separate file. The complete list of supported structures is here.
Note that the names in the structure database are the structure and union tag names, not the names of any types that have been assigned to them via typedefs. In the example
typedef struct _X {
int i;
} X, *PX;
the type name actually stored in the database is _X; X and PX are not in the database. For added convenience, however, !strct will treat a name and its underscore-prefixed variant as equivalent whenever it makes sense to do so.
Syntax for !strct is as follows.
!strct structname [fieldname] [expression]
structname — supplies the name of a structure. If the structure is not found in the database, then a list of structures supported by !strct whose first characters match the value given is printed. If structname is specified as *, then the entire list of structures supported by !strct is printed. In these cases, any specified fieldname and expression are ignored.
fieldname — optionally supplies the name of a field within the structure. If not specified, all fields within the structure are dumped.
expression —optionally supplies the address of a structure whose actual data is to be dumped. If not specified, only the requested offsets (a single field or all fields, depending on whether fieldname is specified) themselves are dumped.
The format of the output when actually dumping structure definitions or structure data (i.e., when structname is found in the database) is described in the next section.
Table of Contents Ý
There are two forms of output, depending on whether a structure definition is being dumped, or the data for a structure is being dumped.
For structure definitions (i.e., no data is actually being dumped), the first line shows the name of the structure or union and its size (what sizeof would return) in decimal. Subsequent lines show the offset of a member in hex, the type of the member, and the name of the member (for arrays of structures with a dimension greater than 1, offsets are not shown). Leading zeros in the offset portion are minimized. The type and name portion is shown using an approximation of C syntax as follows:
· Type modifiers (volatile, const, unaligned) are lost.
· Non-structures are shown as C primitive types; custom scalar types are lost.
· 8-bit values (C primitive type char) are shown as “char” or “byte” for signed and unsigned values, respectively.
· 16-bit values (C primitive type short) are shown as “int16” or “uint16” as appropriate.
· 32-bit values (C primitive types int, long) are shown as “int32” or “uint32” as appropriate.
· 64-bit values (C primitive type _int64) are shown as “int64” or “uint64” as appropriate.
· Real values (C primitive types float and double) are shown as “float” or “double” as appropriate.
· Functions (i.e., in the case of a pointer to a function) are shown as “function.” Type specifications relating to the target routine are lost.
· Bit field members are shown as “bitx-y” where x is the 0-based bit position of the least significant bit of the bit field, and y is the position of the most significant bit.
· Array dimensions are shown for both single and multiple dimension arrays.
· Parentheses are used to differentiate between arrays of pointers (no parens are shown) and pointers to arrays (parens are shown), as in C.
· Compounds are fully supported and displayed correctly (i.e., a 6-element array of pointers to pointers to 4-element arrays of structure FOO).
Nested structures and unions are indented; offsets for these are relative to the outermost structure. A pointer to a structure or union is not considered nested; the pointer’s target struct/union is not displayed. Consider the following example.
typedef
unsigned MY_UINT_TYPE;
typedef
union _FOO {
char CharArray[5];
MY_UINT_TYPE u;
int
(*PointerToFunction[10])(int,int);
}
FOO;
typedef
struct _BAR {
FOO *PointerToFoo;
FOO NestedFoo;
FOO ArrayOf1Foo[1];
FOO ArrayOf10Foo[10];
int OneBitField:1;
int TwoBitField:2;
SHORT
*ArrayOfArrayOfPointersToUshorts[5][10];
__int64 i;
double d;
float f;
}
BAR;
kd>!strct
BAR
struct
_BAR (sizeof=712)
+000
union _FOO *PointerToFoo
+004
union _FOO NestedFoo
+004 char CharArray[5]
+004 uint32 u
+004 function *PointerToFunction[10]
+02c
union _FOO ArrayOf1Foo[1]
+02c char CharArray[5]
+02c uint32 u
+02c function *PointerToFunction[10]
+054
union _FOO ArrayOf10Foo[10]
char CharArray[5]
uint32 u
function *PointerToFunction[10]
+1e4
bits0-0 OneBitField
+1e4
bits1-2 TwoBitField
+1e8
int16 *ArrayOfArrayOfPointersToUshorts[5][10]
+2b0
int64 i
+2b8
double d
+2c0 float f
Note the following:
· The custom scalar type MY_UINT_TYPE resolves down to an unsigned 32-bit value, and so FOO.u is shown as “uint32.”
· Offsets are shown for BAR.ArrayOf1Foo, since an array of one structure is essentially the same as a simple nested structure.
· Offsets are not shown for BAR.ArrayOf10Foo, since any offsets shown would be meaningful only for the 0th element of that array.
· BAR.PointerToFoo is not expanded.
· BAR.OneBitField occupies bit 0 of the int at offset 1e4 of struct _BAR; BAR.TwoBitField occupies bits 1 and 2.
Table of Contents Ý
User-defined structures can be supplied to the extension using structure definition files. A structure definition file is a standard Windows .ini file. One such file can contain an arbitrary number of structure definitions. The specification below builds an example based on the following structure.
struct X {
int i; // plain old int
struct s ss; // nested structure, size = 14 (or 15 or
16, due to packing)
enumE e; // enumerated type
DWORD flags; // bit field
LPCWSTR str[2]; // array of pointers
USHORT array[3]; // array of USHORT values
struct {
int a;
int b;
}; //
anonymous nested structure
struct {
int c;
int d;
} named; // named nested structure
enumF f; // enumerated type
};
The [struct] section lists the structures defined in the file.
;
; Main section, which lists the structures defined in this file.
;
[struct]
X
For each structure named in the [struct] section, there is a section named correspondingly, which defines the structure. The structure is defined by providing, for each member, the member name, offset, data type, and data count. The member name may contain dot characters to indicate nesting for structures that are not defined elsewhere in the structure definition file or for anonymous structures. The data type is a numeric value as follows:
·
0 —
bytes
·
1 —
chars
·
2 —
wide chars
·
3 —
16-bit words
·
4 —
32-bit dwords
·
5 —
64-bit ints
·
6 —
UINT_PTR values such as pointers (32-bit for Win32, 64-bit for Win64)
·
7 —
(pointer to) string
·
8 —
(pointer to) wide string
Non-numeric values name nested structures. The data count refers to the number of elements of the given type in the array case. In addition, if the field has some names associated with it, special keywords are used.
;
; Each defined structure has its own section in the file.
;
; fieldname = offset, type, count, enum/bits
;
[X]
i = 0, 4, 1 // single 4-byte int
ss = 4, s, 1 // nested struct defined elsewhere
e = 20, 4, 1, enum // enumerated type
flags = 24, 4, 1, bits // bitfield
str = 28, 8, 2 // array of 2 LPCWSTRs
array = 32, 3, 3 // array of 3 USHORTs
.a = 40, 4, 1 // member of anonymous struct
.b = 44, 4, 1 // member of anonymous struct
named.c = 48, 4, 1 // member of named nested struct
named.d = 48, 4, 1 // member of named nested struct
f = 52, 4, 1, enum(enumF) // enumerated type
For structure members that have named bits or ordinal values, additional sections list the names of the bits or the ordinal values. The name of one of these list sections can be in one of two forms. In the first form, a keyword of "enum" or "bits" is specified for the member in the ini file. In this case, the name of the list section is the name of the structure, followed by a dot, followed by the name of the member. In the second form, a section name is supplied by the ini file writer by placing it in parenthesis immediately following the "enum" or "bits" keyword. Within the list section, mappings allow the structure dump engine to convert from an enumerated value or bit to a name. Numbers in the section can be in decimal or 0x-prefixed hex.
;
; Each structure member designated as an or enum or bits member has a
; corresponding section to provide the names for the values.
;
; value = name
;
[X.e]
0 = e1
1 = e2
2 = e3
[enumF]
0 = f1
1 = f2
2 = f3
[X.flags]
0 = FLAG_NONE
1 = FLAG_XXXX
2 = FLAG_YYYY
4 = FLAG_ZZZZ
When the kernel debugger extensions dll is loaded, it automatically looks for and loads a structure definition file with the reserved name structdb.ini in the same directory as the dll itself. Structdb.ini can contain a [StructDbList] section, each line of which names another structure definition file. If a filename only is specified, then the file is expected to be either in the same directory as structdb.ini, or in a directory in the PATH environment variable. If any path characters are specified, the path is assumed to be a full path.
[StructDbList]
d:\myproject\mystructs.ini
structs.ini
Besides this special [StructDbList] section, structdb.ini is identical to any other structure definition file as described above, and therefore can itself contain structure definitions.
When looking for nested structure definitions for a structure defined in a structure definition file, !strct will look in the structure definition file before looking in the internal structure database. If a structure is defined in more than one file, the most recently loaded one takes precedence.
Table of Contents Ý
This extension prints maps of pool usage.
!xpool -map [-1]
-1 — if specified, displays maps of paged pool usage. If not specified, displays maps of non-paged pool usage.
Table of Contents Ý
The sections that follow are some notes about the implementation of various features in the debugger extensions.
Dumping all the APC structures by the !apc extension involves finding all the threads in the system – the KTHREAD ApcState structure member contains an array of apc list heads.
The PRCB for each processor contains a linked list of the KDPCs queued for that processor; the implementation for the !dpc extension makes use of this information. Code to read the PCR (which contains a pointer to the PRCB) on a given processor is borrowed from the existing kernel debugger extension DLL.
Ke maintains a system time in a data area shared between the kernel and user mode at the address specified by the KI_USER_SHARED_DATA compile-time constant. The data area is a KUSER_SHARED_DATA structure. Within that structure is the system time and a time zone bias. The !lastlivetime extension retrieves this data, makes some calculations, and then formats the results using the appropriate Win32 APIs to produce the above output.
Table of Contents Ý
Following is a list of structures in the built-in portion of the !strct database.
ACCESS_STATE
ACL
BCTL_DEVICE_CAPABILITIES
CLIENT_ID
CM_COMPONENT_INFORMATION
CM_DISK_GEOMETRY_DEVICE_DATA
CM_EISA_FUNCTION_INFORMATION
CM_EISA_SLOT_INFORMATION
CM_FLOPPY_DEVICE_DATA
CM_FULL_RESOURCE_DESCRIPTOR
CM_INT13_DRIVE_PARAMETER
CM_KEYBOARD_DEVICE_DATA
CM_MCA_POS_DATA
CM_MONITOR_DEVICE_DATA
CM_PARTIAL_RESOURCE_DESCRIPTOR
CM_PARTIAL_RESOURCE_LIST
CM_RESOURCE_LIST
CM_ROM_BLOCK
CM_SCSI_DEVICE_DATA
CM_SERIAL_DEVICE_DATA
CM_SONIC_DEVICE_DATA
CM_VIDEO_DEVICE_DATA
CONFIGURATION_INFORMATION
CONTEXT
CONTROLLER_OBJECT
DEVICE_CONTROL_CONTEXT
DEVICE_DESCRIPTION
DEVICE_FLAGS
DEVICE_OBJECT
DEVOBJ_EXTENSION
DISPATCHER_HEADER
DMA_CONFIGURATION_BYTE0
DMA_CONFIGURATION_BYTE1
DRIVER_EXTENSION
DRIVER_OBJECT
EISA_DMA_CONFIGURATION
EISA_IRQ_CONFIGURATION
EISA_IRQ_DESCRIPTOR
EISA_MEMORY_CONFIGURATION
EISA_MEMORY_TYPE
EISA_PORT_CONFIGURATION
EISA_PORT_DESCRIPTOR
ERESOURCE
EXCEPTION_POINTERS
EXCEPTION_RECORD
FAST_IO_DISPATCH
FAST_MUTEX
FILE_ALIGNMENT_INFORMATION
FILE_BASIC_INFORMATION
FILE_DISPOSITION_INFORMATION
FILE_END_OF_FILE_INFORMATION
FILE_FS_DEVICE_INFORMATION
FILE_FULL_EA_INFORMATION
FILE_NETWORK_OPEN_INFORMATION
FILE_OBJECT
FILE_POSITION_INFORMATION
FILE_STANDARD_INFORMATION
FLOATING_SAVE_AREA
GENERAL_LOOKASIDE
GENERIC_MAPPING
GUID
HAL_BUS_INFORMATION
HAL_CALLBACKS
HAL_DISPATCH
HAL_POWER_INFORMATION
HAL_PROFILE_SOURCE_INFORMATION
HAL_PROFILE_SOURCE_INTERVAL
INITIAL_PRIVILEGE_SET
IO_COMPLETION_CONTEXT
IO_COUNTERS
IO_ERROR_LOG_MESSAGE
IO_ERROR_LOG_PACKET
IO_RESOURCE_DESCRIPTOR
IO_RESOURCE_LIST
IO_RESOURCE_REQUIREMENTS_LIST
IO_SECURITY_CONTEXT
IO_STACK_LOCATION
IO_STATUS_BLOCK
IRP
KAPC
KBUGCHECK_CALLBACK_RECORD
KDEVICE_QUEUE
KDEVICE_QUEUE_ENTRY
KDPC
KERNEL_USER_TIMES
KEVENT
KEY_BASIC_INFORMATION
KEY_FULL_INFORMATION
KEY_NODE_INFORMATION
KEY_VALUE_BASIC_INFORMATION
KEY_VALUE_ENTRY
KEY_VALUE_FULL_INFORMATION
KEY_VALUE_PARTIAL_INFORMATION
KEY_WRITE_TIME_INFORMATION
KIPI_COUNTS
KMUTANT
KPCR
KSEMAPHORE
KSYSTEM_TIME
KTIMER
KWAIT_BLOCK
LUID_AND_ATTRIBUTES
MCA_DRIVER_INFO
MCA_EXCEPTION
MDL
NPAGED_LOOKASIDE_LIST
NT_TIB
OBJECT_HANDLE_INFORMATION
OBJECT_NAME_INFORMATION
OWNER_ENTRY
PAGED_LOOKASIDE_LIST
PCI_COMMON_CONFIG
PCI_SLOT_NUMBER
POOLED_USAGE_AND_LIMITS
PRIVILEGE_SET
PROCESS_ACCESS_TOKEN
PROCESS_BASIC_INFORMATION
PROCESS_WS_WATCH_INFORMATION
QUOTA_LIMITS
RESOURCE_HASH_ENTRY
RESOURCE_PERFORMANCE_DATA
RTL_QUERY_REGISTRY_TABLE
SECTION_OBJECT_POINTERS
SECURITY_QUALITY_OF_SERVICE
SECURITY_SUBJECT_CONTEXT
SECURITY_TOKEN_AUDIT_DATA
SECURITY_TOKEN_PROXY_DATA
SE_IMPERSONATION_STATE
SHARE_ACCESS
TIME_FIELDS
VM_COUNTERS
VPB
WAIT_CONTEXT_BLOCK
WORK_QUEUE_ITEM
ZONE_HEADER
ZONE_SEGMENT_HEADER
Table of Contents Ý