Note The video is coded with ACELP® codec, you need install the free ACELP® codec available at http://www.acelp.net/acelp_eval.php
Note Because the malloc function in the C run-time (CRT) module uses the frame pointer omission (FPO) on the original release version of Windows Server 2003, you may not see the complete stack information of the malloc function by using the UMDH tool. This issue is fixed in the CRT module of Windows Server 2003 Service Pack 1 (SP1). Therefore, you can see the complete stack information of the malloc function in Windows Server 2003 SP1.
Before You Use UMDHIf you think that you are experiencing a memory leak, be aware that memory leaks may not be what they appear to be. You may discover that a memory leak is not a true memory leak, but is 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) because it retrieves data and writes caches. The cache permits the Jet engine to get fast read-ahead and write-ahead buffering.
To determine whether or not a process is experiencing memory leaks, use Windows Performance Monitor (Perfmon.exe) and monitor Private Bytes under the Process category for your application. Private bytes is the total memory that 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 that the process uses. An application can leak virtual memory, but may not see a difference in the private bytes that are allocated. If you do not see memory increase when you monitor private bytes, but you suspect that you are still running out of memory, monitor virtual bytes to see if you are using up virtual memory. For additional information about detecting memory leaks and the overview of Windows Performance Monitor (Perfmon.exe), visit the following Microsoft Web site:
If you determine that you see a memory leak, before you use UMDH, follow these steps:
- Install the UMDH utility.
- Set the System PATH environment variable to include the folder where you installed UMDH.
- Set the _NT_SYMBOL_PATH environment variable to the Microsoft symbol server path so that UMDH can locate debug symbol files.
Before you use UMDH, you must install the correct debug symbols for the components of your application and your operating system. Use the Microsoft Symbol Server to acquire debug symbols for Microsoft components.
For more information about the Microsoft Symbol Server, click the following article number to view the article in the Microsoft Knowledge Base:
UMDH tries to find the symbol files by using the _NT_SYMBOL_PATH environment variable. The command to set the path from a command prompt might look similar to the following:
After you complete these steps, you are ready to use the UMDH utility.
Capturing Heap Dumps with UMDHUMDH is a utility that dumps information about the heap allocations of a process. This information includes the callstack for each allocation, the number of allocations that are made through that callstack, and the number of bytes that are consumed through that callstack. For example:
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
To produce a dump file of the heap allocations, you must use the Gflags.exe utility, which is also included with the Debugging Tools for Windows products, to let the operating system know that you want the kernel to track the allocations.
Assume that you want to dump the heap(s) contents for Notepad.exe. First you must enable stack trace acquisition for the application that you want to test. By default, this feature is not enabled. The command to enable this feature is as follows:
When you set the image flags through Gflags.exe, and you set up the debug symbols, you are ready to start Notepad (the application that is using UMDH). After the program is started, you must determine the Process ID (PID) of the Notepad process that was just started. The command for this is as follows:
Use Umdh.exe to Compare UMDH LogsWhile 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 dump files. The Umdh.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 is in that backtrace. If you open the second log file and search for BackTrace00053, you may find something that similar to the following:
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
Enabling Stack TracesThe most important information in UMDH logs is the stack traces of the heap allocations. You can analyze them to verify if a process leaks heap memory. By default, these stack traces are not acquired. You can enable this feature per-process or system-wide. Use the following command to enable stack tracing system-wide:
Use the following commands to verify what settings have been set system-wide or for a specific process: System-wide:
System Registry, and then type a new depth in the Max. Stack Trace Capture Depth edit control. Click Apply, and then restart the computer.
IMPORTANT: If you are using Windows NT 4.0 Service Pack 6, you must use Umdh_nt4.exe, instead of Umdh.exe, and you must use the gflags -r command to set system-wide stack tracing. Make sure that you restart your computer. Umdh_nt4 stack tracing does not work on a per process basis on Windows NT version 4. It must be set for the whole system.
Debug SymbolsOne of the most important steps to using UMDH is to make sure that you have good symbol files (.dbg or .pdb file) to get a good stack trace. At a minimum, you need the Kernel32.dbg and Ntdll.dbg symbol files. You can acquire additional debugging symbols that you may need as you find out more about which components leak memory.
For more information about how to get debug symbol files for Microsoft components, click the following article number to view the article in the Microsoft Knowledge Base:
For additional information about how to use the Microsoft Symbol Server and how to obtain Windows symbol packages, visit the following Microsoft Web site:
Follow these steps to set the _NT_SYMBOL_PATH environment variable:
- In Control Panel, double-click System.
- Click the Advanced tab, and then click Environmental Variables.
NOTE: Also include the path to the PDBs for the components of your application. For example, set the path for _NT_SYMBOL_PATH to the following:
Invoking UMDHThe 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 that is obtained by UMDH contains an enumeration of heap consumers that are sorted by allocation count. If, for debugging purposes, you also need a dump file of all of the allocated blocks with their corresponding stack traces, the -d option can be used:
If the log contains too much information, it can be limited only to big users who have the allocation count above a certain threshold. Use the following command:
Another useful UMDH option is the -l option. This causes file and line numbers to be printed in the callstack whenever possible.
UMDH Output ExplainedIf you redirected the log to a file (umdh -p:PID -f:umdh.log), the contents are similar to the following, which was obtained from a running Notepad process:
UMDH: Logtime 2000-06-28 10:54 - Machine=MYMachine - PID=704
*********** Heap 00270000 Information ********************
Number Of Entries: 87
Number Of Tags: <unknown>
Bytes Allocated: 00008DF0
Bytes Committed: 0000A000
Total FreeSpace: 00001210
Number of Virtual Address chunks used: 1
Address Space Used: <unknown>
Entry Overhead: 8
*********** Heap 00270000 Hogs ********************
000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00031
000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00034
Problems That You Can Experience When You Use UMDHThe most common errors when you use UMDH occur because stack tracing is not enabled. Also, incorrect symbols for Ntdll.dll prevent UMDH from running. For the other symbols files, UMDH runs but the log file contains 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 try to run UMDH for a process that does not have stack tracing enabled:
Call UMDH from Visual BasicIt may be useful sometimes to dump a number of logs over time because the leak may not be very noticeable at first. For example, if you suspect that your Active Server Pages (ASP) Web 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.
The following is some Visual Basic code that invokes UMDH and creates a log file that is based on the current time:
Private Declare Function GetCurrentProcessId Lib "kernel32" () As Long
Public Function GetProcessID()
GetProcessID = GetCurrentProcessId()
Dim strTime As String
Dim sProcID As String
sProcID = GetProcessID()
strTime = "MYLOG_" & Format(Now(), "hhmm")
Shell ("C:\UMDH\umdh -p:" & sProcID & " -f:d:\logs\" & strTime & ".txt")
Use UMDH with Windows NT 4.0 Service Pack 6a (SP6a)The UMDH utility that is included with the Debugging Tools for Windows products does not work on Windows NT 4.0. A self-extracting executable (Umdhnt4tools.exe) is included with this article and contains the following tools to be used with NT 4.0:
- Umdh_nt4.exe and Dbghelp.dll
This is the Windows NT 4.0 SP6 version of the UMDH utility.
This utility is used to compare two UMDH dumps to determine where a possible memory leak occurrs.
Release Date: August 28, 2002
For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
Put Umdh_nt4.exe and Dbghelp.dll in a folder, and then put them first in your PATH environment variable. Use Umdh_nt4.exe instead of UMDH.
On a computer that is running Windows NT 4.0, you must use Gflags.exe to set system-wide stack tracing. For example:
UMDH_NT4 is unlike UMDH in that it does not compare log files. For example, you cannot do the following: