umdh windbg分析内存泄露

最新推荐文章于 2024-08-16 14:40:57 发布

whatday

最新推荐文章于 2024-08-16 14:40:57 发布

阅读量4.3k

点赞数 2

A.利用工具umdh（user-mode dump heap）分析

1设置gflags.exe标志

Gflags标志设置好后，开启cmd

键入要定位内存泄露的程序gflags.exe /i memroyleak.exe +ust

如图成功后，开启memoryleak.exe程序

2利用umdh创建heap快照

命令格式：umdh -pn:memoryleak.exe -f:snap1.log

程序运行一段时间后或者程序占用内存增加时，然后再次创建heap快照，命令行无差别，snap1.log改为snap2.log或者其他。

设置好程序的符号路径，如下图

设置好后可以开始分析heap前后两个快照的差异

分析差异命令:umdh -d snap1.log snap2.log -f:result.txt

生成的result.txt文件在命令行同目录下这里是 D:\WinDDK\7600.16385.0\Debuggers

分析完成后查看结果result.txt

红色为umdh定位出来的泄露点，我们在查看源代码

这样我们就可以修改代码中内存泄露的地方了。

内存泄露实例分析：

两次快照差异文件实例大致如下：

// Debug library initialized ...
D0000-111FFF DBGHELP: Server - private symbols & lines 
        C:\FunctionServer\Release\Server.pdb
77E70000-77FEFFFF DBGHELP: ntdll - public symbols  
        c:\mysymbol\wntdll.pdb\B081677DFC724CC4AC53992627BEEA242\wntdll.pdb
。。。。
等等符号加载信息

紧接着是内存泄露信息格式说明 
//                                                                         
// Each log entry has the following syntax:                                 
//                                                                          
// + BYTES_DELTA (NEW_BYTES - OLD_BYTES) NEW_COUNT allocs BackTrace TRACEID 
// + COUNT_DELTA (NEW_COUNT - OLD_COUNT) BackTrace TRACEID allocations      
//     ... stack trace ...                                                  
//                                                                          
// where:                                                                   
//                                                                          
//     BYTES_DELTA - increase in bytes between before and after log         
//     NEW_BYTES - bytes in after log                                       
//     OLD_BYTES - bytes in before log                                      
//     COUNT_DELTA - increase in allocations between before and after log   
//     NEW_COUNT - number of allocations in after log                       
//     OLD_COUNT - number of allocations in before log                      
//     TRACEID - decimal index of the stack trace in the trace database     
//         (can be used to search for allocation instances in the original  
//         UMDH logs).                                                      
//                        

接着是具体的内存泄露信息

+    47e0 ( 237238 - 232a58)    1f9 allocs	BackTrace8E5CFAC
+       4 (   1f9 -   1f5)	BackTrace8E5CFAC	allocations


	ntdll!RtlAllocateHeap+274
	Server!malloc+49 (f:\dd\vctools\crt\crtw32\heap\malloc.c, 92)
	Server!operator new+1D (f:\dd\vctools\crt\crtw32\heap\new.cpp, 59)
	Server!CUi::AddItemText+129 (d:\projects\testtest\common\uilibf, 611)
	Server!CUi::AddItemInt+57 (d:\projects\testtest\common\uilibf, 709)
	Server!CMainWin::AddOneFunction+1FE (d:\projects\testtest\server\server\, 361)
	Server!CTest::FunctionPcInfo+3F9 (d:\projects\testtest\server\server\, 306)
	Server!CTest::FunctionReadDispatch+15D (d:\projects\testtest\server\server\, 105)
	Server!CTest::FunctionReadCallback+14 (d:\projects\testtest\server\server\, 76)
	Server!CWSAAsync::ReadProc+10F (d:\projects\testtest\common\wsaasyncselect, 1336)
	Server!CWSAAsync::ReadProcMiddle+12 (d:\projects\testtest\common\wsaasyncselect, 1296)
	Server!CWindowsPool::ReadThreadPoolCallback+25 (d:\projects\testtest\common\wsaasyncselect, 332)
	ntdll!TppWorkpExecuteCallback+10F
	ntdll!TppWorkerThread+572
	kernel32!BaseThreadInitThunk+E
	ntdll!__RtlUserThreadStart+70
	ntdll!_RtlUserThreadStart+1B

。。。。
等等其他内存泄露块信息

根据格式的说明可得到此泄露信息如下：

第一行：+ 47e0 ( 237238 - 232a58) 1f9 allocs BackTrace8E5CFAC

BackTrace8E5CFAC是这个内存块的标记 237238是生成日志文件2时该内存块的大小 232a58是生成日志文件1该内存块的大小差值47e0 是内存泄露的字节数 1f9是分配内存的次数（其中47e0 个人理解为申请内存未释放的字节数，因为有可能是释放的时间未到就生成日志文件2 造成只有申请内存没有释放的情况所以被判定为内存泄露关于这点只是个人意见不一定正确）。

第二行：+ 4 ( 1f9 - 1f5) BackTrace8E5CFAC allocations

BackTrace8E5CFAC是内存块标记和第一行一样，1f9是生成日志文件2时该内存分配的次数， 1f5是生成日志文件1时该内存分配的次数差值4是这次该内存块分配的次数。

其他行：是函数调用堆栈，通过分析自己的程序发现，第三行的 Server!CUi::AddItemText+129 (d:\projects\testtest\common\uilibf, 611) 也是内存泄露所在，对应源代码是：pItemLabel = new CLabelUI; 这样基本上就定位到问题所在了

验证一下观点：每一次分配的大小是47e0 /4=4600(十进制)，程序中代码验证了sizeof(CLabelUI)也等于4600，看来从日志1 到日志2 过程中这个地方new了4次但是在日志2时还未释放这些内存所以造成内存比较时会定位处该块内存的泄露，至于是否真泄露还是要看程序逻辑，但是既然已定位到该代码还是要仔细分析一下看看是逻辑问题还是真忘了释放内存。