Umdh exe to find memory leaks on windows
Finding Memory Leaks in Windows 2000
How to Use Umdh.exe to Find Memory Leaks
This information applies to:
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Server
Microsoft Windows 2000 Professional
Microsoft Windows NT Server version 4.0
Microsoft Windows NT Workstation version 4.0
User-Mode Dump Heap Utility (UMDH)
The user-mode dump heap utility works with the operating system to analyze the Windows heap allocations for a specific process. While this utility, and the other tools associated with it, are primarily targeted for Windows 2000, a Umdh_nt4.exe application, and the Dbghelp.dll which is not available on Windows NT, have been supplied for use under Windows NT version 4.0 Service Pack 6 (SP6). The following discusses how you can use UMDH to help locate memory leak problems. A self-extracting executable is included that contains the following tools:
Umdh.exe — This utility is used to dump the heap allocation information for a process.
Umdh_nt4.exe and Dbghelp.dll — This is the Windows NT 4.0 SP6 version of the UMDH tool.
Gflags.exe — This utility sets the appropriate registry entries for the application that will be analyzed. The operating system looks at the registry entries to determine if an application’s heap allocations will be tracked.
Tlist.exe — This application lists all of the processes running on a machine and all of their related process IDs.
Dhcmp.exe — This tool is used to compare two UMDH dumps to determine where a possible memory leak is occurring.
You can download this package either directly from the Microsoft Download Center or from our server:
Umdhtools.exe Microsoft Download Center Release Date: Feb. 5, 2001
Umdhtools.exe Download From Our Server Release Date: Feb. 5, 2001
Both we and Microsoft used the most current virus detection software available on the date of posting to scan this file for viruses. Once posted, the file is housed on secure servers that prevent any unauthorized changes to the file.
Before You Begin Using UMDH!
If you think you are experiencing a memory leak, please be aware that memory leaks may not be what they appear to be. You may discover that a memory leak is really not a memory leak at all, but rather a performance enhancement. For example, the Microsoft Jet database engine can consume large amounts of memory (up to 128 MB on a 256-MB computer) for its data retrieval and writing caches. The cache allows the Jet engine to achieve fast read-ahead and write-ahead buffering.
To determine whether or not a process is experiencing memory leaks, use the Windows Performance Monitor (Perfmon.exe) and monitor «Private Bytes» under the Process category for your application. Privates Bytes is the total amount of memory the process has allocated but is not sharing with other processes. Note that this is different from «Virtual Bytes,» which is also interesting to monitor. Virtual Bytes is the current size in bytes of the virtual address space the process is using. An application can leak virtual memory but not see a difference in the amount of private bytes allocated. If you don’t see memory rising when monitoring private bytes but suspect that you are still running out of memory, you should monitor virtual bytes to see if you are exhausting virtual memory.
The following MSDN article «Finding Leaks and Bottlenecks with a Windows NT PerfMon COM Object» will assist you further with detecting memory leaks:
To be certain your application is leaking memory, you should place the suspect code in a loop with many iterations, and monitor private and virtual bytes for any increases of memory. Watch to make certain that the number of private bytes and virtual bytes doesn’t eventually stay the same and stops rising. If there is a point at which the memory stops rising, that is, it does not continue to climb indefinitely, you are not seeing a memory leak but are probably seeing some cache that is growing to its maximum size.
Capturing Heap Dumps with UMDH
UMDH (or Umdh_nt4.exe if you are using Windows NT 4.0 SP6) is a tool that dumps information about a process’s heap allocations. This information includes the callstack for each allocation, the number of allocations made through that callstack, and the number of bytes consumed through that callstack. For example:
This UMDH output shows that there were 21280 (0x5320) bytes allocated total from the callstack. The 21280 bytes were allocated from 20 (0x14) separate allocations of 1064 bytes (0x428). The callstack is given a identifier of BackTrace00053.
To produce a dump of the heap allocations, you must first let the operating system know that you would like the kernel to track the allocations. This is done by using the Gflags.exe utility.
Let’s assume that you want to dump the heap contents for Notepad.exe. By the way, most processes have more than one heap active and the UMDH log will contain all of them. First you need to enable stack trace acquisition for the application you want to test. This feature is not enabled by default. The command to enable it is:
Before using UMDH, you also need to install the correct debug symbols for the components of your application as well as the operating system. Typically, the operating system symbols are installed in the SYMBOLS folder on the WINNT folder. UMDH attempts to find the symbol files by using the _NT_SYMBOL_PATH. The command for setting the path from a command prompt is:
With the image flags set and the symbols installed, you are ready to start Notepad. After the program is started, you need to determine the Process ID (PID) of the Notepad process just started. The command for this is:
Using Dhcmp.exe to Compare UMDH Logs
While the UMDH log file contains valuable information about the current state of the heaps for a process, if you are concerned with finding a memory leak, it may be more valuable to compare the outputs of two logs and find out what callstack has seen the largest growth between the two dumps. The Dhcmp.exe utility helps compare two UMDH logs to provide an analysis of the difference between them. Once you have two logs captured at different intervals, you can then use the following command:
The next step is to find out what’s in that backtrace. If you open the second DH log file and search for «BackTrace00053» you might find something that resembles the following:
By looking at the callstack, you can see that the LeakyFunc function is allocating memory by way of the Visual C++ run-time library. If you find that the number of allocations grows as you took more dumps, you might be able to conclude that memory is not being freed.
Enabling Stack Traces
The most important information in UMDH logs is the stack traces of the heap allocations. By analyzing them it can be understood whether a process leaks heap memory. These stack traces are not acquired by default. The feature can be enabled per-process or system-wide. Use the following command to enable stack tracing system-wide:
Restart the computer after this command.
For per-process enabling, the command is
Use the following commands to verify what settings have been set system-wide or for a specific process:
IMPORTANT : If you are using Windows NT 4.0 Service Pack 6, you must use Umdh_nt4.exe, rather than Umdh.exe, and you must use the above command to set system-wide stack tracing. Be certain to reboot. Umdh_nt4 stack tracing does not work on a per process basis on Windows NT version 4. It must be set for the entire system.
UMDH uses the IMAGEHLP library for symbol manipulation. This is the standard tool for such tasks and it is also used by Microsoft debuggers. One of the most important steps to using UMDH is to ensure that you have good symbol files (.dbg or .pdb file) to get a good stack trace. The debug symbol files can be installed from the Windows NT CD, or in the case of Microsoft Windows 2000, from the Windows 2000 Support Tools CD. At a minimum, you need the Kernel32.dbg and Ntdll.dbg symbol files. You can always acquire additional debugging symbols as needed as you find out more about which components are leaking the memory.
When building components with Visual C++, it is important that you not have Program Database for Edit and Continue selected for the C++ compiler options. Instead, select Program Database .
To set the symbol path, initialize the _NT_SYMBOL_PATH environment variable to the path to be used. This can be done once when the test computer is set up by using the System application in Control Panel (Advanced, Environment Variables) or inside a command window before UMDH is run. Usually the symbols are copied to the test machine in the %windir%\Symbols folder. In this case, use the following command to set the variable:
Invoking the UMDH Tool
The only required command-line parameter for UMDH is the -p option, which specifies the PID of the process from which a heap dump will be obtained. The PID can be obtained by using Task Manager or the Tlist.exe program. For a command similar to the following, the log will be dumped to the standard output:
The default log obtained by UMDH contains an enumeration of heap consumers sorted by allocation count. If, for debugging purposes, you also need a dump of all allocated blocks with their corresponding stack traces, the -d option must be used:
UMDH Output Explained
If you redirected the log to a file ( umdh -p:PID -f:umdh.log ), the contents will resemble the following, which was obtained from a running Notepad process: The log contains a dump of every heap in the process. In this example, the log starts with a heap at address 270000. After a few global counters for the heap, the log contains a dump in decreasing sorted order of stack traces that are responsible for the most allocations. By comparing the dynamics of memory used at different moments you can deduce what happened in the process and if any heap use looks like a leak.
Problems That Can Be Encountered When Using UMDH
The two most common errors when using UMDH are not having stack tracing enabled and not having good symbols. Incorrect symbols for Ntdll.dll prevent UMDH from running. For the other symbols files, UMDH will run but the log file will contain stack traces that do not have function names but instead have relative addresses inside modules. A distant third error is specifying a wrong PID.
The following error message results when you attempt to run UMDH for a process that does not have stack tracing enabled:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
A stack trace was not saved for this allocation (Index == 0)
The Dhcmpgui.exe tool can be used to compare two UMDH logs. This tool is located in the Dhcmpgui.zip file. It calls out to Dhcmp.exe (make certain that you have this in your PATH). Click File 1 and File 2 to specify the two UMDH logs to compare.
After selecting the two files to compare, you will see a list of the differences. The columns listed are the number of bytes allocated, number of allocations, and the BackTraceID, respectively. You can sort by any one of those columns by clicking the appropriate button, and then clicking Sort . To see the BackTrace (callstack) for any line, just double-click it. This provides an easy way to compare two logs and to quickly get to the callstack for the callstack that is leaking memory.
The source code has been provided for Dhcmpgui.exe in case you want to make any modifications. The project requires Visual C++ version 6.0.
Calling UMDH from Visual Basic
There may be times when it is useful to dump a number of logs over time because the leak may not be very noticeable at first. For example, suppose you suspect that your ASP application is leaking memory. It may be helpful to write a COM component in Visual Basic that shells out to UMDH. You can then call that component from your ASP page.
Following is some Visual Basic code that invokes UMDH and creates a log file based on the current time:
Last updated on February 25, 2001
Copyright В©1999-2000 DEW Associates Corporation . All rights reserved.
Using UMDH to Find a User-Mode Memory Leak
The user-mode dump heap (UMDH) utility works with the operating system to analyze Windows heap allocations for a specific process. UMDH locates which routine in a specific process is leaking memory.
UMDH is included in Debugging Tools for Windows. For full details, see UMDH.
Preparing to Use UMDH
If you have not already determined which process is leaking memory, do that first. For details, see Using Performance Monitor to Find User-Mode Memory Leaks.
The most important data in the UMDH logs are the stack traces of the heap allocations. To determine whether a process is leaking heap memory, analyze these stack traces.
Before using UMDH to display the stack trace data, you must use GFlags to configure your system properly. GFlags is included in Debugging Tools for Windows.
The following GFlags settings enable UMDH stack traces:
In the GFlags graphical interface, choose the Image File tab, type the process name (including the file name extension), press the TAB key, select Create user mode stack trace database, and then select Apply.
Or, equivalently, use the following GFlags command line, where ImageName is the process name (including the file name extension):
Use this command to clear the GFlag settings once you are done. For more information, see GFlags Commands.
By default, the amount of stack trace data that Windows gathers is limited to 32 MB on an x86 processor, and 64 MB on an x64 processor. If you must increase the size of this database, choose the Image File tab in the GFlags graphical interface, type the process name, press the TAB key, check the Stack Backtrace (Megs) check box, type a value (in MB) in the associated text box, and then select Apply. Increase this database only when necessary, because it may deplete limited Windows resources. When you no longer need the larger size, return this setting to its original value.
If you changed any flags on the System Registry tab, you must restart Windows to make these changes effective. If you changed any flags on the Image File tab, you must restart the process to make the changes effective. Changes to the Kernel Flags tab are effective immediately, but they are lost the next time Windows restarts.
Before using UMDH, you must have access to the proper symbols for your application. UMDH uses the symbol path specified by the environment variable _NT_SYMBOL_PATH. Set this variable equal to a path containing the symbols for your application. If you also include a path to Windows symbols, the analysis may be more complete. The syntax for this symbol path is the same as that used by the debugger; for details, see Symbol Path.
For example, if the symbols for your application are located at C:\MySymbols, and you want to use the public Microsoft symbol store for your Windows symbols, using C:\MyCache as your downstream store, you would use the following command to set your symbol path:
In addition, to assure accurate results, you must disable BSTR caching. To do this, set the OANOCACHE environment variable equal to one (1). Make this setting before you launch the application whose allocations are to be traced.
If you need to trace the allocations made by a service, you must set OANOCACHE as a system environment variable and then restart Windows for this setting to take effect.
Detecting Increases in Heap Allocations with UMDH
After making these preparations, you can use UMDH to capture information about the heap allocations of a process. To do so, follow this procedure:
Determine the process ID (PID) for the process you want to investigate.
Use UMDH to analyze the heap memory allocations for this process, and save it to a log file. Use the -p switch with the PID, and the -f switch with the name of the log file. For example, if the PID is 124, and you want to name the log file Log1.txt, use the following command:
Use Notepad or another program to open the log file. This file contains the call stack for each heap allocation, the number of allocations made through that call stack, and the number of bytes consumed through that call stack.
Because you are looking for a memory leak, the contents of a single log file are not sufficient. You must compare log files recorded at different times to determine which allocations are growing.
UMDH can compare two different log files and display the change in their respective allocation sizes. You can use the greater-than symbol (>) to redirect the results into a third text file. You may also want to include the -d option, which converts the byte and allocation counts from hexadecimal to decimal. For example, to compare Log1.txt and Log2.txt, saving the results of the comparison to the file LogCompare.txt, use the following command:
Open the LogCompare.txt file. Its contents resemble the following:
For each call stack (labeled «BackTrace») in the UMDH log files, there is a comparison made between the two log files. In this example, the first log file (Log1.txt) recorded 0x9DF0 bytes allocated for BackTrace00B53, while the second log file recorded 0xF110 bytes, which means that there were 0x5320 additional bytes allocated between the time the two logs were captured. The bytes came from the call stack identified by BackTrace00B53.
To determine what is in that backtrace, open one of the original log files (for example, Log2.txt) and search for «BackTrace00B53.» The results are similar to this data:
This UMDH output shows that there were 0x5320 (decimal 21280) total bytes allocated from the call stack. These bytes were allocated from 0x14 (decimal 20) separate allocations of 0x428 (decimal 1064) bytes each.
The call stack is given an identifier of «BackTrace00B53,» and the calls in this stack are displayed. In reviewing the call stack, you see that the DisplayMyGraphics routine is allocating memory through the new operator, which calls the routine malloc, which uses the Visual C++ run-time library to obtain memory from the heap.
Determine which of these calls is the last one to explicitly appear in your source code. In this case, it is probably the new operator because the call to malloc occurred as part of the implementation of new rather than as a separate allocation. So this instance of the new operator in the DisplayMyGraphics routine is repeatedly allocating memory that is not being freed.
