Windbg是跟visual studio差不多的一个调试器，可以用来调试非托管程序（native application），也可以调试托管程序（managed application）。它比VS强的地方是你可以使用它来调试Windows操作系统，因此它也被叫做kernel mode debugger，同样为kernel mode debugger的调试器还有随着windbg一起安装的kd.exe（只不过这是一个命令行工具而已）。然而它在调试托管程序方面会比VS难用很多，当然如果你想看.NET程序的CLR内部结构，例如内存相关的信息的话，使用windbg还是可以的。
Windbg与VS在调试方面最大的区别是，Windbg是采用命令驱动，而VS是采用良好的用户界面（UI）驱动。粗看起来，好像windbg是可以通过类似批处理的方式来实现一些调试步骤自动化（的确是这样的，会在后续的文章中讲到），可能你会感觉windbg功能会比VS强一些。实际上VS也提供了宏支持，你可以编写宏来控制VS的调试过程—请参考我以前的文章Visual Studio调试之断点技巧篇。
本篇文章里，以下面这个简单的程序为例，我介绍一些在windbg中，调试托管程序常用的命令：
| Nativedebug.cpp
#include "stdafx.h" #include <tchar.h>
void Usage() { #ifdef _UNICODE wprintf(L"[Usage]: nativedebug.exe <digital numbers>\n"); #else printf("[Usage]: nativedebug.exe <digital numbers>\n"); #endif }
int _tmain(int argc, _TCHAR* argv[]) { int result = 0; if ( argc != 2 ) { Usage(); return -1; }
result = _ttol(argv[1]); #ifdef _UNICODE wprintf(L"%s * %s = %d\n", argv[1], argv[1], result * result); wprintf(L"Press any key to exit ...\n"); _getwch(); #else printf("%s * %s = %d\n", result * result); printf("Press any key to exit ...\n"); _getch(); #endif
return 0; } |
编译好了以后，运行windbg.exe，点击菜单中的“File”-“Open Executable”，在弹出的对话框中选择nativedebug.exe。你应该可以看到类似下面的输出，我使用绿色的字符注释了各行输出的含义：
| # # 注意黄色高亮的字体，它说明这个调试器是32位的调试器，只能调试32位的程序， # 如果你需要调试x64或者IA 64的程序，需要运行对应的调试器。 # Microsoft (R) Windows Debugger Version 6.10.0003.233 X86 Copyright (c) Microsoft Corporation. All rights reserved. # # 这一行注明了被调试程序的命令行 # CommandLine: E:\临时文档\Windbg教程\nativedebug\Debug\nativedebug.exe # # 下面这几行说明当前没有设置好符号文件搜索路径，符号文件在调试中比源文件 # 还重要，关于符号文件的说明和其重要性请参考我的另外一篇文章 # Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** # # 可执行文件搜索路径告诉了windbg在哪里搜索可执行文件（也就是.exe和.dll文件） # 大部分情况下，windbg知道怎样找到可执行文件--从程序的启动目录，从PATH环境 # 变量里面，从system32文件夹里面等等。因此大部分情况下，你不需要设置这个变量 # 然而在少数情况下，你需要使用.exepath设置它。请参看windbg帮助里面的.exepath # 的说明来了解。一种少数情况基本上我们用不到—是内核模式的调试，另外一种情况 # 是在调试用户模式（user mode）mini dump文件的时候需要指明。 # Executable search path is: # # ModLoad: 指明了当前程序加载的其所依赖的 dll文件，以及它们加载的地址。顺便 # 说一句，windbg有的时候会使用这些信息来将堆栈转换到对应的函数上去。 # ModLoad: 00950000 0096b000 nativedebug.exe ModLoad: 77d80000 77f00000 ntdll.dll ModLoad: 76070000 76170000 C:\Windows\syswow64\kernel32.dll ModLoad: 77670000 776b4000 C:\Windows\syswow64\KERNELBASE.dll ModLoad: 6ed80000 6eea4000 C:\Windows\WinSxS\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_2a4cbfc25558bcd3\MSVCR90D.dll # # 下面这一行说明了当前是什么异常导致程序中断执行，是的 ，虽然我们刚刚启动被 # 调试的程序，的确是一个异常—断点异常导致程序中断执行。至于原因请参看我的 # 另外一篇文章： # 另外，下面一行中，第一个括号里面的是当前的线程ID，第二个括号指明了当前的异常 # 是第一次机会处理，还是第二次机会处理。First chance的含义请参看我的这篇文章： (ec4.d7c): Break instruction exception - code 80000003 (first chance) # # 当前CPU中各个寄存器的值 # eax=00000000 ebx=00000000 ecx=f2260000 edx=0016ddd8 esi=fffffffe edi=77da3bdc eip=77e207ff esp=002df598 ebp=002df5c4 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 # # 没有symbol，所以在调试的时候比较麻烦，另外export symbol的含义在后一篇文章 # 中讲 # *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - # # 当前中断时，程序正在执行的函数，以及其位置。 # ntdll!LdrVerifyImageMatchesChecksum+0x6ce: # # 当前执行的指令（或者是下一条要执行的指令）。 # 77e207ff cc int 3 |
Windbg跟VS不同的地方是，windbg在启动程序后，执行main函数之前，就中断了，而VS却是直接执行，原因是VS是一个整合的平台，你可以先在源代码里面设置好断点，然后VS从源代码编译完程序后，启动程序之前自动就可以把断点设置好。而windbg只是一个调试器，所以它需要给程序员设置断点的机会，实际上所有的调试器的使用模式都是类似的。
因为没有符号文件，不好调试，所以需要先加载符号文件。Windbg知道几个符号文件搜索路径（symbol path）――就是微软的公开符号文件服务器，如果你想查看你的程序在运行过程中使用了哪些windows的API和函数的话，可以使用它。执行下面的命令来使用这个文件服务器（不要忽略了前面的点号）：
.symfix
上面的命令自动将symbol path设置为微软的公开符号文件服务器地址，如果你在微软内部混过，你会发现这个命令设置的路径有点不同，嘘……。
Sympath可以设置和查看symbol的路径，执行下面这个命令来查看最新的符号文件搜索路径：
.sympath
#
# 输出结果
#
Symbol search path is: SRV**http://msdl.microsoft.com/download/symbols
设置好符号文件搜索路径以后，接下来每次加载新的可执行（.exe或者.dll）文件，windbg都会先在这些路径里面搜索它的符号文件，但是对于已经加载了的可执行文件，例如ntdll.dll和kernel32.dll，我们需要手动重新加载，使用下面的命令来加载：
.reload
#
# 输出结果
#
Reloading current modules
.....
这个时候，点击windbg菜单里面的“View”－“Call Stack”，就可以看到堆栈了。因为我们还用到了MS CRT里面的函数，即atoi，所以我们还需要VCRT的符号文件。幸运的是，VS自带了VCRT的私有符号文件，这样我们用下面的命令将这个符号文件的文件夹路径添加到windbg的符号文件搜索路径列表里面来，注意后面的加号，如果不写加号，就说明将搜索路径完全替换成新的：
.sympath+ C:\Windows\symbols\dll
#
# 输出结果
#
Symbol search path is: SRV**http://msdl.microsoft.com/download/symbols;C:\Windows\symbols\dll
执行下面的命令看一下加载的结果（注意前面没有点号）：
lm
#
# 输出结果
#
start end module name
00b60000 00b7b000 nativedebug (deferred)
6fef0000 70014000 MSVCR90D (private pdb symbols) D:\Debuggers\sym\msvcr90d.i386.pdb\EBEA784C96244F1E8F8D35E0391C898D1\msvcr90d.i386.pdb
76070000 76170000 kernel32 (deferred)
77670000 776b4000 KERNELBASE (deferred)
77d80000 77f00000 ntdll (pdb symbols) D:\Debuggers\sym\wntdll.pdb\E06BEA155E9748BEA818E2D0DD2FED952\wntdll.pdb
上面的输出结果会在后文讲到，至于如何设置断点，以及在命令行里面查看堆栈，在后面讲――写文章还是蛮辛苦的。