The information in this post follows on from earlies post on Pool Tags. The steps we discuss in this post assume that you are very comfortable with kernel debugging, and in particular live debugging.
Let’s say that you have a server that is leaking Pool memory (either Paged or NonPaged). You’ve done troubleshooting and identified the leaking tag, but you want to examine the actual stack leading up to the allocation. Using Special Pool and the Debugger Tools you can find out exactly who is allocating the tag. Now, we’re not going to dive too deep into Special Pool itself, but in a nutshell, this feature configures Windows to request memory allocations from a reserved memory pool when the memory is allocated with a specific pool tag or is within a specified size range.
So let’s take a look at an example. We’re going to use the Ddk tag for our example. The Ddk tag is the default tag for driver-allocated memory.
- On the system where the tag is leaking, we navigate to the HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management key
- Create a REG_DWORD value called PoolTag. In this value, we enter the tag value in little-endian format (i.e. backwards). Remember that Pool Tags are four bytes(characters), so the tag is actually Ddk<space>. When we convert this string into ASCII (and then into Hex) we get the following:
Windows, Architecture, Debugging, Memory Management, Performance, Troubleshooting, Knowledgebase
- Microsoft KB188831: How to use the Special Pool Feature
- MSDN: Special Pool (Driver Development Kit)
- MSDN: Special Pool (Debugging Tools for Windows)