Windows® Internals, Sixth Edition, Part 2

You can obtain a listing of the functions a driver has defined for its dispatch routines by entering a 7 after the driver object’s name (or address) in the !drvobj kernel debugger command. The following output shows that drivers support 28 IRP types.lkd> !drvobj \Driver\kbdclass 7 Driver object (fffffa800adc2e70) is for: \Driver\kbdclass Driver Extension List: (id , addr) Device Object list: fffffa800b04fce0 fffffa800abde560 DriverEntry: fffff880071c8ecc kbdclass!GsDriverEntry DriverStartIo: 00000000 DriverUnload: 00000000 AddDevice: fffff880071c53b4 kbdclass!KeyboardAddDevice Dispatch routines: [00] IRP_MJ_CREATE fffff880071bedd4 kbdclass!KeyboardClassCreate [01] IRP_MJ_CREATE_NAMED_PIPE fffff800036abc0c nt!IopInvalidDeviceRequest [02] IRP_MJ_CLOSE fffff880071bf17c kbdclass!KeyboardClassClose [03] IRP_MJ_READ fffff880071bf804 kbdclass!KeyboardClassRead ... [19] IRP_MJ_QUERY_QUOTA fffff800036abc0c nt!IopInvalidDeviceRequest [1a] IRP_MJ_SET_QUOTA fffff800036abc0c nt!IopInvalidDeviceRequest [1b] IRP_MJ_PNP fffff880071c0368 kbdclass!KeyboardPnP

While active, each IRP is usually queued in an IRP list associated with the thread that requested the I/O. (Otherwise, it is stored in the file object when performing thread-agnostic I/O, which is described earlier in this chapter.) This allows the I/O system to find and cancel any outstanding IRPs if a thread terminates with I/O requests that have not been completed. Additionally, paging I/O IRPs are also associated with the faulting thread (although they are not cancellable). This allows Windows to use the thread-agnostic I/O optimization —when an APC is not used to complete I/O if the current thread is the initiating thread. This means that page faults occur inline, instead of requiring APC delivery.

EXPERIMENT: Looking at a Thread’s Outstanding IRPs

When you use the !thread command, it prints any IRPs associated with the thread. Run the kernel debugger with live debugging, and locate the service control manager process (Services.exe) in the output generated by the !process command:lkd> !process 0 0 **** NT ACTIVE PROCESS DUMP **** ... PROCESS 8623b840 SessionId: 0 Cid: 0270 Peb: 7ffd6000 ParentCid: 0210 DirBase: ce21e080 ObjectTable: 964c06a0 HandleCount: 198. Image: services.exe ...

Then dump the threads for the process by executing the !process command on the process object. You should see many threads, with most of them having IRPs reported in the IRP List area of the thread information (note that the debugger will show only the first 17 IRPs for a thread that has more than 17 outstanding I/O requests):lkd> !process 8623b840 PROCESS 8623b840 SessionId: 0 Cid: 0270 Peb: 7ffd6000 ParentCid: 0210 DirBase: ce21e080 ObjectTable: 964c06a0 HandleCount: 198. Image: services.exe VadRoot 862b1358 Vads 71 Clone 0 Private 466. Modified 14. Locked 2. DeviceMap 8b0087d8 ... THREAD 86a1d248 Cid 0270.053c Teb: 7ffdc000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Alertable 86a40ca0 NotificationEvent 86a40490 NotificationEvent IRP List: 86a81190: (0006,0094) Flags: 00060900 Mdl: 00000000 ...

Choose an IRP, and examine it with the !irp command:lkd> !irp 86a81190 Irp is active with 1 stacks 1 is current (= 0x86a81200) No Mdl: No System Buffer: Thread 86a1d248: Irp stack trace. cmd flg cl Device File Completion-Context >[ 3, 0] 0 1 86156328 86a4e7a0 00000000-00000000 pending \FileSystem\Npfs Args: 00000800 00000000 00000000 00000000

This IRP has a major function of 3, which corresponds to IRP_MJ_READ, which can be found in WDM.h. It has one stack location and is targeted at a device owned by the Npfs driver (the Named Pipe File System driver). (Npfs is described in Chapter 7, “Networking,” in Part 1.)

IRP Buffer Management

When an application or a device driver indirectly creates an IRP by using the NtReadFile, NtWriteFile, or NtDeviceIoControlFile system services (or the Windows API functions corresponding to these services, which are ReadFile, WriteFile, and DeviceIoControl), the I/O manager determines whether it needs to participate in the management of the caller’s input or output buffers. The I/O manager performs three types of buffer management: