参考文献:

1、http://blog.csdn.net/wcjy07220114/article/details/6962140

2、http://blog.csdn.net/chenyujing1234/article/details/11918987

3、http://www.cnblogs.com/yujiang2011/archive/2011/09/14/2176771.html

内存泄露分析

Visual Leak Detector for Visual C++ 2008/2010/2012/2013

内存泄漏工具(VLD)使用说明

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 click Apply.

    Or, equivalently, use the following GFlags command line, where ImageName is the process name (including the file name extension):

    Copy
    gflags /i ImageName +ust   
  • 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 or Itanium-based 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 clickApply.
    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 Flagstab 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:

Copy
set _NT_SYMBOL_PATH=c:\mysymbols;srv*c:\mycache*http://msdl.microsoft.com/download/symbols   

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.

On Windows 2000, in addition to setting OANOCACHE equal to 1, you must also install the hotfix available with KB
139071
. This hotfix is not needed on Windows XP and later versions of Windows.

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:

  1. Determine the process
    ID (PID)
     for the process you want to investigate.

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

    Copy
    umdh -p:124 -f:log1.txt   
  3. 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.

  4. 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 andLog2.txt, saving
    the results of the comparison to the file LogCompare.txt, use the following command:

    Copy
    umdh log1.txt log2.txt > logcompare.txt   
  5. Open the LogCompare.txt file. Its contents resemble the following:
    Copy
    + 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.

  6. 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:

    Copy
    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.

Send
comments about this topic to Microsoft

Build date: 12/1/2010

Umdh 是 Debugging Tools for Windows 里面的一个工具, 可以从下面链接下载http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
UMDH主要通过分析比较进程的Heap Stack trace信息来发现内存泄露的。

使用 UMDH 之前

1.设置_NT_SYMBOL_PATH环境变量,例如用命令行:set _NT_SYMBOL_PATH=C:\WINDOWS\Symbols。把你自己程序的Symbol files (.pdb) 文件放在跟你执行文件同一目录,或者加到_NT_SYMBOL_PATH环境变量里面。

2.设置gflags,通过命令gflags -i notepad.exe +ust, gflags也是Debugging Tools for Windows里面一个工具程序。也可以敲入Gflags命令,然后通过界面配置,进入界面后选择Image File, 在Image栏写入执行文件的名字,不需要全路径,例如只要输入notepad.exe, 然后按 TAB键,选中Create user mode stack trace database选项,确认。

转储以捕获堆

1.获得要分析的程序的进程号,比如你的进程号是1234,在命令行输入umdh -p:1234 -f: 1234old.log,得到1234old.log文件。

2.继续运行你的程序,或者说进行你怀疑会有内存泄漏的操作。

3.间隔一段时间后,输入命令umdh -p:1234 -f: 1234new.log。

4.然后运行Umdh -d 1234old.log 1234new.log > cmp1234.txt。

分析比较结果

1.cmp1234.txt就是两个时刻的Heap Stack Trace的差别,它类似于以下信息:

+ 5320 ( f110 - 9df0) 3a allocs BackTrace00053 

Total increase == 5320

2.接下来就是查找对应的BackTrace,例如上面的意思是说在BackTrace00053处内存增加了5320个字节,在BackTrace00053你将能找到内存泄露处对应的CallStack。

3.接下来看一下BackTrace00053究竟有什么东西,找到第二个日志文件,在这里就是1234new.log,搜索BackTrace00053, 如果你的Symbol File Path配置正确的话,在BackTrace00053你会发现有类似如下信息:

00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053 

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!LeakyFunc+0x0000001E 

MyApp!main+0x0000002C 

MyApp!mainCRTStartup+0x000000FC 

KERNEL32!BaseProcessStart+0x0000003D

      上面就是分配那块内存的Stack trace信息,在这里我们看到实在MyApp!LeakyFunc函数里面有个new操作。以上信息说明,在两个日志时间间隔里面,MyApp!LeakyFunc分配了新的内存,但是还没有释放。

     下面链接是有关UMDH的视频:http://wm.microsoft.com/ms/mcsp/servicedesk/080702.wmv.

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/phiger/archive/2007/12/12/1932141.aspx

使用UMDH查找内存泄露的更多相关文章

  1. Android中如何查找内存泄露

    1.首先确定是否有内存泄露及哪个程序造成. 1.1.内存泄露已弹出out of memory对话框的情况. 这种情况很简单,直接看对话框就知道是哪个应用的问题了.然后再分析该应用是否是因为内存泄露造成 ...

  2. 用poolmon来查找内存泄露

    用poolmon来查找内存泄露 poolmon C:\WinDDK\7600.16385.1\tools\Other\i386\poolmon.exegflags     C:\WinDDK\7600 ...

  3. 【转】使用UMDH查找内存泄漏

    转载出处:http://blog.csdn.net/phiger/article/details/1932141 Umdh 是 Debugging Tools for Windows 里面的一个工具, ...

  4. Windows下使用Gflags和UMDH查找内存泄漏

    GFlags和UMDH与WinDbg一样,都是Debugging Tools for Windows里的工具. 1.设置符号路径 去微软官网下载对应的操作系统的符号安装文件,并安装到某个目录,如C:\ ...

  5. leaks工具查找内存泄露

    作为一名iOS开发攻城狮,在苹果没有出ARC(自动内存管理机制)时,我们几乎有一半的开发时间都耗费在这么管理内存上.后来苹果很人性的出了ARC,虽然在很大程度上,帮助我们开发者节省了精力和时间.但是我 ...

  6. Glib程序使用Valgrind查找内存泄露

    G_DEBUG=gc-friendly G_SLICE=always-malloc     //glib有缓存  故需使用 上述两条设置环境变量 G_SLICE和G_DEBUG排除由内存分配机制带来的 ...

  7. Valgrind查找内存泄露利器

    Valgrind是一个GPL的软件,用于Linux(For x86, amd64 and ppc32)程序的内存调试和代码剖析.你可以在它的环境中运行你的程序来监视内存的使用情况,比如C 语言中的ma ...

  8. 用Eclipse Memory Analyzer查找内存泄露

    写在CSDN里面了 http://blog.csdn.net/dayulxl/article/details/78164301

  9. Instruments指南:如何调试内存泄露

    Instruments指南:如何调试内存泄露 开篇 现在,你应该使用的ARC,而不是原来我们使用的MRC或者其他.但是我们在使用ARC的时候也会出现内存泄露的情况. 幸运的是,苹果为我们提供了Inst ...

随机推荐

  1. 【Linux高级驱动】rtc驱动开发

    [1.分层思想] 1.1 rtc-dev.c   //设备接口层,功能:给用户提供接口 subsys_initcall(rtc_init);   , RTC_DEV_MAX, "rtc&qu ...

  2. c++默认参数函数注意事项

    再有默认参数的函数中,一般我们都把默认参数放在声明处而不是定义处. 如果声明和定义都有默认参数,编译器将会报错. 调用含有默认实参的函数时,我们可以包含参数,也可以省略. 有默认参数的函数,我们可以不 ...

  3. Docker入门学习总结

    1. 什么是Docker Docker是一种虚拟化技术,其在容器的基础上进一步封装了文件系统.网络互联.进程隔离等等,从而极大地简化了容器的创建和维护.Docker使用 Google 公司推出的 Go ...

  4. azkaban在centos下的部署安装

    azkaban 是一个用Java开发的开源调度工具workflow. 下面介绍具体安装过程,我这里使用的版本是3.43.0,使用的是solo运行模式. 编译 git clone https://git ...

  5. mysql搭建主从

    1.主从服务器分别作以下操作: 1.1.版本一致 1.2.初始化表,并在后台启动mysql 1.3.修改root的密码 数据库内容也要保证数据一致 //否则报错, Slave_SQL_Running: ...

  6. python初级 1 数据类型和变量

    一.整数(int) 例:  0 1 2 3 -1 -2 –3 In [31]: print(type(0)) <class 'int'> In [32]: print(type(1)) & ...

  7. WPF之依赖属性和附加属性

     参考资料: 一站式WPF--依赖属性(DependencyProperty)一 一站式WPF--依赖属性(DependencyProperty)二         依赖属性之我见: 这两篇文章介绍的 ...

  8. juypter安装使用

    安装: pip install jupyter 启动: jupyter notebook 创建文件 这里的python文件格式是ipynb,可以在download as 中选择要保存的格式. 执行: ...

  9. Redis 自定义 RedisAppender 插件, 实现日志缓冲队列,集中日志输出.

    因为某些异步日志设置了即使队列满了,也不可丢弃,在并发高的时候,导致请求方法同步执行,响应变慢. 编写这个玩意,除了集中日志输出以外,还希望在高并发的时间点有缓冲作用. 之前用Kafka实现了一次入队 ...

  10. 基于VS Code创建Java command-line app

    由于国产化的原因,公司由.NET转向了Java阵营,之后会不定期分享一些技术转型中的体会.所谓Java的command-line app其实就是.NET项目中的Console Application, ...