扬长避短使用Windbg和Visual Studio高效调试调试你的代码

经常被问及这样的问题：

你为什么非要使用Windbg调试你的程序？

记得有一次面试的时候笔者也被问到这样的问题，我的回答是：不是我非要使用Windbg, 只是在不同的情况下使用不同的工具会更加方便而高效。



那么这两者到底有什么区别？在什么情况下用什么工具会更方便呢？



所谓尺有所短，寸有所长，那么笔者就总结一下在什么情况下用什么工具会更方便，可能不是100%的全面，但是应该可以说明一定的问题，希望给初学者以指引。



Case 1:

分析.dmp文件的时候，可以使用Windbg和Visual
Studio，但是windbg更高效，.dmp文件是发生问题时的进程转储文件，windbg集成了一系列的基本命令和扩展命令，一句话，只要是.dmp文件里面有的，你都可以很快的得到。



Case 2：

问题没有办法重现，就是说测试人员并不知道问题是怎么跑出来的，或者代码跑了几个月，跑出来一个问题，没有办法调试，只能抓一个.dmp文件，然后就回到了Case
1.



Case 3:

内核调试，包括驱动，系统代码，他们本身是运行在内核级的，而我们的程序运行在用户态，如果希望调试这部分代码，Visual Studio似乎有些力不从心，这个时候就是windbg发挥的时候了。



Case 4：

调试多线程死锁问题，用windbg很容易分析出来那个线程占用了那个锁。



Case 5：

分布式，RPC调用，利用Visual
Studio看那个组件调用哪个组件很不方便，而是用windbg却是一目了然。



Case 6：

内存破坏问题，Visual Studio如果想查看内存破坏问题简直比登天还难，除非破坏完了马上crash，但是大部分的情况是内存破坏了，但是并不来表现出来，包括对破坏，栈破坏，windbg几个命令就可以轻松搞定。



Case 7：

内存泄漏问题，结合umdh, leakdiag这两个工具，再加上windbg的内存分析，可以说没有查不出来的内存泄漏。



注意：Windbg调试.Net代码需要SOS扩展..



Case 8 :

Visual Studio无法在其他机器上调试dump文件中的某些模块的函数信息，因为在其他机器上在相同路径出没有相应的bin，所以无法加载pdb文件，及时你已经指定pdb所在路径。

Case 9：

Visual Studio在调试某个进程的时候，如果该进程hang住，此时Visual Studio也“hang”住，没有任何信息。

总结

首先需要说明的是本文的目的并不是说Visual Studio和Windbg这两个工具哪个好哪个差，只是说在不同的场合不同的工具可能更加高效，请大家不要误解。另外Visual
Studio绝对是Windows开发的利器, 在大多数Windows代码开发，调试方***有不可替代的作用，如果说Visual
Studio是利器，那么Windbg绝对是个神器，在一些极端的场合绝对可以独当一面。本文并没有罗列所有的cases, 如果大家有什么好的建议可以提出来，如果有必要的话，我会继续补充更多的cases. 待续..