利用windbg分析崩溃,句柄泄漏,死锁,CPU高,内存泄漏

2024-10-19 16:27:38

Windbg的一些简单使用命令

一、崩溃

1、输入.ecxr;kbn得到崩溃的堆栈

其中源代码如下

2、查看堆栈和源代码，发现第0帧导致崩溃，代码也是本地代码

输入.frame 0,切到第0帧如下

3、输入 dv 查看当前帧的一些变量信息

发现变量p =0x00000000

二、句柄泄漏

1、启动进程

2、用windbg附加到进程

3、 !htrace -enable命令开启句柄检测

4、 !htrace –snapshot

5、运行一段时间后

6、 !htrace –diff

得到如下信息

标红函数创建了event

7、输入lsahandleLeak!ThreadProc1+0x00000037

这样就可以看出代码中在不停CreateEvent。

补充：

可以在windbg调式中，输入!handle可以得到当前堆栈的一些句柄信息，可以看出这个堆栈event非常多。

三、死锁

1、启动进程

2、 Windbg附加进程

3、输入~*kv, 输出所有线程

4、输入!findstackntdll!RtlEnterCriticalSection,查找哪些线程在等待锁

或者看代码某一函数没执行,对比windbg中的线程,找到线程id分析

图1是源代码,图2是执行结果, ThreadProc1函数中的” ThreadProc1 lock g_mutex2”没发生,怀疑是否死锁了

5、windbg中线程信息如下，发现ThreadProc1在等某一把锁

第三帧是本地代码对比源代码发现在等锁g_mutex2;

第二帧是系统函数在等待锁,锁地址为00bf7140

6、输入!cs 00bf7140，查看这把锁信息

发现锁的占有者是0x00002cc4

7、输入~~[0x00002cc4]，发现对应是3号线程

8、切到3号线程，并输出堆栈

发现代码27号，也在等一把锁，锁地址00bf7158

9、同理输出锁信息

10、发现锁占有者0x00004c80，切到线程0x00004c80，并输出堆栈

发现是刚才的2号线程

至此分析完成2号线程和3号线程发生死锁。

四、CPU高

1、启动进程

2、 Windbg附加进程

3、输入!runaway

4、发现2号线程cpu最高，切到2号线程，并输出堆栈

5、可以得到是cpuhigh!ThreadProc1+0x35

五、内存泄漏

5.1、windbg手动分析

1、设置gflags.exe,这工具和windbg在同一目录

2、 windbg附加到进程,输入!heap –s

3、程序运行一段时间之后，再次输入!heap–s

发现00970000这个堆有增加，其他无变化

4、输入!heap -stat -h00970000，查看这个堆状态

发现这个堆的内存主要是被大小为0x224的块占用

5、输入!heap -flt s 224, 查看224这些块被谁在使用

6、输入!heap -p -a 00971d20，查看堆栈

7、已经得到堆栈，本地有源代码，还可以查看代码，

输入lsa memoryleak!ThreadProc1+0x00000048

5.2、利用umdh分析

1、同5.1设置gflags配置

2、开启命令窗口cmd,输入要定位内存泄露的程序gflags.exe /i memoryleak.exe +ust

3、设置程序的符号表路径

SET _NT_SYMBOL_PATH=SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;F:\windbgtest\Debug

4、启动memoryleak.exe,利用umdh创建第一次heap快照

输入umdh-pn:memoryleak.exe -f:memory1.log

5、运行一段时间后，再次输入快照，umdh -pn:memoryleak.exe -f:memory2.log

6、分析前后2次快照的差异umdh -dmemory1.log memory2.log -f:memoryleak.log

会在当前路径下面生成memoryleak.log,打开分析

7、

定位到代码，需要具体分析逻辑，查看是否真的泄漏，还是还没来得及释放。

最新文章

热门文章