爱华网1.下载与安装。这个简单的问题也很折磨了我好一阵子。网上提到的从微软网站下载WinDbg的大多数方法，都过时了。现在微软是把此软件放到MicrosoftWindows SDK软件中，只能先获得Microsoft WindowsSDK的online的安装器或者下载个完整的iso文件，然后启动Microsoft WindowsSDK的安装，在components中对Debugging Tools for Windows这个东西打上勾，作为MicrosoftWindows SDK的一个部件安装。折磨我的问题这时出来了，我的Win7 64位系统已经安装了Visual Studio 2010sp1 Team版与Microsoft Windows SDK 7.1 64位版。这时我安装Debugging Tools forWindows，一点效果没有。我只好先卸载掉Microsoft Windows SDK 7.164位版，重启计算机，再完整的安装Microsoft Windows SDK 7.1 64位版（Debugging Tools forWindows已经打勾），安装过程很顺利。最后再一找，硬盘上还是没有Debugging Tools forWindows！ 无奈啊，哪的问题呢？ 而且了Visual Studio2010自带了Microsoft Windows SDK 7.0A32位版，默认也是使用这个SDK的头文件与库文件。安装了Microsoft Windows SDK 7.164位版之后，执行它的Windows SDK configuration Tools想设为VisualStudio的默认设置，结果是报错。不过，用Microsoft Windows SDK 7.164位版编程倒是没问题。这个看来只有等用Visual Studio 2012才能解决了
不死心，又百度了一下“WinDbg64位”，竟然国内网站上发现有dbg_amd64+6.12.2.633.msi这个安装软件，还有免安装绿色版的Windbg.6.12.2.633for Visual.C++ 2010 andWindows.SDK.v7.1.7z天无绝人之路。使用上述msi安装软件，成功地安装上了WinDbg 64位版。
结论：微软只提供作为Microsoft WindowsSDK的一个部件来下载、安装WinDbg，但是我的计算机上死活是不能完全成功搞好这个Microsoft WindowsSDK。最后在国内的下载网站上找到了一个WinDbg独立安装包，解决了问题。
2.符号（Symbols）。这个是调试exe可执行程序时遇到的首要的基本概念。如何你在没有任何其它信息情况下打开一个exe文件，反汇编它，然后试图去理解程序的控制结构与数据结构，那可是一座极为艰巨的任务。如果有信息告诉你call0x03ff71ac,这是在调用CreateFileW函数，mov EAX dword ptr0x4f80af10，是在读一个iFileSize的整型变量，这对于理解该程序的帮助将是巨大的。这种把可执行程序中的各个存储对象，如函数入口地址、局部变量、函数的形参、全局变量等，的地址与标识符名字对应起来的信息，就放在了程序的pdb文件中（ProgramDatabase）。编译链接时在生成exe或dll同时还生成了pdb。如何稍微了解exe文件格式（PE格式），就知道实现上述的功能需求比较简单。一个可执行模块（exe或dll）装入内存准备执行时，由操作系统给该模块一个装入基准地址，模块内部的各个函数入口或者变量的地址，都是在编译链接时就算好的相对于装入基准地址的位移量，叫做虚地址(virtualaddress)。所以在调试程序时，当前模块的装入基准地址是已知的，一个内存地址减去它所在模块的装入基准地址，就是它的虚地址，然后去该模块的pdb文件中一查，就知道该内存地址保存了一个什么东西（函数或者变量），以及其类型信息。
微软提供的系统各模块的pdb文件，只包含公开接口的符号。而自己编写的程序编译链接后生成的pdb，叫做私有pdb，包含了模块自己使用的函数以及局部变量的信息，还包含了源程序对应行号。
WinDbg要求你提供你编写程序的pdb文件，以及从微软网站上下载的MS的各个模块/DLL的pdb文件。具体做法在网上有很多文章介绍了。我把SymbolsPath设为C:Symbols;C:MySymbols;SRV*C:Symbols*http://msdl.microsoft.com/download/symbols其中C:MySymbols是我自己编写的程序的pdb的存放位置；C:Symbols是微软提供的pdb的保存位置。
遇到的问题有两个：从微软下载了Windows_Win7SP1.7601.17514.101119-1850.AMD64FRE.Symbols.msi，安装了Win7SP164位的所有pdb，结果在断网状态下用WinDbg加载ntdll、kernel32等的符号，失败！还是必须联网在线下载这些pdb文件，不知道这是何故。第二个问题，在WinDbg中输入.reload -f，强制重新加载当前进程的所有模块的符号，看见它输出一串点号......然后似乎就停在了这里，没有显示命令已经执行完毕。难道是网络传输有问题？或者微软的下载网站太忙？疑惑地等了油等，最后还是再输入个别的命令试试看。lm（列出各个模块信息）命令竟然是所有模块的pdb文件都有了。原来是我不熟悉WinDbg的命令执行结果输出风格，误把它的加载完毕当成了从网上下载的进展停顿。
3.一般使用流程，就是打开一个exe文件或者attach到一个正在执行的exe进程上。然后Ctrl+Break把被调试进程停下来。设置断点。恢复进程执行。遇到断点或者异常时停在现场，查看相关的局部变量值、全局变量值、调用栈、获得的资源Handle情况、线程数量与情况等等。WinDbg默认是支持源代码调试，就跟在VisualStudio中的调试一样。自行编译的程序的pdb文件中有行号信息，所以可以把指令对应到源代码的哪一行上。
更多的高级功能、细节使用，网上有很多介绍文章。有两本书很不错《Windows用户态程序高效排错》《软件调试》（张银奎），网上都能下载到pdf版。
4. 一个超级坑人的问题。
0:001> x testLangFeatures!i
00000001`3f429154 testLangFeatures!i = 0n20
0:001> j (poi(testLangFeatures!i)==0n20) '.echo1';'.echo 2'
2
含义是对模块testLangFeatures中的一个全局整型变量i，用x命令查看，获得其地址与所存的值是十进制20.然后条件判断（j）这个整型变量的值是否等于十进制20，如果是就打印1，否就打印2.其中的poi是WinDbg表达式中取地址值的操作。结果竟然是2！网上的各种文章与书上，都是这么用的，怎么就死活判断为否呢！？无奈，又查了WinDbg的帮助，是这么说poi操作的：
Pointer-sized data from the specified address. The pointer size is32 bits or 64 bits. In kernel debugging, this size is based on theprocessor of the target computer. In user-mode debugging onan Itanium-based computer, this size is 32 bits or 64 bits,depending on the target application. Therefore, poi is thebest operator to use if you want pointer-sized data.
看见了吧，poi是按照当前系统的指针长度取数据的！所以在Win764位上就是按照64位取内存的值，而不是整型变量的32位取值。所以上例中就断定poi(testLangFeatures!i)==0n20不成立。把poi改为dwo（Double-word from the specified address）就好使了。
结论：网上的绝大多数文章甚至关于调试的书，都犯了一个错误：把指针长度与整型长度认为是相等的，因此2类操作与存储认为是可互换。这是从32位程序移植到64位程序时的最大的、最常见的legacy问题。所以两个指针相减，可别认为这是一个有符号的整数！因为整型总是4字节的，而在64位系统的指针与指针差都是8字节！
