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回调各占线程池的情况。