Windows® Internals, Sixth Edition, Part 2

The entry in bold in the output describes an IRP that is directed at the Kbdclass driver, so it is likely that the IRP was issued by the Windows subsystem raw input thread that reads keyboard input. Examining the IRP with the !irp command reveals the following:lkd> !irp 862dee28 Irp is active with 3 stacks 3 is current (= 0x862deee0) No Mdl: System buffer=864f5108: Thread 864fc030: Irp stack trace. cmd flg cl Device File Completion-Context [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 >[ 3, 0] 0 1 84baf030 864f52f8 00000000-00000000 pending \Driver\kbdclass Args: 00000078 00000000 00000000 00000000

The active stack location is at the bottom. (The debugger shows the active location with a “>” character in column one.) It has a major function of 3, which corresponds to IRP_MJ_READ.

The next step is to see what device object the IRP is targeting by executing the !devobj command on the device object address in the active stack location.lkd> !devobj 84baf030 Device object (84baf030) is for: KeyboardClass1 \Driver\kbdclass DriverObject 84b706b8 Current Irp 00000000 RefCount 0 Type 0000000b Flags 00002044 Dacl 8b0538b8 DevExt 84baf0e8 DevObjExt 84baf1c8 ExtensionFlags (0x00000800) Unknown flags 0x00000800 AttachedTo (Lower) 84badaa0 \Driver\TermDD Device queue is not busy.

The device at which the IRP is targeted is KeyboardClass1. The presence of a device object owned by the Termdd driver attached beneath it reveals that it is the device that represents keyboard input from a Terminal Server client, not the physical keyboard.

We can see details about the thread and process that issued the IRP by using the !thread and !process commands:lkd> !thread 864fc030 THREAD 864fc030 Cid 01d4.0234 Teb: 7ffd9000 Win32Thread: ffac4008 WAIT: (WrUserRequest) KernelMode Alertable 8623c620 SynchronizationEvent 864fc3a8 NotificationTimer 864fc378 SynchronizationTimer 864fc360 SynchronizationEvent IRP List: 86af0e28: (0006,01d8) Flags: 00060970 Mdl: 00000000 86503958: (0006,0268) Flags: 00060970 Mdl: 00000000 862dee28: (0006,01d8) Flags: 00060970 Mdl: 00000000 Not impersonating DeviceMap 8b0087d8 Owning Process 0 Image: Attached Process 864d2d90 Image: csrss.exe Wait Start TickCount 171909 Ticks: 29 (0:00:00:00.452) Context Switch Count 121222 UserTime 00:00:00.000 KernelTime 00:00:00.717 Win32 Start Address 0x764d9a30 Stack Init 96f46000 Current 96f45c28 Base 96f46000 Limit 96f43000 Call 0 Priority 15 BasePriority 13 PriorityDecrement 0 IoPriority 2 PagePriority 5 lkd> !process 864d2d90 PROCESS 864d2d90 SessionId: 1 Cid: 0208 Peb: 7ffdf000 ParentCid: 0200 DirBase: ce21e0a0 ObjectTable: 964a6e68 HandleCount: 284. Image: csrss.exe

Locating the thread in Process Explorer by opening the Properties dialog box for Csrss.exe and going to the Threads tab confirms, through the names of the functions on its stack, the role of the thread as a raw input thread for the Windows subsystem:

After the disk controller’s DMA adapter finishes a data transfer, the disk controller interrupts the host, causing the ISR for the disk controller to run, which requests a DPC callback completing the IRP, as shown in Figure 8-17.

As an alternative to reusing a single IRP, a file system can establish a group of associated IRPs that work in parallel on a single I/O request. For example, if the data to be read from a file is dispersed across the disk, the file system driver might create several IRPs, each of which reads some portion of the request from a different sector. This queuing is illustrated in Figure 8-18.

Figure 8-17. Completing a layered I/O request

Figure 8-18. Queuing associated IRPs