蓝屏分析修复工具(Windbg) v6.12汉化版

Windbg 64位是针对windows出现蓝屏而设计的一款修复工具，软件可以通过对dmp文件的分析和定位来帮助用户解决蓝屏、系统崩溃等问题，当您电脑出现蓝屏或者其他系统问题的时候，可以下载此款工具进行修复，支持64位和32位系统，已完全汉化，需要的朋友可以下载！

Windbg使用方法

当你拿到一个dmp文件后，可使用【Ctrl+D】快捷键来打开一个dmp文件，或者点击WinDbg界面上的【File=>Open Crash Dump…】按钮，来打开一个dmp文件。第一次打开dmp文件时，可能会收到如下提示，出现这个提示时，勾选“Don't ask again in this WinDbg session”，然后点否即可。

当你想打开第二个dmp文件时，可能因为上一个分析记录未清除，导致无法直接分析下一个dmp文件，此时你可以使用快捷键【Shift+F5】来关闭上一个dmp分析记录。

注意事项

符号表是WinDbg关键的“数据库”，如果没有它，WinDbg基本上就是个废物，无法分析出更多问题原因。所以使用WinDbg设置符号表，是必须要走的一步。

1、运行WinDbg软件，然后按【Ctrl+S】弹出符号表设置窗

2、将符号表地址：SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols 粘贴在输入框中，点击确定即可。

注：红色字体为符号表本地存储路径，建议固定路径，可避免符号表重复下载。

使用技巧

【抓dump】

1、一般抓法

adplus -hang -p 3230 -quiet 抓3230 pid进程，hang模式，相当于把那个进程暂停住，取内存快照

adplus -crash -pn w3wp -quiet 抓w3wp进程，crash模式，当那个进程崩溃结束的时候自动抓取当时的内存

adplus -hang -iis -quiet 抓IIS相关进程，包括其上host的web应用，以及iis自身

2、抓window服务

http://support.microsoft.com/kb/824344/zh-cn

3、远程抓

http://blog.joycode.com/tingwang/archive/2006/08/11/79763.aspx

4、抓蓝屏和死机的dump

电脑无故重启或者蓝屏会在C:\WINDOWS\Minidump\下保存一个minidump，但是这个minidump可用的命令很少，一般只打!analyze –v看到是哪个进程引起的，还有相关的驱动模块就基本定位问题了。

5、IIS回收的时候抓

http://blog.yesky.com/blog/omakey/archive/2006/12/17/1618015.html

6、计划任务抓

比如一个进程起来后不知道它什么时候会意外崩溃，可以在计划任务里用crash里抓，当那个进程意外终止的时候，cdb可以直接附加上去，抓取当时的dump，如果要抓一些会自动重启的进程，而且要抓每次重启前的dump，可以参考附录里一节。

【常用命令】

1、先path C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727，把.net路径设置为path环境变量，一遍在windbg里可以直接.load sos，而不必.load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

2、ld demo，加载你程序的pdb文件，调试.net程序一般要把kernel32和mscorwks的符号加载上，关于这两个东西大家可以查资料，尤其是后者有哪些函数可以多了解一些。

3、在windbg的file/symbol file path对话框里输入以下文字，以便自动加载和下载符号

C:\WINDOWS\Symbols;d:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\symbols;.sympath SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols

其中有windows、.net2.0和自动从网上下载的调试符号，注意根据自己的情况适当修改目录

【调试死锁】

1、!syncblk，查看哪些线程拿到了锁

2、~67e!clrstack 跳到某个拿到锁的线程看它正在干什么操作，迟迟不肯释放锁

3、!runaway 查看这个占有锁的线程运行了多长时间。

4、~*e!clrstack查看所有线程的托管堆栈，看看哪些是正在等待锁的，比如hang在System.Threading.Monitor.Enter(System.Object)

5、~136s选择该线程，显示如下

0:000> ~136s eax=00005763 ebx=08deeb5c ecx=03eff0d4 edx=5570ab69 esi=08deeb5c edi=7ffd6000 eip=7c95ed54 esp=08deeb10 ebp=08deebb8 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!KiFastSystemCallRet: 7c95ed54 c3 ret

找到ecx寄存器的值，复制后ctrl+f，向上查找，会找到!syncblk的地方，如下

0:000> !syncblk Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 1906 03ee4be4 5 1 03ee8f88 22c8 67 185e2ef0 System.Object 5390 052ca39c 3 1 05292b30 1dd4 49 1060d3ac System.Object 9372 0530702c 15 1 0012d3a8 1aa8 80 185e7704 System.Object 11428 03eff0d4 35 1 053b8fa8 169c 120 166acd98 System.Object 15278 0531c6b4 61 1 06bc1430 26d8 86 1a5bea88 System.Object

可以看到136线程等待的锁被120号线程占着不放(格式有点乱，凑合看)，

6、有时候通过ecx寄存器找锁不是很确定，可以用~* kb来把所有线程堆栈打出来，然后根据!syncblk出来的同步快的值去搜索大概有多少个线程在等那个锁。因为同样是等待锁，可等的状态不一样，有的在Q里，有的锁已经升级，有的去尝试去拿锁了，所以不一定当时ecx寄存器指向那块内存，具体如何找到某个正在等待锁的线程等待的锁的内存地址，以及它正等待的这个锁被哪个线程拿着，我还没琢磨出规律来，但一般情况下，如果有其它同步对象的话，更难查。.net里用我上面说的几步就能查出锁的问题了。

【内存泄漏】

1、!dumpheap -stat看看哪些对象个数最多，占内存最大，

2、找到某个格式比较多的对象，可以看它的方法表，然后用!dumpheap -mt 66398fa4去随机找几个对象的地址

3、用!do 1e5a22bc命令去查看几个对象的状态，属性的值等，看看正常不正常

4、用!gcroot -nostacks 1e5a22bc去查看几个对象的根正常不正常，如果有些对象的根不是自己预先设计的那样，很可能被自己没想到的对象强引用了，所以GC无法回收它，就泄漏了。

【CPU百分百】

主要用几个计数器和!runaway命令，具体见以下链接

http://www.cnblogs.com/onlytiancai/archive/2007/12/archive/2007/06/03/769307.html

【线程池耗尽】

!threadpool 能看到完成端口，线程池工作线程和timer回调各占线程池的情况。