|Debugging Tools for Windows|
If you suspect there is a kernel-mode memory leak, the easiest way to determine which pool tag is associated with the leak is to use the PoolMon tool.
PoolMon (Poolmon.exe) monitors pool memory usage by pool tag name. This tool is included in the Windows Driver Kit (WDK). For a full description, see
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. For more details, see GFlags.
On Windows Server 2003 and later versions of Windows, pool tagging is always enabled.
The PoolMon header displays the total paged and non-paged pool bytes. The columns show pool use for each pool tag. The display is updated automatically every few seconds. For example:
Commit: 24140K Limit: 24952K Peak: 24932K Pool N: 744K P: 2180K
Tag Type Allocs Frees Diff Bytes Per Alloc
CM Paged 1283 ( 0) 1002 ( 0) 281 1377312 ( 0) 4901
Strg Paged 10385 ( 10) 6658 ( 4) 3727 317952 ( 512) 85
Fat Paged 6662 ( 8) 4971 ( 6) 1691 174560 ( 128) 103
MmSt Paged 614 ( 0) 441 ( 0) 173 83456 ( 0) 482
PoolMon has command keys that sort the output according to various criteria. Press the letter associated with each command in order to re-sort the data. It takes a few seconds for each command to work.
The sort commands include:
|P||Limits the tags shown to nonpaged pool, paged pool, or both. Repeatedly pressing P cycles through each of these options, in that order.|
|B||Sorts tags by maximum byte usage.|
|M||Sorts tags by maximum byte allocations.|
|T||Sorts tags alphabetically by tag name.|
|E||Causes the display to include the paged and non-paged totals across the bottom.|
|A||Sorts tags by allocation size.|
|F||Sorts tags by free operations.|
|S||Sorts tags by the difference between allocations and frees.|
To find a memory leak with the PoolMon utility, follow this procedure:
Typically, after an application reaches a stable running state, it allocates memory and free memory at roughly the same rate. If it tends to allocate memory faster than it frees it, its memory use will grow over time. This often indicates a memory leak.
After you have determined which pool tag is associated with the leak, this might reveal all you need to know about the leak. If you need to determine which specific instance of the allocation routine is causing the leak, see Using the Kernel Debugger to Find Kernel-Mode Memory Leaks.