Windows® Internals, Sixth Edition, Part 2

EXPERIMENT: Viewing a Device Stack

The kernel debugger command !devstack shows you the device stack of layered device objects associated with a specified device object. This example shows the device stack associated with a device object, \device\keyboardclass0, which is owned by the keyboard class driver:lkd> !devstack keyboardclass0 !DevObj !DrvObj !DevExt ObjectName fffffa800a5e2040 \Driver\Ctrl2cap fffffa800a5e2190 > fffffa800a612ce0 \Driver\kbdclass fffffa800a612e30 KeyboardClass0 fffffa800a612040 \Driver\i8042prt fffffa800a612190 fffffa80076e0a00 \Driver\ACPI fffffa80076f3a90 0000005c !DevNode fffffa800770f750 : DeviceInst is "ACPI\PNP0303\4&b0a2531&0" ServiceName is "i8042prt"

The output highlights the entry associated with KeyboardClass0 with the “>” character in column one. The entries above that line are drivers layered above the keyboard class driver, and those below are layered beneath it. In general, IRPs flow from the top of the stack to the bottom.

The file system is most likely to reuse an IRP if the request it receives translates into a single straightforward request to a device. For example, if an application issues a read request for the first 512 bytes in a file stored on a volume, the NTFS file system would simply call the volume manager driver, asking it to read one sector from the volume, beginning at the file’s starting location.

To accommodate its reuse by multiple drivers in a request to layered drivers, an IRP contains a series of IRP stack locations (not to be confused with the CPU stack used by threads to store function parameters and return addresses). These data areas, one for every driver that will be called, contain the information that each driver needs to execute its part of the request—for example, function code, parameters, and driver context information. As Figure 8-16 illustrates, additional stack locations are filled in as the IRP passes from one driver to the next. You can think of an IRP as being similar to a stack in the way data is added to it and removed from it during its lifetime. However, an IRP isn’t associated with any particular process, and its allocated size doesn’t grow or shrink. The I/O manager allocates an IRP from one of its IRP look-aside lists or nonpaged system memory at the beginning of the I/O operation.

Note

Since the number of devices on a given stack is known in advance, the I/O manager allocates one stack location per device driver on the stack. However, there are situations in which an IRP might be directed into a new driver stack, as can happen in scenarios involving the Filter Manager, which allows one filter to redirect an IRP to another filter (going from a local file system to a network file system, for example). The I/O manager exposes an API, IoAdjustStackSizeForRedirection, that enables this functionality by adding the required stack locations because of devices present on the redirected stack.

EXPERIMENT: Examining IRPs

In this experiment, you’ll find an uncompleted IRP on the system, and you’ll determine the IRP type, the device at which it’s directed, the driver that manages the device, the thread that issued the IRP, and what process the thread belongs to.

At any point in time, there are at least a few uncompleted IRPs on a system. This occurs because there are many devices to which applications can issue IRPs that a driver will complete only when a particular event occurs, such as data becoming available. One example is a blocking read from a network endpoint. You can see the outstanding IRPs on a system with the !irpfind kernel debugger command:lkd> !irpfind Scanning large pool allocation table for Tag: Irp? (86c16000 : 86d16000) Searching NonPaged pool (80000000 : ffc00000) for Tag: Irp? Irp [ Thread ] irpStack: (Mj,Mn) DevObj [Driver] MDL Process 862d2380 [8666dc68] irpStack: ( c, 2) 84a6f020 [ \FileSystem\Ntfs] 862d2bb0 [864e3d78] irpStack: ( e,20) 86171348 [ \Driver\AFD] 0x864dbd90 862d4518 [865f7600] irpStack: ( d, 0) 86156328 [ \FileSystem\Npfs] 862d4688 [867133f0] irpStack: ( 3, 0) 86156328 [ \FileSystem\Npfs] 862dd008 [00000000] Irp is complete (CurrentLocation 4 > StackCount 3) 0x00420000 862dee28 [864fc030] irpStack: ( 3, 0) 84baf030 [ \Driver\kbdclass]