如何使用umdh.exe检查Windows上的内存泄漏

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.

let's use testApp.exe for demo.

Testapp

1. Fist compile your testApp on your local machine, the symbol file need to use later.

2. Use the following GFlags command line to configure your system properly. 

   "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\gflags.exe" /i TestApp.exe +ust

   
   Use this command to clear the GFlag settings once you are done. For more information, see GFlags Commands.

   "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\gflags.exe" /i TestApp.exe -ust

3. Set symbol correctly, please change the path to where your test app belong 

   set _NT_SYMBOL_PATH=srv*C:\code\testapp\*http://shanghai-nfs.cisco.com/symstore/

4. start testAPP and make some operation, like making a call.

5. Get the first log of memory allocation, change 124 to the process number of your testApp
    

   "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\umdh.exe" -p:124 -f:log1.txt

6. Get the 2nd log of memory allocation, change 124 to the process number of your testApp

   "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\umdh.exe" -p:124 -f:log2.txt

7. Get the mem allocation info by compare the 2 log files

   "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\umdh.exe" log1.txt log2.txt > logcompare.txt

8. Open file logcomare.txt, check all the memory allocation info. below is a example, the + means how many memory added between log1 and log2 for this stack, below that is the backstack.

   + 2a3044 ( 2a3044 - 0) 1 allocs BackTraceE32F1C8
   + 1 ( 1 - 0) BackTraceE32F1C8 allocations

   ntdll!RtlWalkHeap+194
   ntdll!RtlCaptureStackContext+11301
   ntdll!RtlAllocateHeap+3E
   ucrtbase!malloc_base+26
   cpve!ippMalloc+1A

    

    

9. Here is another example comes from internet.

   1. Open the LogCompare.txt file. Its contents resemble the following:
      text

      + 5320 ( f110 - 9df0) 3a allocs BackTrace00B53 
      Total increase == 5320 
      

      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.

   2. 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:
      text

      00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00B53
      ntdll!RtlDebugAllocateHeap+0x000000FD
      ntdll!RtlAllocateHeapSlowly+0x0000005A
      ntdll!RtlAllocateHeap+0x00000808
      MyApp!_heap_alloc_base+0x00000069
      MyApp!_heap_alloc_dbg+0x000001A2
      MyApp!_nh_malloc_dbg+0x00000023
      MyApp!_nh_malloc+0x00000016
      MyApp!operator new+0x0000000E
      MyApp!DisplayMyGraphics+0x0000001E
      MyApp!main+0x0000002C
      MyApp!mainCRTStartup+0x000000FC
      KERNEL32!BaseProcessStart+0x0000003D 
      

      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.

10. Here is how to use it for Jabber windows

    1. Gflag CiscoJabber.exe
    "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\gflags.exe" /i CiscoJabber.exe +ust
    
    2. Set symbol correctly
    set _NT_SYMBOL_PATH=srv*C:\Users\regqin\Work\symbols*http://shanghai-nfs.cisco.com/symstore/
    3. umdh file1
    "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\umdh.exe" -p:124 -f:log1.txt
    4. umdh file2
    5. umdh diff - load symbol at diff
    "c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\umdh.exe" log1.txt log2.txt > logcompare.txt

    
    
    Refer

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/using-umdh-to-find-a-user-mode-memory-leak

    https://blog.csdn.net/lluozh2015/article/details/73611079

    http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/PSS/Tools/Developer%20Support%20Tools/LeakDiag/

    https://blog.csdn.net/zjc156m/article/details/54600722