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、
定位到代码，需要具体分析逻辑，查看是否真的泄漏，还是还没来得及释放。
