windbg

简介：最近经常会碰到客户那边出现各种奇怪的问题，由于日志不可能完全记录运行信息，又或者日志回滚导致记录信息丢失等，无法定位bug出现位置，这时你非常希望自己的能够单步调试。下面是vs2008+windbg研究的结果，可能存在不完善的地方，希望牛人不吝赐教，互相学习。<br/> 补充：一般写完程序之后，自己会写一些测试用例来测试自己写的程序，进行完单元测试之后会交由测试部进行测试，但是不能够保证所有的bug都会被测试出来，多数会由客户电脑负责的环境导致程序出现一些莫名其妙的问题，废话不多说了。<br/> 调试环境 测试环境：windows 7<br/> 开发工具：vs2008, windbg6.3.9600<br/> ##调试代码## #include <stdio.h> void TestFunc(int nVar, char *pStr) { printf("juest print nVar:%d, pStr:%s\n", nVar, pStr ? pStr:"null"); } void main() { TestFunc(1, "hello world!"); } ##vs2008 release模式设置## /Zi 该命令是生成PDB文件中包含变量名和函数名，不会影响到优化选项(生成代码时vs release版会对代码进行优化) ![在此输入图片描述][1] /01

以下默认windbg加载calc程序 1. d*s dds 、 dps 和 dqs 命令显示给定范围内存的内容,它们是把内存区域转储出来，并把内存中每个元素都视为一个符号对其进行解析，dds是四字节视为一个符号，dqs是每8字节视为一个符号，dps是根据当前处理器架构来选择最合适的长度 比如要看看当前stack 中保存了哪些函数地址，就可以检查ebp 指向的内存 0:000> dds ebp 0007fdfc 0007ff1c 0007fe00 010021b0 calc!WinMain+0x25f 0007fe04 0007fee8 0007fe08 00000000 0007fe0c 00000000 0007fe10 00000000 0007fe14 7c80b741 kernel32!GetModuleHandleA 0007fe18 000a232f 0007fe1c 00000000 由于 COM Interface 和C++ Vtable 里面的成员函数都是顺序排列的，所以这个命令可以方便 地找到虚函数表中具体的函数地址。比如用下面的命令可以找到OpaqueDataInfo 类型中虚 函数对应的实际函数地址: 0:002> x ole32!OpaqueData* 76aa6a41 ole32!OpaqueDataInfo::GetOpaqueData = <no

很长一段时间以来，我有一个注册表文件来为WinDbg创建上下文菜单项。这些条目允许您选择x86或x64调试器。在公司内部，我有另一个版本的注册表文件，其中包含了私有符号服务器的另外两个上下文菜单项。你可以在这个截图中看到我在内部添加的所有4个选项。 注意，注册表文件假定WinDBG安装在c:\调试器_x86和c:\调试器中（分别用于x86和AMD64调试器）。 注册表项传入Microsoft公共符号服务器（http://msdl.Microsoft.com/download/symbols）和Microsoft专用符号服务器的符号路径。在这两种情况下，符号都通过SRV*链接在本地缓存（例如c:\符号）。与体系结构条目非常相似，这种技术为您提供了一种在公共和私有符号之间切换的快速方法（在我的例子中）。符号路径的传递，而不是使用-NT_symbol_path环境变量，是绕过WinDBG所做的具体化的唯一方法。如果设置了环境变量，则该变量将位于传递的符号路径的前面。这意味着仍然可以使用环境变量路径而不是传递路径。我承认，这只是一个问题，为人们需要支持的两个符号商店和绝大多数人，环境变量是一个更好的方式去做。如果这样做，只需删除命令行的-y部分。 注册表文件为所有转储变量建立关联，包括反射转储文件（*.ini）。反射转储可以使用ProcDump和-r开关（例如ProcDump.exe-r

当你在分析一些dmp文件时，可能会发现下面的异常信息： 0:000> .exr -1 ExceptionAddress: 00000000 ExceptionCode: 80000003 (Break instruction exception) ExceptionFlags: 00000000 NumberParameters: 0 实际上我们没有在代码中设置任何硬代码断点，所以在google中搜索这个异常，有人说这个异常可能是由于堆损坏引起的。所以我的问题是，除了硬代码断点、调试时的手动断点、堆损坏之外，是否还有其他原因导致此异常？ 另一个问题是，我试图使用应用验证器来检查堆损坏，我知道它是如何工作的，应用验证器将在堆损坏时触发中断指令异常。但目前，我运行没有应用验证程序，谁会提出中断指令异常？ 我们的应用程序是一个Visual Studio包。 以下是结果来自!analyze -v 0:000> !analyze -v ******************************************************************************* * * * Exception Analysis * * * **********************************************************************

第一章　准备 1.1. 环境配置 _NT_DEBUGGER_EXTENSION_PATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 _NT_SYMBOL_PATH=SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols Path add: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 C:\Program Files\Debugging Tools for Windows (x86) 1.2 .Net CLR知识 第二章　常用命令 2.1 基本命令 序号 命令 解释 .chain 显示有哪些调试扩展。 .load DLLName !DLLName.load 加载调试扩展。DLLName要是全路径名，包括”.dll” .loadby DLLName ModuleName 加载调试扩展。DLLName是短文件名，不包括”.dll”。 ModuleName是调试进程中的模块名，表示通过它所在的路径查找DLLName。 .unload DLLName !DLLName.unload 卸载调试扩展。 .setdll DLLName !DLLName.setdll 设置缺省的调试扩展。 ![ext.]address 显示VM的分配状况 !

　　项目上反馈了一个问题，就是在生产环境上，用户正常使用的过程中，出现了服务器内存突然暴涨，客户有点慌，想找下原因。 　　讲道理，内存如果是缓慢上涨一直不释放的话，应该是存在内存泄漏的，这种排查起来比较困难，还得找开发一块看；但像这种突然暴涨的，肯定是把某些大对象放到内存里了，而最有可能的，就是大查询了，比如把几百万数据查出来这种，但这种一般等用户用完这个功能内存就会降下来。 　　环境：IIS+.net framework。发现是w3wp进程一直在涨内存，也就是iis，确实是程序的锅。 　　分析内存问题的话，一般是在持续上涨的过程中，多抓几个dump，看看哪些对象没释放，便于分析，这次用户只抓了一个dump，要不然太大了，传到我本机也费事。 　　那就开始分析吧。 　　首先找了个本地测试环境，用windbg加载dump，加载分析文件，幸运的是，.loadby sos clr一次成功了，后续分析都没啥问题，不用再从客户那边拷贝sos，clr这些文件； 　　这是用户正常业务场景的dump，也不知道当时多少人用，都在干什么，既然是内存问题，先看下内存中的对象情况吧： 　　!dumpheap -stat 　　果不其然，出现了DataRow的影子，估计是有个大查询没跑了。但是是什么场景？哪个sql？查出来多少数据？这个得继续分析了。 　　需要注意的是，抓这个dump的时候，内存3g多

WinDBG提供了多种设断点的命令： bp 命令是在 某个地址 下断点， 可以 bp 0x7783FEB 也可以 bp MyApp!SomeFunction 。 对于后者，WinDBG 会自动找到 MyApp!SomeFunction 对应的地址并设置断点。 但是使用bp的问题在于：1）当代码修改之后，函数地址改变，该断点仍然保持在相同位置，不一定继续有效； 2）WinDBG 不会把bp断点保存工作空间中 。 bu 命令是针对 某个符号 下断点。 比如 bu MyApp!SomeFunction 。 在代码被修改之后， 该断点可以随着函数地址改变而自动更新到最新位置。 而且bu 断点会保存在WinDbg工作空间中， 下次启动 Windbg 的时候该断点会自动设置上去。 还bu 可以对还不能识别的符号设置断点，当系统中有新模块加载进来时，调试器会对未定断点再次进行识别，如果找到了匹配的符号则会设置它。而bp 断点会失败（因为函数地址不存在），bu 断点则可以成功。 新版的WinDBG中 bp失败后会自动被转成bu 。 bm 命令也是针对 符号 下断点。 但是它支持 匹配表达式 。 很多时候你下好几个断点。 比如，把MyClass 所有的成员函数都下断点： bu MyApp!MyClass::* ， 或者把所有以CreateWindow开头的函数都下断点： bu user32