Windows® Internals, Sixth Edition, Part 1

If you have symbols available, you can zoom in on individual modules and see the time spent by function name. For example, profiling the system while rapidly dragging a window around the screen resulted in the following (partial) output: C:\WinDDK\7600.16385.1\tools\Other\i386>kernrate.exe -z ntkrnlpa -z win32k /==============================\ < KERNRATE LOG > \==============================/ Date: 2011/03/09 Time: 16:49:56 Time 4191 hits, 25000 events per hit -------- Module Hits msec %Total Events/Sec NTKRNLPA 3623 5695 86 % 15904302 WIN32K 303 5696 7 % 1329880 INTELPPM 141 5696 3 % 618855 HAL 61 5695 1 % 267778 CDD 30 5696 0 % 131671 NVLDDMKM 13 5696 0 % 57057 ----- Zoomed module WIN32K.SYS (Bucket size = 16 bytes, Rounding Down) -------- Module Hits msec %Total Events/Sec BltLnkReadPat 34 5696 10 % 149227 memmove 21 5696 6 % 92169 vSrcTranCopyS8D32 17 5696 5 % 74613 memcpy 12 5696 3 % 52668 RGNOBJ::bMerge 10 5696 3 % 43890 HANDLELOCK::vLockHandle 8 5696 2 % 35112 ----- Zoomed module NTKRNLPA.EXE (Bucket size = 16 bytes, Rounding Down) -------- Module Hits msec %Total Events/Sec KiIdleLoop 3288 5695 87 % 14433713 READ_REGISTER_USHORT 95 5695 2 % 417032 READ_REGISTER_ULONG 93 5695 2 % 408252 RtlFillMemoryUlong 31 5695 0 % 136084 KiFastCallEntry 18 5695 0 % 79016

The module with the second hit rate was Win32k.sys, the windowing system driver. Also high on the list were the video driver and Cdd.dll, a global video driver used for the 3D-accelerated Aero desktop theme. These results make sense because the main activity in the system was drawing on the screen. Note that in the zoomed display for Win32k.sys, the functions with the highest hits are related to merging, copying, and moving bits, the main GDI operations for painting a window dragged on the screen.

One important restriction on code running at DPC/dispatch level or above is that it can’t wait for an object if doing so necessitates the scheduler to select another thread to execute, which is an illegal operation because the scheduler relies on DPC-level software interrupts to schedule threads. Another restriction is that only nonpaged memory can be accessed at IRQL DPC/dispatch level or higher.

This rule is actually a side effect of the first restriction because attempting to access memory that isn’t resident results in a page fault. When a page fault occurs, the memory manager initiates a disk I/O and then needs to wait for the file system driver to read the page in from disk. This wait would, in turn, require the scheduler to perform a context switch (perhaps to the idle thread if no user thread is waiting to run), thus violating the rule that the scheduler can’t be invoked (because the IRQL is still DPC/dispatch level or higher at the time of the disk read). A further problem results in the fact that I/O completion typically occurs at APC_LEVEL, so even in cases where a wait wouldn’t be required, the I/O would never complete because the completion APC would not get a chance to run.

If either of these two restrictions is violated, the system crashes with an IRQL_NOT_LESS_OR_EQUAL or a DRIVER_IRQL_NOT_LESS_OR_EQUAL crash code. (See Chapter 14 in Part 2 for a thorough discussion of system crashes.) Violating these restrictions is a common bug in device drivers. The Windows Driver Verifier (explained in the section “Driver Verifier” in Chapter 10, “Memory Management,” in Part 2) has an option you can set to assist in finding this particular type of bug.

Interrupt Objects