基于windbg的内存泄露分析

最新推荐文章于 2024-04-05 15:58:21 发布
最新推荐文章于 2024-04-05 15:58:21 发布
阅读量732 收藏
点赞数
分类专栏： C++ 文章标签： c++

可以使用windbg附带的工具gflags.exe可以对堆调用的过程进行跟踪，对内存泄露的排查有很大的帮助：在windbg程序目录下有个gflags.exe，运行后设置：



运行CMD.EXE，输入"D:\Debugging Tools for Windows (x86)\gflags.exe" /i test.exe +ust,如果设置成功则显示：


设置完成后通过堆分配的地址就能通过!heap命令查看进程分配堆时的调用栈，可以通过crt提供的_CrtDumpMemoryLeaks()函数来打印堆分配的地址，打印的内容如下，然后通过!heap -p -a 003bbab0命令即可查看调用栈。

如果没有使用CRT的函数打印堆地址，可以通过下面的方法筛选出堆地址：

让系统运行一段时间，用windbg attach 它的进程，运行下面的命令

0:025> !heap -s
LFH Key                   : 0xeaafe2e0
Heap     Flags   Reserv Commit Virt   Free List   UCR Virt Lock Fast
                    (k)     (k)    (k)     (k) length      blocks cont. heap
-----------------------------------------------------------------------------
00160000 00000002   32768 28204 28492   1460   239    19    0      f   LFH
00260000 00001002      64     40     40      3     1     1    0      0   L 
00270000 00008000      64     12     12     10     1     1    0      0     
004e0000 00000002      64      8      8      0     0     1    0      0   L 
00030000 00001002    1088     72     72      9     2     1    0      0   L 
00480000 00001002    7232   3444   3444     36     5     2    0      0   L 
004c0000 00001002    1088    252    252      5     1     1    0      0   L 
004d0000 00001002      64     12     12      4     1     1    0      0   L 
01060000 00001002      64     16     16      2     2     1    0      0   L 
01120000 00000002    1024     24     24      0     0     1    0      0   L 
010b0000 00001002     256     32     32      0     0     1    0      0   L 
01660000 00001002    3136   2796   2828    377    13     7    0      0   L 
    External fragmentation 13 % (13 free blocks)
01680000 00001002      64     32     32      3     0     1    0      0   L 
01690000 00041002     256     12     12      0     0     1    0      0   L 
01790000 00001003     256    104    116     60     9     3    0    bad     
017d0000 00001003     256      4      4      2     1     1    0    bad     
01810000 00001003     256      4      4      2     1     1    0    bad     
030d0000 00001003     256      4      4      2     1     1    0    bad     
03110000 00001003     256      4      4      2     1     1    0    bad     
01850000 00001002      64     20     20      2     1     1    0      0   L 
03560000 00001002    1280    664    776     22     7     4    0      0   L 
04780000 00001003     256      8      8      2     1     1    0    bad     
047c0000 00001003     256      4      4      2     1     1    0    bad     
04800000 00001003     256      4      4      2     1     1    0    bad     
04840000 00001003     256      4      4      2     1     1    0    bad     
04880000 00001003     256      4      4      2     1     1    0    bad     
048e0000 00001002     256     16     16      4     1     1    0      0   L 
04920000 00001002    1088   1012   1024    111     7     3    0      0   L 
04930000 00001002    3136    940    940    153     9     2    0     8d   L 
04ce0000 00001002      64     16     16      0     0     1    0      0   L 
04cf0000 00001002    1088    192    192      6     2     1    0      0   L 
05850000 00001002      64     28     28      1     1     1    0      0   L 
05de0000 00001002      64     12     12      3     1     1    0      0   L 

第二次记录

Detatch the windbg from the excel process

让它再运行一段时间，用windbg attach 它的进程，运行下面的命令

0:025> !heap -s
LFH Key                   : 0xeaafe2e0
Heap     Flags   Reserv Commit Virt   Free List   UCR Virt Lock Fast
                    (k)     (k)    (k)     (k) length      blocks cont. heap
-----------------------------------------------------------------------------
00160000 00000002   32768 28204 28492   1460   239    19    0      f   LFH
00260000 00001002      64     40     40      3     1     1    0      0   L 
00270000 00008000      64     12     12     10     1     1    0      0     
004e0000 00000002      64      8      8      0     0     1    0      0   L 
00030000 00001002    1088     72     72      9     2     1    0      0   L 
00480000 00001002    7232   3444   3444     36     5     2    0      0   L 
004c0000 00001002    1088    252    252      5     1     1    0      0   L 
004d0000 00001002      64     12     12      4     1     1    0      0   L 
01060000 00001002      64     16     16      2     2     1    0      0   L 
01120000 00000002    1024     24     24      0     0     1    0      0   L 
010b0000 00001002     256     32     32      0     0     1    0      0   L 
01660000 00001002    3136   2796   2828    377    13     7    0      0   L 
    External fragmentation 13 % (13 free blocks)
01680000 00001002      64     32     32      3     0     1    0      0   L 
01690000 00041002     256     12     12      0     0     1    0      0   L 
01790000 00001003     256    104    116     60     9     3    0    bad     
017d0000 00001003     256      4      4      2     1     1    0    bad     
01810000 00001003     256      4      4      2     1     1    0    bad     
030d0000 00001003     256      4      4      2     1     1    0    bad     
03110000 00001003     256      4      4      2     1     1    0    bad     
01850000 00001002      64     20     20      2     1     1    0      0   L 
03560000 00001002    1280    664    776     22     7     4    0      0   L 
04780000 00001003     256      8      8      2     1     1    0    bad     
047c0000 00001003     256      4      4      2     1     1    0    bad     
04800000 00001003     256      4      4      2     1     1    0    bad     
04840000 00001003     256      4      4      2     1     1    0    bad     
04880000 00001003     256      4      4      2     1     1    0    bad     
048e0000 00001002     256     16     16      4     1     1    0      0   L 
04920000 00001002    1088   3012   3024    511     7     3    0      0   L 
04930000 00001002    3136    940    940    153     9     2    0     8d   L 
04ce0000 00001002      64     16     16      0     0     1    0      0   L 
04cf0000 00001002    1088    192    192      6     2     1    0      0   L 
05850000 00001002      64     28     28      1     1     1    0      0   L 
05de0000 00001002      64     12     12      3     1     1    0      0   L 

比较第一次和第二次，发现在0x04920000上的内存有明显的增长

执行!heap -stat -h 04920000 去观察这段内存的详细情况

0:025> !heap -stat -h 04920000
heap @ 04920000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (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 该内存分配时的堆栈。 这样就可以定位到内存泄露的根源了。

lougd
关注
专栏目录
Windows和Linux下排查C++软件异常的常用调试器与内存检测工具详细介绍
dvlinker的技术专栏
08-17 2万+
本文详细介绍了Windows和Linux下排查C++软件异常的常用调试器与内存监测工具。
使用Process Explorer/Process Hacker和Windbg高效排查软件高CPU占用问题
热门推荐
dvlinker的技术专栏
11-02 1万+
通过在Windbg中查看变量的值去快速定位软件高CPU占用问题。
windbg内存泄漏问题
07-18
windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题
使用WINDBG检测内存泄漏
flyingleo1981的专栏
09-15 2708
使用WINDBG检测内存泄漏 一、使用命令！heap –s抓取快照   二、再次使用命令抓取快照 三、使用命令查看内存情况！heap –stat –h addr【!heap -stat -h 03570000】 四、使用命令分别查看较高的内存使用情况！heap –flt s 16c 五、使用命令查看调用堆栈即可以判断内存泄漏情况！heap –p –a 0bba8530
基于WinDbg的内存泄漏分析
blacet的专栏
11-07 3384
基于WinDbg的内存泄漏分析 在前面C++中基于Crt的内存泄漏检测一文中提到的方法已经可以解决我们的大部分内存泄露问题了，但是该方法是有前提的，那就是一定要有源代码，而且还只能是Debug版本调试模式下。实际上很多时候我们的程序会用到第三方没有源代码的模块，有些情况下我们甚至怀疑系统模块有内存泄露，但是有没有证据，我们该怎么办？ 这时我们就要依靠无所不能的WinDbg了。 WinDbg的!h...
windbg分析内存泄露
weixin_41481284的博客
01-05 441
安装完毕后进入cmd，切换到windbg安装目录 执行指令 cd C:\Program Files (x86)\Debugging Tools for Windows (x86) 1、设置PDB路径 运行命令set _NT_SYMBOL_PATH=C:\Windows\symbols;F:\3D\KS37.00.00000.01\Pdb\Release; 2、设置要跟踪堆栈的进程。 运行gflags -i F:\3D\KS37.00.00000.01\Pdb\Release\SCADAView.ex
Windows程序内存泄漏(Memory Leak)分析之Windbg
一个程序员的修炼之路
04-04 1923
之前本人写了一篇<<Windows程序内存泄漏(Memory Leak)分析之Windbg>>。这种方法有一定的局限性: 实践证明，当程序复杂，内存频繁的申请释放，通过UMDH对比的文件将会非常的大，并且很难直接看出内存泄露所在。 UMDH在收集信息的需要符号文件，不太适合于在客户的机器上进行操作。 调试方法很难一通百用，因为不同的工具都有自己的局限性，也有适合自己的分析场景，这个取决于碰到的问题。那么本文来介绍一种，使用Windbg分析内存泄露的方法。 样例代码 这个样例代码中
windbg查看内存泄漏
Leon的专栏
05-11 707
1：查看所有堆信息，找到一个很大的堆 0:243> !heap -s ************************************************************************************************************************ NT HEAP STATS BELOW ***************************************************************************
使用windbg检测内存泄漏
那时那刻
03-24 8191
使用windbg检测内存泄漏 缘起： 作为C++程序员，检测内存泄漏是非常痛苦的事情。尤其是看着程序的内存在一直增长，你却无能为力。此时，windbg可以用来检测内存泄漏。 配置windbg： 1.      配置symbol文件路径： “SRV*d:\symbols*http://msdl.microsoft.com/download/symbols”. 2.      增加测
[微软工具] 基于WinDbg的内存泄漏分析 - 比较复杂情况下调试
08-13
本篇将详细探讨如何利用微软提供的工具，尤其是WinDbg，来分析和定位复杂的内存泄漏问题。 WinDbg是一款强大的调试工具，由微软开发，适用于Windows操作系统。它提供了丰富的命令集和可视化界面，使得开发者能够...
使用Windbg定位内存泄露
suhuaiqiang_janlay的专栏
08-16 3889
在网上看了两篇文章，整理一下，大致内容如下：   场景一：运行Debug版本程序，用Windbg attach 上去，等程序退出时，基于内存泄露报告，定位内存泄露的位置。   首先使用windbg工具gflags.exe设置内存启动跟踪内存泄露进程的user stack 启动方法就是运行下面指令gflags.exe /i test.exe +ust 需要通过gflags.exe工具打
windows 64位 内存泄漏抓包工具windbg
01-10
vs平台c++代码下64位内存泄漏抓包工具，本人因业务开发需要，经常使用，分享给大家，希望大家喜欢。
WinDbg入门系列
06-22
WinDbg的基本操作包括设置断点、单步执行、查看内存、分析堆栈、跟踪调用链等。断点是调试中的重要工具，你可以设置条件断点，只在满足特定条件时暂停程序执行。单步执行功能允许你逐行查看代码运行过程，理解程序的...
使用 Windbg 的 !heap 命令分析内存泄漏
dvlinker的技术专栏
11-25 3520
使用 Windbg 的 !heap 命令分析内存泄漏。
使用Windbg快速分析应用内存泄露问题
微软技术栈
11-24 3080
Windbg程序调试是.NET高级开发需要掌握的必备技能，分析内存泄露、分析CPU高使用率、分析线程阻塞、分析内存对象、分析线程堆栈、Live Dedugging。这些Debug领域可以说一个技能+场景化应用的结合，如果只依靠Windbg几个简单的命令，不理解每个指令在实际Troubleshooting中的作用，是没有意义的。工欲善其事必先利其器，我们先从常用的命令和示例说起。 微软MVP实验室研究员 Windbg 常用命令 先准备一个Dump文件，建议使用64位应用程序。例如：64位II
Windbg 分析内存泄漏
Tommy(凌飞)的专栏
05-07 2577
1. 首先添加这样的一段代码到头文件中。 #ifdef _DEBUG #define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__) #else #define DEBUG_CLIENTBLOCK #endif  // _DEBUG #define _CRTDBG_MAP_ALLOC #include #incl
使用 Windbg 目录下的 UMDH 分析内存泄漏
dvlinker的技术专栏
11-25 2158
使用 Windbg 目录下的 UMDH 分析内存泄漏。
windbg托管内存泄漏排查
最新发布
qq_26900081的博客
04-05 975
地址00000290a180就是找的溢出。String 类型的一般先不管，因为他一般都是被其他对象所持有的。dumpheap -mt 7ffa056e60a8 查看方法表对于的实例地址和占用内存大小。数据量太大这里会卡死一段时间，可以考虑出现一部分内容后截图，关掉windbg重开。随便找一个或多个Address来查看他的引用根，就知道是谁在溢出了。7、如果还找不到哪里的问题（比如第三方dll有问题），可以找到具体的代码位置。dumpobj /d 00000290a180 查看一下这个对象实例。
Windbg 内存泄漏
07-25
内存泄漏是指在程序运行过程中，分配的内存没有被正确释放，导致内存占用不断增加，最终耗尽系统资源。使用Windbg可以帮助我们检测和定位内存泄漏问题。Windbg是微软提供的Windows下强大的调试工具，可以分析多种软件异常问题。使用Windbg监测内存泄漏的一般步骤包括以下几个步骤：首先，我们需要在程序运行时使用Windbg附加到目标进程；然后，通过Windbg的命令和扩展插件来监测和分析内存使用情况；最后，根据Windbg的输出结果来定位内存泄漏的具体位置和原因。需要注意的是，Windbg只能监测两个时间点的申请堆内存的变化量，并没有统计释放的堆内存，因此在分析结果时需要结合代码将其他几项过滤掉，最终确定发生内存泄漏的那一项。\[1\]\[2\]如果你想了解更多关于使用Windbg监测内存泄漏的详细步骤和技巧，可以参考相关的专栏文章列表，如VC++常用功能开发汇总和C++软件异常排查从入门到精通系列教程。\[3\] #### 引用[.reference_title] - *1* *2* *3* [使用Windbg定位Windows C++程序中的内存泄漏](https://blog.csdn.net/chenlycly/article/details/121295720)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值