windbg

windbg查看函数参数，调用堆栈，及返回值． bp kernel32!CreateFileW ".echo ---------------------------------------;kL;du poi(@esp+4);gu;.echo =======;r eax;g" 用windbg打开qq看看 0:000> bp kernel32!CreateFileW ".echo ---------------------------------------;kL;du poi(@esp+4);gu;.echo =======;r eax;g" 0:000> g ModLoad: 62c20000 62c29000 C:/WINDOWS/system32/LPK.DLL ModLoad: 77180000 77283000 C:/WINDOWS/WinSxS/x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03/comctl32.dll --------------------------------------- ChildEBP RetAddr 0012e374 7c814d65 kernel32!CreateFileW 0012e5dc 7c801d3a

WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具，可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。 WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。  调试应用程序(用户模式 user mode)  调试操作系统及驱劢程序(内核模式 kernel mode)  调试非托管程序(native program)  调试托管程序(managed program)  实时调试 (JIT: Just in time)  事后调试 (postmortem debugging) 使用WinDbg可以解决线上.NET应用程序的如下问题： ◆ 内存高 ◆ CPU高 ◆ 程序异常 ◆ 程序Hang死 在生产环境下进行故障诊断时，为了不终止正在运行的服务或应用程序，有两种方式可以对正在运行的服务或应用程序的进程进行分析和调试。 一、用WinDbg等调试器直接attach到需要调试的进程，调试完毕之后再detach即可。但是这种方式有个缺点就是执行debugger命令时必须先break这个进程，执行完debug命令之后又得赶紧F5让他继续运 行，因为被你break住的时候意味着整个进程也已经被你挂起。另外也经常会由于First Chance Excetpion而自动break

工作中难免需要查看dump，现在VC2015对dump的解析已经非常好了，自动化程度做的也很不错，只要设置了symbol路径，则绝大部分dump都可以自动解析。但有的dump，函数堆栈不够清晰，默认情况下windbg/cv2015都无法准确解析，这里就需要windbg来手动处理了。处理步骤如下： 1. 问题示例。 0:025> knb # ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 00 3211f0c0 76273520 ntdll!NtDelayExecution+0x15 *** ERROR: Symbol file could not be found. Defaulted to export symbols for kernel32.dll - 01 3211f0d0 75c2270d KERNELBASE!Sleep+0xf 02 3211f0e4 75c07890 kernel32!GetProfileStringW+0x15161 03 3211f0f4 75c0780f kernel32!UnhandledExceptionFilter+0x161 04 3211f180 77bd21d7 kernel32

使用windbg调试进程调用堆栈时，有时候会发现调用堆栈显示的不完全，这是因为windbg默认最多显示20帧调用堆栈，可以使用.kframe [StackCount]设置最大的堆栈显示深度。另外也可以使用k系列命令时附加要显示的堆栈深度，k [FrameCount]设置要显示的栈帧数量。之前用的不太熟练，被逼的使用 !for_each_frame [ " CommandString " ] 显示完整的堆栈调用。 来源： CSDN 作者： xbgprogrammer 链接： https://blog.csdn.net/xbgprogrammer/article/details/52085396

一. 显示堆栈信息 k* 命令 [~ Thread ] k[b |p| P |v] [c] [n] [f] [ L ] [ M ] [ FrameCount ] [~ Thread ] k[b |p| P |v] [c] [n] [f] [ L ] [ M ] = BasePtr [ FrameCount ] [~ Thread ] k[b |p| P |v] [c] [n] [f] [ L ] [ M ] = BasePtr StackPtr InstructionPtr [~ Thread ] kd [ WordCount ] 参数： Thread： 指定显示哪个线程的调用堆栈。如果省略该参数，则显示当前线程的调用堆栈。*显示所有线程的调用堆栈。 b： 显示每个函数的前3个参数。 p： 显示每个函数的所有参数。参数列表包括每个参数的类型、名称、值。 P： 类似于 p 。不同之处在于，每个参数显示在单独的行上面。 n： 显示调用堆栈中每帧的序号（一般称栈帧，如栈帧3）。 FrameCount： 指定显示调用堆栈的帧数，即调用堆栈的深度。默认为16进制格式。默认帧数为0x14=20 二. 切换到指定帧信息 调用堆栈显示出来之后，如果想知道调用某帧时的相关信息，可以使用 .frame 来切换到指定的帧，然后就可以使用如 dv 命令显示局部变量等。 .frame [/c] [/r]

参考文章： 文章一 ， 文章二 ， 文章三 ， 文章四 事情的起因是这样子的，一次在qq群里有人问了这么一个问题 ，“如果我的程序崩溃了，我想把崩溃时的地址和寄存器值显示出来用什么方法啊”，看到这个问题就想起了有时用vs调试器调试程序时弹出的一个什么提示都没有的警告框，只是说某某地址访问冲突了，但是这些信息对于找到是程序什么地方出问题基本没有什么帮助，要是程序恰好有一个指针形状的东西指向了程序的某行代码那还好说，可以在他附近仔细找找有什么问题，要是没有这个指针形状的东西基本上就是抓瞎了。 然后群里有大神回复了可以使用一个开源库“crashrpt”或者使用“ms的dbghelp”，基于我以往的认识，开源的东西往往文档很少，而且我最近的打算是把ms的一套东西都尽可能地多了解，于是想着看看dbghelp，至于crashrpt，虽然说上面那个大神更加推崇，只能暂时放弃。 在网上继续搜索，发现dbghelp原来只是ms里面的一个动态链接库，就是dbghelp.dll这个库，之前还以为它是一个可以执行的小工具。那么显然接下来就是搜寻这个库的使用方法了，一个我可以很容易理解的用法如下（来着 这篇文章 ），它的基本思路是在程序出错时会将错误信息写入dump文件中，基于此，它自己定义了一个minidump.h文件，这个头文件非常小，使用时包含它就可以了。这个是 下载链接 。 #include