求索阁

检查dump文件的时候, 我们经常会使用下面的命令来获得所有线程上的调用栈 ~*e !clrstack 输出结果举例如下: OS Thread Id: 0x1b30 (15) Child-SP         RetAddr          Call Site 0000000034a9ed00 000006424e611fc0 System.Threading.WaitHandle.WaitOne(Int64, Boolean) 0000000034a9ed40 00000642782f174b System...

当我们在调试器中分析问题时, 经常需要查看不同内存块的内容以分析产生的原因, 并且在随后验证所做出的假设是否正确. 由于各个对象的状态都是保存在内存中的, 因此内存的内容也就相当于对象的状态. d命令最常见的格式就是根据指定的类型信息来显示存储在某地址中的数据. 调试器并不会去猜测这个地址上存储的是什么数据, 因为在大多数情况下猜测都是错误的. 所以需要用户显式地制定按照何种格式来解析数据. 命令格式如下: d [typ...

命令 ============ dv Display Variable的缩写, 查看局部变量. dv /i 查看局部变量, 并显示符号的类型和参数类型. dv /V 查看局部变量, 并显示变量的存储位置. dv /V VariableName 指定需要查看的变量的名字 dv 02sample!gGlo* dv命令可以带有通配符, 来查看具有某命名模式的变量. 举例: dt Display Type的缩写. 当变量的类型为复合类型, 比如说结构体或者类, 那么dv命令只会显示变量的地址. dt命令可以将一块内存按照某...

命令 ========== k k命令显示的是一定数量的栈帧, 其中帧的数量是由.kframes命令来控制的, 默认值是256。 kp 5 显示调用栈中前5个函数以及他们的参数. kb 5 显示调用栈中前五个函数以及他们的前三个参数. kf 5 显示在调用栈中五个函数所使用的栈的大小. 每个栈帧所占的空间使用量的计算方法是: 将当前函数的栈基指针与在函数中调用的任何一个函数栈基指针相减. 举例: 手动构造栈的实践- 如何手工构造调用栈 ============ 首先...

命令 ========== ~0 bp 02sample!KBTest::Fibonacci_stdcall "r esp" 在零号线程上的KBTest类的Fibonacci_stdcall函数上设置断点, 并且在触发断点时执行"r esp"命令. bl 列出所有已经设置了的断点 bc * 清除所有断点 bp 02sample!KBTest::Fibonacci_stdcall “r esp;g” 在所有线程上设置断点, 并且在触发断点时执行"resp;g"两条命令. bm 02sample!*kbtest* 命令bm可以在参数中指定一个符号模...

命令 ========== u . u $ip 上面的两个命令是效果是一样的, 反汇编当前$ip地址上的8条命令. uf . uf $ip 上面两个命令的效果是一样的, 反汇编当前$ip地址上的整个函数. ub . ub $ip 反汇编$ip之前的8条指令. ub $ip L2a 反汇编$ip地址之前的42条指令. u $ip $ip+a 反汇编地址$ip到地址$ip+10之间的指令. 注意, 这里包括$ip, 不包括$ip+10。 举例:

几乎每个命令都会直接或者间接地使用符号信息. 进行符号检查的命令却不多. 查看符号的命令是x, 这个字符表示"查看符号". 语法如下所示: 0.00>x [options] module!symbols module和symbols都可以包含通配符. 在调试陌生代码时, 通配符是一种功能强大的工具, 因为它使我们在阅读代码之前能够猜测函数的名字或者全局变量. 其中, 带有_imp前缀的函数说明了该模块是引入函数的模块. 不带_imp的函数是实现该函数的模块...

Procdump是一个轻量级的Sysinternal团队开发的命令行工具, 它的主要目的是监控应用程序的CPU异常动向, 并在此异常时生成crash dump文件, 供研发人员和管理员确定问题发生的原因. 你还可以把它作为生成dump的工具使用在其他的脚本中. 有了它, 就完全不需要在同一台服务器上使用诸如32位系统上的Debug Diag 1.1或是64位系统上的ADPlus了. 问题描述 =============== 在任务管理器里发现w3wp.exe的CPU总在49%-60%左右, 间歇性地会下...

假设有个应用程序, 一启动就崩溃, 根本就来不及让你用Visual Studio来Attach, 并且该应用程序在使用Visual Studio直接lunch的情况下又不会出现这样的问题, 该怎么办呢? 除了使用<<在进程崩溃的时候自动抓取一个DUMP文件>>中的方法, 还可以使用WinDBG直接加载应用程序的可执行文件, 然后在应用程序退出的系统函数上下断点, 从而得到退出时的call stack. 让我们用notepad.exe作为例子吧. 首先, 使用Open Executable来...

比方说你抓了个full dump, 在debug一个很复杂的问题, 可能你已经有了结果, 或者还在研究当中, 这时你被别的事情打搅了, 回家了, 第二天来重开dump文件, 不记得昨天做到哪里了. 在或者说, 你的同事很牛, 他分析了dump文件并得出了结论. 你想学一下他的思路. 在这两种情况下, 让windbg把曾经输入过的命令按顺序写到文件里的功能就相当有帮助了. 命令举例如下: .write_cmd_hist c:\WindbgCmdHistory.txt 参考资料: WinDBG帮助文件.