使用Windbg定位内存泄露

在网上看了两篇文章，整理一下，大致内容如下：

场景一：运行Debug版本程序，用Windbg attach 上去，等程序退出时，基于内存泄露报告，定位内存泄露的位置。

首先使用windbg工具gflags.exe设置内存启动跟踪内存泄露进程的user stack启动方法就是运行下面指令gflags.exe /i test.exe +ust 需要通过gflags.exe工具打开开关，才能调试内存泄露！等价于HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options，命令“gflags.exe /i test.exe +ust”实际上就是在该路径下创建一个子键“test.exe”并创建一个名为GlobalFlag内容为0x00001000的REG_DWORD值。使用windbg加载test.exe,运行关闭时windbg中会提示内存泄露normal block at 0x026A5F98, 4000 bytes long.Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete.可以发现地址0x026A5F98就是内存泄漏的地址泄漏4000个字节通过!heap命令对该地址进行分析可以发现具体的调用堆栈0:000> !heap -p -a 0x026A5F98 address 026a5f98 found in_HEAP @ 14f0000HEAP_ENTRY Size Prev Flags UserPtr UserSize - state026a5f60 01fc 0000 [00] 026a5f78 00fc4 - (busy)77a1b234 ntdll!RtlAllocateHeap+0x00000274584d7743 MSVCR100D!_heap_alloc_base+0x00000053584e5d8c MSVCR100D!_heap_alloc_dbg_impl+0x000001fc584e5b2f MSVCR100D!_nh_malloc_dbg_impl+0x0000001f584e5adc MSVCR100D!_nh_malloc_dbg+0x0000002c584e5a91 MSVCR100D!_malloc_dbg+0x0000002158694dd6 mfc100ud!operator new+0x0000002658694e6a mfc100ud!operator new[]+0x0000001a58694768 mfc100ud!operator new[]+0x00000018*** WARNING: Unable to verify checksum for SendMsgEx.exe2a3c25 SendMsgEx!CSendMsgExDlg::Thread1Proc+0x00000055767c1174 kernel32!BaseThreadInitThunk+0x0000000e779fb3f5 ntdll!__RtlUserThreadStart+0x00000070779fb3c8 ntdll!_RtlUserThreadStart+0x0000001b可以发现内存泄漏的地址在CSendMsgExDlg::Thread1Proc这个地址里面调用了new[]导致内存泄漏DWORD WINAPI CSendMsgExDlg::Thread1Proc(__in LPVOID lpParameter){INT *pVal = new INT[1000];//..................}

结论：场景一适用于Debug版本程序，而且需要在程序退出时才能定位泄露。

场景二：程序运行一段时间，用Windbg attach上去，查看堆内存使用情况；detach 让程序继续运行；过一段时间再 attach，查看堆内存使用情况，与第一次对比，找到内存明显增长的堆。

我们开发的系统需要在客户的电脑上持续运行，可是客户报告在运行几天后，程序会占用越来越多的内存，最后会产生下面的两个错误使之不能继续：1. The application has no enough resource to display2. The application crash with a log like "memory allocation failed".怎么办？上windbg。准备工作Configure the symbol file path to the Microsoft symbol server “SRV*c:\symbols*/download/symbols”,也可以一个环境变量_NT_SYMBOL_PATH到系统路径下，省得每次配置它Add your program EXE/DLL PDB (program database) path to the symbol file path.（设置PDB路径）Configure the Operating System's flag to enable user stack trace for the process which has memory leaks.Gflags.exe -i excel.exe +ust（和场景一一样，设置gflags.exe启动调试）第一次记录让系统运行一段时间，用windbg attach 它的进程，运行下面的命令0:025> !heap -sLFH Key : 0xeaafe2e0HeapFlags Reserv Commit Virt Free List UCR Virt Lock Fast(k)(k) (k)(k) lengthblocks cont. heap-----------------------------------------------------------------------------00160000 00000002 32768 28204 28492 1460 239 19 0f LFH00260000 00001002644040311 00 L 00270000 000080006412121011 00004e0000 000000026488001 00 L 00030000 00001002 10887272921 00 L 00480000 00001002 7232 3444 34443652 00 L 004c0000 00001002 1088 252 252511 00 L 004d0000 00001002641212411 00 L 01060000 00001002641616221 00 L 01120000 00000002 10242424001 00 L 010b0000 000010022563232001 00 L 01660000 00001002 3136 2796 2828 377 137 00 L External fragmentation 13 % (13 free blocks)01680000 00001002643232301 00 L 01690000 000410022561212001 00 L 01790000 00001003256 104 1166093 0 bad017d0000 0000100325644211 0 bad01810000 0000100325644211 0 bad030d0000 0000100325644211 0 bad03110000 0000100325644211 0 bad01850000 0000100264211 00 L 03560000 00001002 1280 664 7762274 00 L 04780000 0000100325688211 0 bad047c0000 0000100325644211 0 bad04800000 0000100325644211 0 bad04840000 0000100325644211 0 bad04880000 0000100325644211 0 bad048e0000 000010022561616411 00 L 04920000 00001002 1088 1012 1024 11173 00 L 04930000 00001002 3136 940 940 15392 08d L 04ce0000 00001002641616001 00 L 04cf0000 00001002 1088 192 192621 00 L 05850000 00001002642828111 00 L 05de0000 00001002641212311 00 L

第二次记录Detatch the windbg from the excel process（windbg 和应用程序detach, 如果不detach，程序被中断到调试状态，无法运行）让它再运行一段时间，用windbg attach 它的进程，运行下面的命令0:025> !heap -sLFH Key : 0xeaafe2e0HeapFlags Reserv Commit Virt Free List UCR Virt Lock Fast(k)(k) (k)(k) lengthblocks cont. heap-----------------------------------------------------------------------------00160000 00000002 32768 28204 28492 1460 239 19 0f LFH00260000 00001002644040311 00 L 00270000 000080006412121011 00004e0000 000000026488001 00 L 00030000 00001002 10887272921 00 L 00480000 00001002 7232 3444 34443652 00 L 004c0000 00001002 1088 252 252511 00 L 004d0000 00001002641212411 00 L 01060000 00001002641616221 00 L 01120000 00000002 10242424001 00 L 010b0000 000010022563232001 00 L 01660000 00001002 3136 2796 2828 377 137 00 L External fragmentation 13 % (13 free blocks)01680000 00001002643232301 00 L 01690000 000410022561212001 00 L 01790000 00001003256 104 1166093 0 bad017d0000 0000100325644211 0 bad01810000 0000100325644211 0 bad030d0000 0000100325644211 0 bad03110000 0000100325644211 0 bad01850000 0000100264211 00 L 03560000 00001002 1280 664 7762274 00 L 04780000 0000100325688211 0 bad047c0000 0000100325644211 0 bad04800000 0000100325644211 0 bad04840000 0000100325644211 0 bad04880000 0000100325644211 0 bad048e0000 000010022561616411 00 L 04920000 00001002 1088 3012 3024 51173 00 L 04930000 00001002 3136 940 940 15392 08d L 04ce0000 00001002641616001 00 L 04cf0000 00001002 1088 192 192621 00 L 05850000 00001002642828111 00 L 05de0000 00001002641212311 00 L 比较第一次和第二次，发现在0x04920000上的内存有明显的增长执行!heap -stat -h 04920000 去观察这段内存的详细情况0:025> !heap -stat -h 04920000heap @ 04920000group-by: TOTSIZE max-display: 20size#blockstotal( %) (percent of total busy bytes)4 21a29 - 82cd0 (94.77)d0 2a - 2220 (1.06)20 cd - 19a0 (0.79)90 2d - 1950 (0.78)be0 2 - 17c0 (0.74)e0 1b - 17a0 (0.73)f0 19 - 1770 (0.73)1f0 b - 1550 (0.66)200 a - 1400 (0.62)40 4f - 13c0 (0.61)240 7 - fc0 (0.49)bd0 1 - bd0 (0.37)发现这段内存主要是由size=4的内存构成的，而内存泄漏通常都是同一size的内存只分配，但没有释放引起的，所以，这个是值得高度怀疑的。执行!heap -flt s 4 去查进程中size=4的所有内存，_HEAP @ 04920000 03659ab8 0002 0002 [01] 03659ac0 00004 - (busy)03659ac8 0003 0002 [01] 03659ad0 00004 - (busy)0365e8e8 0002 0003 [01] 0365e8f0 00004 - (busy)0f2b9fe8 0003 0002 [11] 0f2b9ff0 00004 - (busy)0f2d9760 0003 0003 [01] 0f2d9768 00004 - (busy)0f2dcc20 0002 0003 [01] 0f2dcc28 00004 - (busy)0f2dcc50 0002 0002 [01] 0f2dcc58 00004 - (busy)0f2dd790 0002 0002 [01] 0f2dd798 00004 - (busy)0f2dd7c0 0002 0002 [01] 0f2dd7c8 00004 - (busy)0f2de260 0002 0002 [01] 0f2de268 00004 - (busy)0f2de290 0002 0002 [01] 0f2de298 00004 - (busy)0f2de2a0 0003 0002 [01] 0f2de2a8 00004 - (busy)0f2df740 0002 0003 [01] 0f2df748 00004 - (busy)0f2e0270 0002 0002 [01] 0f2e0278 00004 - (busy)0f2e02a0 0002 0002 [01] 0f2e02a8 00004 - (busy)0f2e02e0 0003 0002 [01] 0f2e02e8 00004 - (busy)0f2e1270 0002 0003 [01] 0f2e1278 00004 - (busy)0f2e1ce0 0002 0002 [01] 0f2e1ce8 00004 - (busy)0f2e1d10 0002 0002 [01] 0f2e1d18 00004 - (busy)0f2e27d0 0002 0002 [01] 0f2e27d8 00004 - (busy)0f2e2800 0002 0002 [01] 0f2e2808 00004 - (busy)0f2e2cc0 0002 0002 [01] 0f2e2cc8 00004 - (busy)0f2e2cf0 0002 0002 [01] 0f2e2cf8 00004 - (busy)0f2e3340 0003 0002 [01] 0f2e3348 00004 - (busy)0f2e3d20 0002 0003 [01] 0f2e3d28 00004 - (busy)0f2e4890 0002 0002 [01] 0f2e4898 00004 - (busy)0f2e48c0 0003 0002 [01] 0f2e48c8 00004 - (busy)然后执行!heap -p -a 0365e8f0 该内存分配时的堆栈。这样就可以定位到内存泄露的根源了。

结论：场景二比较试用于大部分情况，不需要是Debug版本，在现场调试，也不需要等待进程结束。