Resolve Memory Leaks Faster

A note about using UMDH: You can trace both Microsoft and non-Microsoft related processes and services by running UMDH commands; however, to actually capture the component name involved in the leak, you’ll need the corresponding symbol file for that component. Some vendors don’t make their symbol files public; if you don’t have access to the symbol file, the information in the UMDH output file will be limited to only the component’s load address and exclude the component name and function being executed. So, to get any meaningful output from UMDH, you should specify at least the Microsoft symbol path, as explained earlier.

Interpreting UMDH Output
When you open the output file—comparefiles.txt in Figure 1—at the top you’ll see the first thread of execution (thread for short), two lines followed by a succession of lines grouped together. Threads represent a running task inside a process; they’re components and functions that have memory allocated. Every process must have at least one thread to be able to load and run. The top two lines are the thread’s summary information, and the group of lines under the summary information represents each thread entry in that process. Let’s look more closely at the output and what it means.

The first two lines of the thread stack show comparative memory-usage information from the two snapshots. The first hexadecimal number, +113faf000, represents the delta change in memory consumption from the first snapshot to the second. So in our example, you can see a change of more than 4.6GB of memory (113faf000-0 = 4.6GB). To see the delta value, you can convert the hex value to decimal by using the Windows calculator’s Scientific view (you can access the calculator either through the Start menu or by running calc.exe).

The next number, 81df8, represents the number of actual allocations that occurred to consume the memory. 81df8 hex represents 531,960 allocations. This high number of allocations is normal, considering this thread is responsible for more than 4GB of memory. The next part, BackTrace8117, is the internal ID with which the system has tagged this thread.

The thread at the top of the UMDH output is the thread that consumed the greatest amount of memory, so that’s where you’ll start investigating the memory-leak problem. Each thread in the output file consists of the component’s load address (e.g., in the first entry, 77EDCA76), the component filename (or DLL name—ntdll in the first entry), and just after the ! sign, the function within the DLL that was executed (e.g., !$$VProc_ImageExportDirectory).

You can use the UMDH output to start your troubleshooting investigation by reviewing the components in the output file and, if necessary, updating them to their latest versions. If the components involved in the process are up-to-date and the leak still occurs, your next step is to call tech support or research the problem further.

Using UMDH Information
You can further narrow down and possibly solve the problem by researching it online. For example, I searched on information from the sample UMDH snapshots—the string “repdrvfs wmi leak,” including “wmi” because the leak occurred in a Windows Management Instrumentation (WMI) process and “repdrvfs” because that component name was high on the thread stack (i.e., the thread that was consuming the most memory) and repeated several times (indicating that the repdrvfs DLL was involved in the consumption of memory). My search found a TechNet article that provided the fix for the problem, at support.microsoft.com/kb/838884. Thus, when you select components to search, you’ll probably be most successful searching those that are both high on the thread stack and repeated.

Of course, you won’t solve all leaky-application problems by using UMDH. However, using UMDH for troubleshooting leaky processes will provide key information that can significantly reduce the time needed to resolve a technical support issue. Check out the Microsoft Advanced Windows Debugging and Troubleshooting blog (blogs.msdn.com/ntdebugging) for further guidance in identifying and resolving Windows technical issues.