Overview

The best way to detect memory leak in drivers is to use ""AppVerifier"" tool. This tool comes with some default shims that can detect leaks from most common resources such as heap and handles. Also you can write your own shims to apply to ""AppVerifier"" tool.

However, currently this tool has some limitations. The biggest one is that ""AppVerifier"" must apply shims to the targeted dll before it gets loaded. However, there are some practical methods to work around it.

Using App Verifier

Please read App Verifier Tutorial document for detailed information about how to use App Verifier to detect memory leak in a dll. The Toutorial document can be downloaded here.
This doc has described how to load ""AppVerifier"" during the boot time, by doing so the ""AppVerifier"" can load shim layers for targeted drivers that loaded during the system boot up time.

Using DevMgrTool

To load ""AppVerifier"" during the boot up time normally requires you to rebuild the image. If you do not want to do so, there is another way to use ""AppVerifier"" for already loaded drivers.
We provided a tool named ""DevMgrTool"". This is a command-line tool that can enumerate, unload and reload drivers in the system. For detailed info about how to use this tool, please refer to the doc Load/Unload driver tool.

Here is the recap of steps of using this tool to detect memory leak:
1. Use ""DevMgrTool"" to identify the targeted driver.
2. Use ""DevMgrTool"" to unload the targeted driver. If you only need heap shim and handle shim, this tool can directly do that for you after it unload the driver.
3. If you need to load some other shims, either use ""DevMgrTool"" or ""AppVerifier"" itself to do so. Otherwise skip this step.
4. Use ""DevMgrTool"" to reload the driver again. After driver gets loaded, use ""AppVerifier"" to set checkpoints if you want.
5. Run tests
6. Use ""AppVerifer"" to check delta if you had setup the checkpoints. Otherwise, use ""DevMgrTool"" to unload this driver. After the driver is unloaded, ""AppVerifier"" should automatically generate the report for you.

Also there are two limits for the existing version of this tool:
1. If the driver is not managed by device manager, or it is not loaded by another driver that managed by device manager, then it would not be able to be picked up by this tool.
2. You will have to use PB with KITL connection to the device. All the info print out by this tool can only be seen in the debug output window of PB.

Other Alternative Methods

If you do not have ""AppVerifier"", then things will become much tougher.
Under such situation, if you are using PB, then the command “mi” in target control window can give some memory information in real time, such as how many r/w pages that a process is currently consuming. But ping down to the memory usage of the specific dll will be really hard.

Here are some other generic tips that may help you if you do not have ""AppVerifier"":
1. Run stress tests. This can trigger the memory leak to accumulate to an easy-to-spot level quickly.
2. For plug and play driver, try insert/remove devices for many times, that may help you to find out whether there are memory leaks in driver’s initialization and cleanup stages.
3. Instrument your driver memory operation as much as you can.
4. Try creating your own heap for the driver instead of using what OS provides. If you tag your heap, it would be easier to debug and analyze the driver’s memory-related behavior.

---

Go up to BSP Advanced Features
Go up to Big Book of BSP

Thank you for contributing to this BSP Wiki. To ensure your comments and concerns receive proper exposure, include bspwiki""@""microsoft"".""com when providing feedback or topical suggestions.

---