|Debugging Tools for Windows|
The kernel debugger determines the precise location of a kernel-mode memory leak.
On Windows 2000 and Windows XP, you must first use GFlags to enable pool tagging. GFlags is included in Debugging Tools for Windows. Start GFlags, choose the System Registry tab, check the Enable Pool Tagging box, and then click Apply. You must restart Windows for this setting to take effect.
On Windows Server 2003 and later versions of Windows, pool tagging is always enabled.
To determine which pool tag is associated with the leak, it is usually easiest to use the PoolMon tool for this step. For details, see Using PoolMon to Find Kernel-Mode Memory Leaks.
Alternatively, you can use the kernel debugger to look for tags associated with large pool allocations. To do so, follow this procedure:
Sorting by Paged Pool Consumed
Tag Allocs Used Allocs Used
Abc 0 0 36405 33930272
Tron 0 0 552 7863232
IoN7 0 0 10939 998432
Gla5 1 128 2222 924352
Ggb 0 0 22 828384
After you have determined the pool tag associated with the leak, follow this procedure to locate the leak itself:
820f2ba4 41 62 63 20 Abc
Using this procedure, you can determine which code resident in memory is overallocating pool with the tag Abc.
To clear the breakpoint, set PoolHitTag to zero:
If there are several different places where memory with this tag is being allocated and these are in an application or driver that you have written, you can alter your source code to use unique tags for each of these allocations.
If you cannot recompile the program but you want to determine which one of several possible locations in the code is causing the leak, you can unassemble the code at each location and use the debugger to edit this code resident in memory so that each instance uses a distinct (and previously unused) pool tag. Then allow the system to run for several minutes or more. After some time has passed, break in again with the debugger and use the !poolfind extension to find all pool allocations associated with each of the new tags.