Kernel Debugger Extensions Specification (Phase 3)

 

Last Updated: 12/25/99

 

 


1.     Introduction. 1

1.1       Delivery and Supported Targets. 1

1.2       Extensions. 1

2.     !apc and !dpc. 1

3.     !ethread and !kthread. 2

4.     !idt 2

5.     !ip. 2

6.     !kqueue. 3

7.     !lastlivetime. 3

8.     !list and !singlelist 3

9.     !s. 4

10.       !smb. 4

11.       !stack. 5

12.       !strct 5

12.1     Usage. 6

12.2     Output Format 6

12.3     User-Supplied Structures. 7

13.       !xpool 9

14.       Implementation Notes. 9

14.1     !apc. 9

14.2     !dpc. 9

14.3     !lastlivetime. 9

Appendix A: Structures in the Structure Database. 9

 


1.      Introduction

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.

 

1.1       Delivery and Supported Targets

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.

 

1.2       Extensions

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 Ý

 

2.      !apc and !dpc

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 Ý

 

3.      !ethread and !kthread

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 Ý

 

4.      !idt

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 Ý

 

5.      !ip

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 Ý

 

6.      !kqueue

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 Ý

 

7.      !lastlivetime

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 Ý

 

8.      !list and !singlelist

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 Ý

 

9.      !s

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 Ý

 

10.         !smb

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 Ý

 

11.         !stack

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 Ý

 

12.         !strct

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.

 

12.1  Usage

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 Ý

 

12.2  Output Format

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 Ý

 

12.3  User-Supplied Structures

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 Ý

 

13.         !xpool

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 Ý

 

14.         Implementation Notes

The sections that follow are some notes about the implementation of various features in the debugger extensions.

 

14.1  !apc

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.

 

14.2  !dpc

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.

 

14.3  !lastlivetime

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 Ý

 

Appendix A: Structures in the Structure Database

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 Ý