UMDH在内存泄露分析中的应用

今天开会无聊，又想起了之前在软件测试过程中umdh的应用，于是想写个总结，由于忘记了一些细节，于是跑到微软的官方上找到了经典文章《Umdhtools.exe: How to use Umdh.exe to find memory leaks》，又读了一遍，非常经典，在搜索中恰好发现phiger在其csdn博客中已经写过了有关umdh总结的文章，我这里就摘录几段，不再重写了，个别地方加点自己的经验：

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环境变量里面。（我注：建议大家从微软官方网站上http://support.microsoft.com/kb/311503/下载符号文件，普通系统一般都数据不全，没有完成的符号表，在后面显示的内存调用栈中会出现大量读不懂的符号…）

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选项，确认。（我接着注：通过界面设置gflags，偶没用过;在使用完umdh之后，要释放gflags对应用的控制，否则该应用会一直被注入监控hook代码，可能导致性能下降…）

转储以捕获堆

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 0×14 allocations (@ 0×00000428) by: BackTrace00053

ntdll!RtlDebugAllocateHeap+0×000000FD

ntdll!RtlAllocateHeapSlowly+0×0000005A

ntdll!RtlAllocateHeap+0×00000808

MyApp!_heap_alloc_base+0×00000069

MyApp!_heap_alloc_dbg+0×000001A2

MyApp!_nh_malloc_dbg+0×00000023

MyApp!_nh_malloc+0×00000016

MyApp!operator new+0×0000000E

MyApp!LeakyFunc+0×0000001E

MyApp!main+0×0000002C

MyApp!mainCRTStartup+0×000000FC

KERNEL32!BaseProcessStart+0×0000003D

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

 

好了，感谢phiger的分享和我的注解，哈哈，不过有一点我深有体会，例子毕竟是例子，只是个入门，在我的实际内存调试过程中，从来没有上面如此简单明了的函数调用者，特别是在Java应用程通过JVM调用C、c++等原生代码，那分析起来可真是费劲，下次总结一下。