windbg使用方法（轉）

Windbg調試命令詳解

轉載註明>> 【作者：張佩】【原文：http://www.yiiyee.cn/Blog】

1. 概述

用戶成功安裝微軟Windows調試工具集後，能夠在安裝目錄下發現四個調試器程序，分別是：cdb.exe、ntsd.exe、kd.exe和Windbg.exe。其中cdb.exe和ntsd.exe只能調試用戶程序，Kd.exe主要用於內核調試，有時候也用於用戶態調試，上述三者的一個共同特點是，都只有控制檯界面，以命令行形式工作。

Windbg.exe在用戶態、內核態下都能夠發揮調試功能，尤其重要的是，它不再是命令行格式而是採用了可視化的用戶界面。所以絕大部分情況下，我們在談及Windows調試工具的時候，都直接指向Windbg，而不大談及前三者。

Windbg在用戶態和內核態下，都支持兩種調試模式，即“實時調試模式（Living）”和“事後調試模式（Postmortem）”。所謂實時模式，是被調試的目標對象（Target）當前正在運行當中，調試器可以實時分析、修改被調試目標的狀態，如寄存器、內存、變量，調試exe可執行程序或雙擊雙機實時調試都屬於這種模式；所謂事後模式，是被調試的目標對象（Target）已經結束了，現在只是事後對它保留的快照進行分析，這個快照稱爲轉儲文件（Dump文件）。

Windbg另一個重大優點，還在於它支持源碼級的調試，就像VC自帶的調試器一樣。

雖然提供了用戶界面，但Windbg歸根結底還是需要用戶一個個地輸入命令來指揮其行動。這就是他的Command窗口。

每個調試命令都各有使用範圍，有些命令只能用於內核調試，有些命令只能用於用戶調試，有些命令只能用於活動調試。但用戶也不必記得這許多，一旦在某個環境下，使用了不被支持的命令，都會顯示“No export XXX found”的字樣。就拿!process命令來說吧，它顯示進程信息，但只能用於內核調試中，如果在用戶調試中使用，就是下面的情景：

0:001> !process
No export process found

1.1 尋求幫助

我們首先來看如何在使用過程中獲取有用的幫助。Windbg中的調試命令，分爲三種：基本命令，元命令和擴展命令。基本命令和元命令是調試器自帶的，元命令總是以“.”開頭，而擴展命令是外部加入的，總是以感嘆號“!”開頭。各種調試命令成千上萬，我們首先要想辦法把它們都列舉出來，並取得使用方法。

基本命令最少了，大概40個左右。列舉所有的基本命令，使用如下命令：

• ?

元命令有一百多個，使用下面命令列舉所有元命令：

• .help  [/D]

如使用“/D”參數，命令列表將以DML格式顯示。DML是一種類似於HTML的標識語言，下面會講到。下圖以DML格式顯示所以有字母a開頭的元命令：

最後講擴展命令。所謂擴展命令，顧名思義是可以“擴展”的。擴展命令從動態連接庫中暴露出來，一般以DLL文件名來代表一類擴展命令集，首先我們要搜索出系統中有多少個這樣的DLL文件，使用下面命令：

• .chain  [/D]

此命令能夠給出一個擴展命令集的鏈表。和.help命令一樣，也可以使用/D參數以DML格式顯示。如下所示：

0:001> .chain
Extension DLL search Path:
    C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP;
Extension DLL chain:
    dbghelp: image 6.2.9200.20512, API 6.2.6, built Fri Sep 07 13:45:49 2012
        [path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\dbghelp.dll]
    ext: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 10:11:33 2012
        [path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\ext.dll]
    exts: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 10:15:20 2012
        [path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP\exts.dll]
    uext: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 10:15:09 2012
        [path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\uext.dll]
    ntsdexts: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 10:16:01 2012
        [path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP\ntsdexts.dll]

            最上面兩行顯示了擴展模塊的搜索路徑。接下來共列出了六個Windbg自帶的擴展模塊：wdfkd、dbghellp、ext、exts、uext和ntsdexts。可以查看到這些擴展模塊的版本信息、鏡像文件路徑。如何列出某個擴展庫中所包含的擴展命令列表呢？絕大部分擴展模塊可使用如下命令：

• !模塊名.help

此外，擴展命令模塊是可“擴展”的。如果讀者從第三方處獲取，或自己編寫了一個擴展調試模塊，則可通過.load/.unload命令動態加載/卸載。

1.2 DML語言

DML（Debugger Markup Language調試器標記語言）像HTML一樣，可從一處鏈接到另一處。不同處在於，DML的鏈接內容需要用戶點擊後纔會動態生成。一般用來以精簡方式顯示大量信息和擴展功能。

DML有很多實用的功能，如果使用者一時不知道從何下手，最好就是輸入.dml_start命令，開始DML之旅。

DML鏈接以更加可視化的方式，引導用戶查看調試信息，使得調試工具的使用相比純指令格式而言，更爲友好。DML如同是對原指令的一層輕微的包裝一樣，讓生硬的指令更加溫和了。所以建議讀者總是把DML默認開啓。

• .prefer_dml  1

開始DML。

• .prefer_dml  0

關閉DML。

一旦開啓DML後，像k等支持DML的調試命令，將默認以DML格式顯示輸出內容。

DML還能以一種很特殊的方式爲函數畫流程圖。它主要的原理是使用反彙編，類似於uf，但在邏輯分支處，它會停止反彙編並顯示分支讓用戶選擇。另外，它能顯示彙編代碼對應的行號，這一點真的非常好。如果稍加精進，他就能畫出非常漂亮的流程圖了。他的一個特點是反彙編的順序是從後往前推。只要細想一想，就會覺得很有道理。如果正推的話，分支太多；而反推則分支順序在用戶的參與下（即用戶進行分支選擇），是固定了的。

• .dml_flow  FindAllInfFilesA  FindAllInfFilesA+30

這是一個非常簡單、實用的例子，對Kernel32庫中的FindAllInfFilesA接口函數進行反彙編，效果類似uf命令卻更強大。

1.3 基本信息

本節講解和調試器軟件本身相關的命令，比如：查看軟件版本、啓動參數，以及最基本的軟件設置命令。首先看版本命令：

• version

此命令顯示操作系統的版本信息以及Windbg本身的版本信息，Windbg的配置和操作系統密切相關，所以將操作系統的版本信息一併顯示出來是很有必要的。在內核環境與用戶環境下運行此命令，會得到不同的輸出。下圖爲內核環境下輸出結果：

0:001> version
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.1.7601.18015 (win7sp1_gdr.121129-1432)
Machine Name:
Debug session time: Thu Aug 22 10:11:04.000 2013 (UTC + 8:00)
System Uptime: 14 days 17:26:44.613
Process Uptime: 14 days 17:14:25.000
  Kernel time: 0 days 0:09:02.000
  User time: 0 days 0:42:36.000
Full memory user mini dump: C:\Users\mozhang\AppData\Local\Temp\dwm.DMP

Microsoft (R) Windows Debugger Version 6.2.9200.16384 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

除了Windbg版本信息，上面的輸出中還包括目標系統信息。如果純粹是爲了查看目標系統的版本信息，可使用下面的vertarget命令：

• vertarget

Windbg支持對多個調試系統中的多個調試目標同時進行調試。上面我們通過version或vertarget命令列出了當前調試系統的版本信息，還可以查看當前目標系統的狀態：

• ||

如Windbg中同時打開多個調試對象，“||”命令將列出對象列表。筆者爲了演示此種情況，先在Windbg中開啓Local Debug環境，然後兩次調用.opendump命令打開兩個DUMP文件，這樣就同時擁有了三個被調試的目標對象。下圖顯示了這個情況：

            上圖中的活動對象是0號對象（可從數字0前面的小數點看出）。調試器需要在多個調試目標之間進行切換的話，使用“s”參數。如要切換到1號目標可使用下面的命令：

• ||  1  s

最後一個命令用來查看系統時間。這包括系統當前時間，以及系統正常運行持續時間；用戶模式下還會顯示當前進程的持續時間。命令格式如下：

• .time

0:001> .time
Debug session time: Thu Aug 22 10:11:04.000 2013 (UTC + 8:00)
System Uptime: 14 days 17:26:44.613 // 系統運行時間
Process Uptime: 14 days 17:14:25.000// 當前進程運行時間
  Kernel time: 0 days 0:09:02.000
  User time: 0 days 0:42:36.000

1.4 基本設置

首先看一個清屏命令：

• .cls

當命令窗口中的內容太亂的時候，這個命令幫你快刀斬亂麻。

下面看一個設置默認數字進制的命令：

• n  [8|10|16]

軟件默認是16進制，但有時候我們也需要把默認進制改成八進制或十進制的。下面嘗試在八進制下面求數字11的值，如下：

0:001> n 8
base is 8
0:001> ? 11
Evaluate expression: 9 = 00000000`00000009

最後再來說一個處理器模式指令。關於處理器模式很值得一說，很重要。處理器模式的設置，反映了Windbg軟件的強大。舉例來說，主機爲32位的系統，卻可以同時調試X86、IA64、X64的目標系統——前提是先將主機的處理器模式設置正確了。可用處理器模式值有：x86、adm64、ia64、ebc。

• .effmach  x86

命令.effmach表示Effective Machine Type，即有效的機器類型。此命令將當前的處理器模式設置爲x86模式。

1.5 格式化顯示

將一個整數以各種格式顯示，包括：16進制、10進制、8進制、二進制、字符串、日期、浮點數等。是不是很方便？這個命令是：

• .formats  整數

下面以0x123abc爲例：

0:001> .formats 0x123abc
Evaluate expression:
  Hex:     00000000`00123abc
  Decimal: 1194684
  Octal:   0000000000000004435274
  Binary:  00000000 00000000 00000000 00000000 00000000 00010010 00111010 10111100
  Chars:   ......:.
  Time:    Thu Jan 15 03:51:24 1970
  Float:   low 1.67411e-039 high 0
  Double:  5.90252e-318

1.6 開始調試

現在領大家進入調試階段。首先看看如何讓調試器附載到一個已運行的進程中去？比如IE軟件在運行過程中發生了崩潰，打開Windbg後如何調試呢？第一步就是把Windbg附載到發生崩潰的IE進程上。使用如下命令格式：

• .attach  PID

或者通過Windbg的啓動參數進行掛載：

• Windbg –p PID

上面兩個命令中，PID指定了進程ID。如果覺得指定PID不方便，也可以通過進程名進行掛載：

• Windbg -pn 進程名

比如掛載到記事本就可以這樣：

windbg –pn notepad.exe

上面的命令是把調試器掛載到已經存在的進程上，另外調試器可以創建新進程並對它進行調試，這二者使用了不同的侵入方法。使用下面的命令：

• .create 程序啓動命令行

或者Windbg啓動參數

• Windbg 程序啓動命令行

比如創建並調試一個記事本子進程，可用.create notepad或者windbg notepad命令。也可以打開Windbg後，在File菜單中選擇“Open Executable…”啓動Notepad子進程，但這個選項只能被執行一次（之後會灰掉）。

使用上述命令可將調試器連續附載到多個進程，也就是說，能夠同時調試多個進程，這一點看上去很神奇哦。下例中，調試器先創建子程序IOCTL.exe，然後又調用.attach命令附加到記事本進程，使用命令“|”列出所有被調試進程。

讀者可能會奇怪，多個進程同時調試怎麼兼顧呢？只要有一個切換指令就可以了，這樣就能夠切換到任意的進程（令其爲當前進程）並對之進行調試。比如上圖顯示1號進程爲當前進程（注意1前面的小點），如何將當前進程切換到0號進程呢？可以使用進程列表命令“|”輕鬆切換，比如：

• |  0  s

此命令把當前調試環境切換到0號IOCTL.exe進程。另外需注意的是，多個用戶進程調試目標都處於同一個調試會話中，使用“||”命令會看到，它們屬於同一個 “Live user mode”調試會話。

下面看dump文件調試，使用命令：

• .opendump  文件名

此命令打開一個dump文件，並建立一個DUMP調試會話。如何手動創建一個dump文件呢？比如在調試過程中，遇到了無法解決的問題，希望獲得異地幫助，則把當前調試環境保存到Dump文件中發送給能提供幫助的人，不失爲一種好辦法。

• .dump  文件名

Dump文件一般以.dmp爲後綴，系統生成的Dump文件都默認以.dmp爲後綴的，但使用.dump命令時，使用者可以設置任意後綴，甚至無後綴。下例中，首先爲當前進程生成一個dump文件保存到a.txt中（即後綴名爲.txt），然後將之打開並分析：

0:001> .dump a.txt
Creating a.txt - mini user dump
Dump successfully written
0:001> .opendump a.txt
Loading Dump File [C:\Program Files (x86)\Windows Kits\8.0\Debuggers\a.txt]
User Mini Dump File: Only registers, stack and portions of memory are available

Opened 'a.txt' // 打開成功

上文講到進程掛載命令，當需要解除掛載時，可使用解掛命令，如下：

• .detach

此命令結束當前調試會話， Windbg解除和被調試進程之間的調試關係（不管是通過掛載，還是通過創建方式建立的調試關係），解掛後，被調試進程能夠獨立運行；如果當前的調試會話是一個Dump文件，此命令直接結束對dump文件的調試，即結束調試會話。

如果需要徹底結束調試，下面的命令更有用：

• q | qq | qd

q是Quit的縮寫。結束當前調試會話，並返回到最簡單的工作空間，甚至把命令行界面也關閉掉。q和qq兩個命令將結束（close）被調試的進程，qd不會關閉調試進程，而是進行解掛操作。

雙機調試的時候，如果你感覺調試已經陷入僵局，比如目標機Hang住了動都動不了，此時通過主機讓目標機強制宕機或重啓，不失爲一個好主意。

• .crash
• .reboot

crash命令能引發一個系統藍屏，並生成dump文件；而.reboot使系統重啓，不產生dump文件。

2. 符號與源碼

符號與源碼是調試過程中的重要因素，它們使得枯燥生硬的調試內容更容易地調試人員讀懂。在可能的情況下，應該儘量地爲模塊加載符號和源碼。大部分情況下源碼難以得到，但符號卻總能以符號文件的形式易於得到。

什麼是符號文件呢？編譯器和鏈接器在創建二進制鏡像文件（諸如exe、dll、sys）時，伴生的後綴名爲.dbg、.sym或.pdb的包含鏡像文件編譯、鏈接過程中生成的符號信息的文件稱爲符號文件。具體來說，符號信息包括如下內容：

• 全局變量（類型、名稱、地址）；
• 局部變量（類型、名稱、地址）；
• 函數（名稱、原型、地址）；
• 變量、結構體類型定義；

源文件路徑以及每個符號對應於源文件中的行號，這是進行源碼級別調試的基礎。

有這麼多的信息包含在符號文件中，使得符號文件通常要比二進制文件（PE格式文件）本身要大很多。調試過程中，符號之重要性不言而喻。只有正確設置了符號路徑，使得調試器能夠將調試目標、符號文件以及源碼文件一一對應起來，才能夠最好地發揮調試器的強大功用。

符號信息隸屬於指定的模塊，所以只有調試器需要用到某個模塊時，他的符號信息纔有被加載和分析的必要。所以我們在講符號內容之前，先講和模塊相關的命令。

2.1 模塊列表

每個可執行程序都是由若干個模塊構成，有些模塊靜態加載，有些模塊以動態方式進行加載。所以對於有些模塊，可能在A時刻運行時被加載，而在B時刻運行時，自始至終都未被加載。調試過程中，調試器根據模塊的加載情況加載符號。有幾個命令可以用來列舉模塊列表，分別是：lm、!dlls、.reload /l、!imgreloc。下面分別來看。

• lm [選項] [a Address] [m Pattern | M Pattern]

lm是list loaded modules的縮寫，他還有一個DML版本：

• lmD [選項] [a Address] [m Pattern | M Pattern]

使用/v選項能列出模塊的詳細信息，包括：模塊名、模塊地址、模塊大小、鏡像名、時間戳、以及對應的符號文件信息（包括類型、路徑、類型、編譯器、符號加載狀態）。

如使用參數a，後面跟地址（address），則只有指定地址所在的模塊能夠被列出；

如使用參數m，後面跟一個表示模塊名的字符串通配符，如lm  m  *o*將顯示所有名稱中包含字母o的模塊，下圖所示：

||0:0:001> lm m *o*
start             end                 module name
f3380000 f3512000   dwmcore    (private pdb symbols) 
f92d0000 f9327000   d3d10_1core   (deferred)             
fa890000 fa9f1000   WindowsCodecs   (deferred)             
faa50000 fac44000   comctl32   (deferred)             
fbf70000 fbf7c000   version    (deferred)             
fce20000 fce2f000   profapi    (deferred)             
fd970000 fdb73000   ole32      (deferred)             
fee60000 fee7f000   sechost    (deferred)

下面介紹另一個命令：

• !dlls [選項] [LoaderEntryAddress]

            首先看他的可選參數：

            -i/-l/-m：排序方式，分別按照初始化順序、加載順序、內存起始地址順序排列。

-a：列出鏡像文件PE結構的文件頭、Section頭等詳細信息，是分析PE結構的好幫手（更好的幫手是利用自如PEView或Stud_PE等UI工具）。

            -c：指定函數所在的模塊。這個選項非常實用，比如我想知道NtCreateFile函數是哪個模塊暴露出來的接口，如下：

0:000> !dlls -c ntcreatefile
Dump dll containing 0x7c92d0ae:
0x00251f48: C:\WINDOWS\system32\ntdll.dll
      Base   0x7c920000  EntryPoint  0x7c932c48  Size        0x00096000
      Flags  0x00085004  LoadCount   0x0000ffff  TlsIndex    0x00000000
             LDRP_IMAGE_DLL
             LDRP_LOAD_IN_PROGRESS
             LDRP_ENTRY_PROCESSED
             LDRP_PROCESS_ATTACH_CALLED

除了lm和!dlls外，下文將講到的.reload命令在加入 /l選項後，也能列舉模塊，其命令格式如下：

• .reload /l

最後再來看一個!imgreloc命令，它也能夠列出模塊列表並顯示各模塊地址。但其主要作用尚不在此，它用來判斷各個模塊是否處於preferred地址範圍。所謂Preferred地址是這麼一回事：二進制文件在編譯的時候，編譯器都會爲其設置一個理想地址（Preferred Address），這樣二進制文件被加載時，系統會儘可能將他映射到這個理想地址。當然，所謂“理想”往往是會受到“現實”的挑戰的，當存在地址競爭的時候，需要適當調整二進制文件的加載地址，選擇另一個合適的地方加載之。!imgreloc命令就是用來查看這種情況的，命令如下：

• !imgreloc [模塊地址]

命令!imgReloc是Image Relocate的縮寫，字面已能夠反映其含義：鏡像文件重定位信息。下面是一個例子。

 

      上例中，大部分系統模塊（上圖下部方框所示）其地址由於事先經過統籌分配，所以一般都能被加載到preferred地址處。只有少數模塊（如最上面的Normaliz模塊）由於地址衝突而受到了調整。

2.2 模塊信息

      上一節我們瞭解瞭如何枚舉模塊列表，這一節我們研究針對單個模塊，如何獲取詳細信息。有多個命令可以查看指定模塊的詳細模塊信息，這包括：lm、!dh、lmi等，下面來一一介紹。

首先看lm，這個命令上面我們已經介紹過，現在利用它來獲取指定模塊信息。其命令格式如下：

• lm v a 模塊地址

這裏使用了v選項，以顯示詳細（verbose）信息；並使用a參數以指定模塊地址。通過此命令顯示的信息，和我們在explorer資源管理器中通過鼠標右鍵查看一個文件的屬性所看到的信息差不多。請看下面的清單：

0:000> lm v a 00400000
start    end        module name
00400000 00752000   UsbKitApp C (private pdb symbols)  C:\Trunk\CY001\UsbKitApp\Debug\UsbKitApp.pdb
    Loaded symbol image file: UsbKitApp.exe
    Image path: UsbKitApp.exe
    Image name: UsbKitApp.exe
    Timestamp:        Tue Mar 16 22:07:02 2010 (4B9F9086)
    CheckSum:         00000000
    ImageSize:        00352000
    File version:     1.0.0.1
    Product version:  1.0.0.1
    File flags:       1 (Mask 3F) Debug
    File OS:          4 Unknown Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0804.03a8
    CompanyName:      TODO: <公司名>
    ProductName:      TODO: <產品名>
    InternalName:     UsbKitApp.exe
    OriginalFilename: UsbKitApp.exe
    ProductVersion:   1.0.0.1
    FileVersion:      1.0.0.1
    FileDescription:  TODO: <文件說明>
    LegalCopyright:   TODO: (C) <公司名>。保留所有權利。

    下面看!lmi命令，此命令通過指定模塊地址查找模塊並獲取其信息，其命令格式如下

• !lmi 模塊地址

此命令側重獲取對調試器有用的信息，請看下面的列表：

0:000> !lmi 0x400000
Loaded Module Info: [0x400000]
         Module: UsbKitApp
   Base Address: 00400000
     Image Name: UsbKitApp.exe
   Machine Type: 332 (I386)
     Time Stamp: 4b9f9086 Tue Mar 16 22:07:02 2010
           Size: 352000
       CheckSum: 0
Characteristics: 103
Debug Data Dirs: Type  Size     VA  Pointer
CODEVIEW  - GUID: {5DB12DF1-71CA-43F7-AD85-0977FB3629A4}
               Age: 3, Pdb: C:\Trunk\CY001\UsbKitApp\Debug\UsbKitApp.pdb
     Image Type: FILE     - Image read successfully from debugger.
                 UsbKitApp.exe
    Symbol Type: PDB      - Symbols loaded successfully from image header.
                 C:\Trunk\CY001\UsbKitApp\Debug\UsbKitApp.pdb
       Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
    Load Report: private symbols & lines, not source indexed
                 C:\Trunk\CY001\UsbKitApp\Debug\UsbKitApp.pdb

 如果還要查看更詳細、豐富的模塊信息，可以使用!dh命令，命令格式如下：

• !dh [標誌] 模塊地址

dh是display header的縮寫，直譯就是“顯示文件頭”的意思，它能夠顯示非常詳細的PE頭信息。下圖截取了輸出信息中的開頭部分，其它詳細內容，需要讀者熟悉微軟的PE結構才能看懂：

模塊相關的知識點講完了，下面講符號有關命令。和符號相關的知識點包括：符號路徑、符號服務器、符號緩存、符號加載以及符號的使用等。

2.3 符號路徑

什麼是符號路徑呢？就是調試器尋找符號文件的方向，它可以是本地文件夾路徑、可訪問的UNC路徑、或者是符號服務器路徑。什麼是符號服務器呢？如果調試過程中，需要涉及到成千上萬個符號文件，以及同一個符號文件存在不同平臺下的不同符號文件版本的時候，那麼一一手動設置符號路徑肯定是不現實的，於是引入符號服務器的概念。符號服務器有一套命名規則，使得調試軟件能夠正確找到需要的符號文件。一般來說，符號服務器比較大，都是共用的，放在遠程主機上。爲了降低網絡訪問的成本，又引入了符號緩存的概念，即將從服務器上下載到的符號文件，保存在本地緩存中，以後調試器需要符號文件的時候，先從緩存中尋找，找不到的時候再到服務器上下載。下面分幾部分一一來看。

設置符號路徑：

設置符號路徑的語法如下：

• .sympath  [+]  [路徑]

如果不加入任何參數執行.sympath命令，將顯示當前的路徑設置：

• .sympath

如要覆蓋原來的路徑設置，使用新路徑即可：

• .sympath  <新路徑>

要在原有路徑的基礎上添加一個新路徑，可使用：

• .sympath+  <新增路徑>

要注意的是，使用.sympath改變或新增符號路徑後，符號文件並不會自動更新，應再執行.reload命令以更新之。

這裏要談一談延遲加載的知識點。延遲加載使得模塊的符號表，只在第一次真正使用的時候才被加載。這加快了程序啓動，不用在一開始耗費大量時間加載全部的符號文件。

使用.symopt +4和.symopt -4來開啓或關閉延遲加載設置。

在已經啓動了延遲加載的情況下，如想臨時改變策略，立刻將指定模塊的符號加載到調試器中，可以使用ld或者.reload /f命令。

符號服務器與符號緩存：

設置符號服務器的基本語法是：

• SRV*[符號緩存]*服務器地址

語法由SRV引導，符號緩存和服務器地址的前面各有一個星號引導。符號緩存一般也叫做下游符號庫。如某公司有一臺專門的符號服務器，地址爲\\symsrv\\symbols，則他們公司的所有開發人員都應該在他們的調試器中使用類似下面的命令：

• .sympath+ srv*c:\symbols*\\symsrv\symbols

此外，我們總是應該把微軟的公用符號庫加入到我們的符號路徑中：

• .sympath+ srv*<緩存地址>*http://msdl.microsoft.com/download/symbols

這是一臺微軟對外公開的服務器，使用http地址訪問，不是所有人都能牢記這個網址，所以最好的辦法就是使用.symfix命令，語法如下：

• .symfix [+] [符號緩存地址]

這個命令等價於上面的.sympath命令，而不用輸入長長的http地址。

0:000> .symfix c:\windows\symbols

0:000> .sympath
Symbol search path is: SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols

符號選項：

命令格式如下：

• 顯示當前設置：.symopt
• 增加選項：.symopt+  Flags
• 刪除選項：.symopt-  Flags

第一個命令沒有任何參數，顯示當前設置。後面兩個，第二個命令含有“+”代表添加一個選項，第三個命令含有“-”代表去除一個選項。

001> .symopt
Symbol options are 0x30337:
  0x00000001 - SYMOPT_CASE_INSENSITIVE
  0x00000002 - SYMOPT_UNDNAME
  0x00000004 - SYMOPT_DEFERRED_LOADS
  0x00000010 - SYMOPT_LOAD_LINES
  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
  0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
  0x00010000 - SYMOPT_AUTO_PUBLICS
  0x00020000 - SYMOPT_NO_IMAGE_SEARCH

可用的符號選項請見下表：

值	可讀名稱	描述
0×1	SYMOPT_CASE_INSENSITIVE	符號名稱不區分大小寫
0×2	SYMOPT_UNDNAME	符號名稱未修飾
0×4	SYMOPT_DEFERRED_LOADS	延遲加載
0×8	SYMOPT_NO_CPP	關閉C++轉換，C++中的::符號將以__顯示
0×10	SYMOPT_LOAD_LINES	從源文件中加載行號
0×20	SYMOPT_OMAP_FIND_ NEAREST	如果由於編譯器優化導致找不到對應的符號，就以最近的一個符號代替之
0×40	SYMOPT_LOAD_ANYTHING	使得符號匹配的時候，匹配原則較鬆散，不那麼嚴格。
0×80	SYMOPT_IGNORE_CVREC	忽略鏡像文件頭中的CV記錄
0×100	SYMOPT_NO_UNQUALIFIED_ LOADS	只在已加載模塊中搜索符號，如果搜索符號失敗，不會自動加載新模塊。
0×200	SYMOPT_FAIL_CRITICAL_ ERRORS	不顯示文件訪問錯誤對話框。
0×400	SYMOPT_EXACT_SYMBOLS	進行最嚴格的符號文件檢查，只要有微小的差異，符號文件都不會被加載。
0×800	SYMOPT_ALLOW_ABSOLUTE_ SYMBOLS	允許從內存的一個絕對地址處讀取符號信息。
0×1000	SYMOPT_IGNORE_NT_ SYMPATH	忽視在環境變量中設置的符號路徑，也忽視被調試進程的執行路徑。也就是說，當搜索符號文件的時候，不會從這些路徑中搜索。
0×2000	SYMOPT_INCLUDE_32BIT_MODULES	讓運行在安騰系統上的調試器，也枚舉32位模塊。
0×4000	SYMOPT_PUBLICS_ONLY	僅搜索符號文件的公共（PUBLIC）符號表，忽略私有符號表。
0×8000	SYMOPT_NO_PUBLICS	不搜索符號文件的公共（PUBLIC）符號表
0×10000	SYMOPT_AUTO_PUBLICS	先搜索pdb文件的私有符號表，如果在其中找到對應的符號，就不再搜索公共（PUBLIC）符號表，這可以加快搜索速度。
0×20000	SYMOPT_NO_IMAGE_SEARCH	不搜索鏡像拷貝
0×40000	SYMOPT_SECURE	安全模式，讓調試器儘量不影響到主機。
0×80000	SYMOPT_NO_PROMPTS	不顯示符號代理服務器的認證對話框，將導致某些時候無法訪問符號服務器
0×80000000	SYMOPT_DEBUG	顯示符號搜索的詳細過程和信息

表8-1 符號選項

2.4 符號加載

本節分下面幾個子題目分別講解。

立刻加載：

其命令格式如下：

• ld 模塊名 [/f 符號文件名]

加載指定模塊的符號。調試器默認採用延遲模式加載符號，也就是直到符號被使用的時候，纔將符號文件加載到調試器中並進行解析。ld使得延遲模式被打破，讓指定模塊的符號文件立刻加載到調試器中。此指令可爲模塊的符號文件設置自定義的匹配名稱，比如：

• ld  123  /f  abc

這樣一來，abc.pdb將成爲123.exe的符號文件。正常情況下，這是不可能的，只能是abc.pdb對應abc.exe。

重新加載：

如果對自己正在使用的符號文件感到疑惑，比如源代碼和行號明顯不匹配，最好的做法就是重新加載一下符號文件。此命令語法如下：

• .reload /f /v [模塊名]

.reload命令的作用是刪除指定或所有已加載的符號文件，默認情況下，調試器不會立刻根據符號路徑重新搜索並加載新的符號文件，而是推遲到調試器下一次使用到此文件時。

使用/f參數（force），將迫使調試器立刻搜索並重新加載新的符號文件。

其它參數解釋如下：

• /v：將搜索過程中的詳細信息都顯示出來。
• /i：不檢查pdb文件的版本信息；
• /l：只顯示模塊信息，內核模式下，和“lm n t”命令類似，但顯示內容比後者更多，因爲包含了用戶模塊信息；
• /n：僅重載內核符號，不重載用戶符號；
• /o：強制覆蓋符號庫中的符號文件，即使版本相同；
• /d：用戶層模式下使用Windbg時的默認選項，重載調試器模塊列表中的所有模塊；
• /s：內核模式下使用Windbg時的默認選項，重載系統模塊列表中的所有模塊，另外，如果調試器在用戶模式下運行，要加載內核模塊，也必須使用/s選項，否則調試器將只會在調試器模塊列表中搜索而導致找不到內核模塊；
• /u：卸載指定模塊。如發現當前符號版本不對，使用/u開關先卸載之再重新加載。

符號驗證：

上面講到.reload的時候，我們說過，符號文件會出現不匹配的情況。這是很有可能的，程序員在後期測試的時候可能會將工程多次編譯，爲了維護多個版本而使得自己也被搞混。可以使用下面的命令驗證一個模塊的符號文件：

• !chksym <模塊名> [符號名]

加載選項：!sym

有兩類符號加載選項。第一類是Noisy/Quiet，Noisy選項將打印符號加載的詳細信息，Quiet選項則忽略這些信息。第二類是Prompts/Prompts off，即是否允許執行提示（Prompts）對話框。

一般都是在調用.reload 命令之前，執行加載選項命令，以見立竿見影之效。

所謂Noisy是吵鬧的意思，調試器在搜索、加載符號的時候，會顯示更多與搜索有關的信息。而安靜模式下，則不會顯示這些信息。不管吵鬧與否，都不會影響到最終的搜索、加載結果。

當從網絡上下載符號文件的時候，可能會碰到網絡服務器要求客戶進行安全認證的情況，如果開啓Prompts選項，則彈出認證對話框，讓用戶輸入認證信息；否則，不彈出對話框，並且不會下載符號文件。

不加任何參數的情況下，顯示當前加載選項設置，下面的清單表明當前的設置爲Quite及Prompts模式：

lkd> !sym
!sym <noisy/quiet - prompts/prompts off> - quiet mode - symbol prompts on

2.5 符號搜索

符號搜索包括全局搜索和就近搜索兩種。

全局搜索：

命令“x”被用來進行符號的全局搜索，你可以把它直接就理解爲search。格式如下：

• x  [參數]  [模塊!符號]

如果什麼參數都沒有的話，它將列出當前調試環境下的所有局部變量，前提是要在有局部變量存在的情況下，顯示局部變量的另一個命令是dv，後文也會講到。

• x  kernel32!a*，

上面命令搜索並打印出kernel32模塊中所有a開頭的符號。x命令支持DML，使用/D選項即以DML格式顯示。

如果你不知道ntcreatefile這個函數是在哪個模塊中定義的，可以試着使用下面的命令：

• x  *!*NtCreateFile* （注：亦請參照!dlls –c命令）

同名函數在多個系統模塊中並定義，這可能出乎你的意料，但卻給你帶來真正的知識。

此外，x命令有多個可選參數。建議總是帶上/t和/v，可顯示更多符號、類型信息。

• /f：將只顯示函數符號；並且會顯示函數的詳細定義。
• /d：顯示更多的變量類型相關信息。 

就近搜索

如果知道了符號的大概地址，但不能確定確切的符號名稱，該怎麼處理呢？就近查找命令ln能發揮作用，ln是List Nearest的縮寫。它的作用是：（根據給定的地址）列出附近一定範圍內的所有符號。下表中，指定地址0x7c8179f0的前後各有一個符號被找到：

0:000> ln 7c8179f0
(7c8179c3)   kernel32!NlsServerInitialize+0x29   |  (7c8179fe)   kernel32!AllocTables

2.6 源碼命令

如果含有源碼信息，可使得調試過程能夠以源碼模式逐行進行。和源碼相關的命令包括下面幾個： 

源碼路徑：

和符號路徑類似，要設置源碼路徑，使用如下語法格式：

• .srcpath[+] [路徑1;路徑2]

不含任何參數的情況下，顯示當前設置的源碼路徑。

下面命令將覆蓋原設置，設置新的源碼搜索路徑：

• .srcpath <路徑信息>

使用“+”可以將新的路徑添加到原設置中，而不會把原設置覆蓋掉：

• .srcpath+ <路徑信息> 

源碼選項

這裏列出的源碼選項有三個，下面分別來講。第一個是源碼的Noisy選項，語法如下：

• .srcnoisy [1|0]

此命令乃source noisy縮寫，可以理解成“嘈雜的源碼”，類似於符號設置中也存在的noisy選項。他的三種運用如下所示：

• 狀態：.srcnoisy
• 開啓：.srcnoisy 1
• 關閉：.srcnoisy 0

開始“吵鬧的源碼”選項後，在源碼加載、卸載，甚至單步的時候，都會顯示豐富的源碼信息。下圖顯示了一個含有Noisy信息的單步命令：

 

第二個命令是行號選項，即在符號文件加載過程中，是否將行號也一併加載進來。因爲Windbg支持源碼級調試，所以它在Windbg中是默認開啓（Enable）的，我們一般也不應該去禁止他。語法如下：

• .lines [-d|-e|-t]

參數d是disable的意思；e是enable的意思；t表示切換的意思，即自動在disable和enable兩者之間切換。

最後看第三個命令，是代碼行選項，包括行號和內容。語法如下：

• 打開：l+ [選項]
• 關閉：l- [選項]

命令l是line的縮寫，和上面的.lines命令不同的是，.lines是加載時選項，l是調試時選項。我建議讀者總是調用“l+*”指令，打開所有的行選項，效果會很不錯。這樣在單步調試的時候，每一步的代碼和行號都會顯示出來。顯得很醒目！

            值得注意的是，進入源碼模式和進入彙編模式的命令分別爲：

• 源碼模式：l+t
• 彙編模式：l-t

運行這兩個命令和在Windbg的Debug菜單下點擊source mode選項其效果是一樣的。

3 進程與線程

既可以顯示進程和線程列表，又可以顯示指定進程或線程的詳細信息。調試命令可以提供比taskmgr更詳盡的進程資料，在調試過程中不可或缺。

3.1 進程命令

進程命令包括這些內容：顯示進程列表、進程環境塊、設置進程環境。

進程列表

多個命令可顯示進程列表，但一般只能在特定情況下使用，它們是：|、.tlist、!process和!dml_proc。

豎線命令顯示當前被調試進程列表的狀態信息，這個命令在本章開頭已作過介紹，命令格式如下：

• |  [進程號]

請注意這裏的定語：被調試進程列表。大多數情況下調試器中只有一個被調試進程，但可以通過.attach或者.create命令同時掛載或創建多個調試對象。當同時對多個進程調試時，進程號是從0開始的整數。下圖中顯示了兩個被調試的進程。

如何在多個進程間進行切換呢？使用s參數即可，這一點前文已然講過。

• .tlist [選項] [模塊名]

            .tlist命令顯示當前系統中的進程列表，他是目前唯一可在用戶模式下顯示系統當前進程列表的命令。它有兩個可選項：-v顯示進程詳細信息，-c只顯示當前進程信息。

            內核模式下同樣可以使用.tlist，但更好的命令是!process。!process在內核模式下顯示進程列表，和指定進程的詳細信息，也能顯示進程中的線程和調用棧內容。典型格式如下：

• !process: 顯示調試器當前運行進程信息
• !process 0 0: 顯示進程列表
• !process PID: PID是進程ID，根據進程ID顯示此進程詳細信息。

此外，還有一個DML版本的進程列表命令，如下：

• !dml_proc [進程號|進程地址]

此命令可以看成“|”和“!process”命令的DML合併版本，可在用戶與內核模式下使用。顯示的進程信息偏重於線程和調用棧。用戶模式下此命令和“|”一樣，只能顯示被調試進程的信息。右圖是內核模式下使用此命令的效果：

進程信息

進程環境塊（Process Enviroment Block）是內核結構體，使用!peb命令參看其信息，但也可以用dt命令查看完整的結構體定義。格式如下：

• !peb  [地址]

如果未設置PEB地址，則默認爲當前進程。內核模式下可通過!process命令獲取PEB結構體地址；用戶模式下只能顯示當前進程的PEB信息，故而一般不帶參數。

• dt  nt!_peb  地址

此命令顯示系統nt模塊中所定義的內核結構體PEB詳細內容。使用之前必須先熟悉結構體定義。

進程切換

進程環境的切換，將伴隨着與進程相關的寄存器、堆棧的切換。在不同進程環境中進行的調試結果有天壤之別。上文在講“|”命令的時候，講過用戶環境下多進程間如何互相切換，使用命令：

• |  [進程號]  s

那麼內核模式下，情況又不同了。內核模式下的進程切換，不同於用戶模式下的被調試進程間切換，而是系統存在的多進程間切換。內核環境下，以進程地址作爲參數，調用如下命令以進行進程環境切換：

• .process [進程地址]

如果不使用任何參數，.process命令將顯示當前進程地址。所謂進程地址，即ERPCESS結構體地址。

或以頁目錄地址爲參數，調用下面命令切換用戶地址空間：

• .context [頁目錄地址]

如果不使用任何參數，.context命令將顯示當前頁目錄地址。頁目錄地址就是!process命令中顯示的DirBase值。

進程切換後，爲了檢測是否正確切換，可再用!peb命令檢查當前進程的環境信息。

3.2 線程命令

命令“~”能夠進行線程相關的操作。不帶任何參數的情況下，它列出當前調試進程的線程。下圖是計算器進程某時刻的線程列表：

||0:0:001> ~
#  0  Id: f78.374 Suspend: 0 Teb: 000007ff`fffdc000 Unfrozen
.  1  Id: f78.fb0 Suspend: 0 Teb: 000007ff`fffda000 Unfrozen
   2  Id: f78.a4c Suspend: 0 Teb: 000007ff`fffd8000 Unfrozen
   3  Id: f78.22c8 Suspend: 0 Teb: 000007ff`fff9a000 Unfrozen
   4  Id: f78.2658 Suspend: 0 Teb: 000007ff`fffd4000 Unfrozen
   5  Id: f78.cbc Suspend: 0 Teb: 000007ff`fff96000 Unfrozen
   6  Id: f78.21ec Suspend: 0 Teb: 000007ff`fffd6000 Unfrozen

使用此命令可進行的線程操作包括：線程切換、線程環境、線程時間等。

線程冰凍

參數f與u分別代表freeze和unfress，前者是指凍住指定線程，後者將被冰凍線程解凍。

• ~2f

表示把2號線程凍住，在解凍之前，不再分發CPU時間給它。

若要讓指定線程重新運行，需使用參數u：

• ~2u

針對這兩個命令，下面有一個小實驗：

運行Windbg，並選擇調試記事本程序（Notepad.exe）。程序起來後，CTL+BREAK中斷程序運行，輸入命令： 

~0f 

再輸入g命令讓記事本繼續運行。 

此時嘗試用鼠標定位到notepad軟件，發現軟件界面無法被定位、移動、最大小化，甚至“清空桌面”操作也無濟於事。這是因爲0號線程爲notepad的主線程，被凍住後整個軟件都失去響應。 

更嚴重的是，“清空桌面”操作（Win + D）也會失效，應是Notepad拒絕響應的緣故。

線程掛起 

參數n和m分別代表increase和resume，前者增加一個線程掛起計數，後者減少一個線程掛起計數。如果兩次增加線程掛起計數（即達到2），則必須兩次resume才能讓線程恢復到運行狀態。

把上面實驗中的~0f命令改變成~0n，也能達到相似的效果。

線程切換

查看指定線程的信息，用下面的命令：

• ~ 線程號

線程號是由調試器軟件內部維護的線程ID值，是一個從0開始的整數，和線程ID不是一回事。

線程信息中包括有線程環境塊地址，可通過!teb命令查看環境塊信息：

• !teb  [teb地址]

如要在多線程間作切換，需使用~命令的s參數：

• ~  線程號 s

由於線程號在外部是沒有太大意義的，所以另一個線程切換命令是以線程ID來標識一個線程的。這個命令比較奇怪，以雙波浪線打頭，格式如下：

• ~~[線程ID]  s

注意這個命令中的[]並非可選符，而是命令的一部分。例如命令：~~[11a0] s，它將當前線程切換到線程ID爲0x11a0的線程。線程ID是系統維護的系統唯一的ID值。

下圖是關於線程切換的：

0:014> ~
   0  Id: 4f0.4f4 Suspend: 1 Teb: 00000000`7efdb000 Unfrozen
   1  Id: 4f0.5e0 Suspend: 1 Teb: 00000000`7ef9d000 Unfrozen
   2  Id: 4f0.604 Suspend: 1 Teb: 00000000`7ef9a000 Unfrozen
   3  Id: 4f0.61c Suspend: 1 Teb: 00000000`7ef97000 Unfrozen
   4  Id: 4f0.600 Suspend: 1 Teb: 00000000`7ef94000 Unfrozen
   5  Id: 4f0.610 Suspend: 1 Teb: 00000000`7ef91000 Unfrozen
   6  Id: 4f0.608 Suspend: 1 Teb: 00000000`7ef8e000 Unfrozen
   7  Id: 4f0.60c Suspend: 1 Teb: 00000000`7ef8b000 Unfrozen
   8  Id: 4f0.614 Suspend: 1 Teb: 00000000`7ef88000 Unfrozen
   9  Id: 4f0.5fc Suspend: 1 Teb: 00000000`7ef85000 Unfrozen
  10  Id: 4f0.5f4 Suspend: 1 Teb: 00000000`7ef82000 Unfrozen
  11  Id: 4f0.5f8 Suspend: 1 Teb: 00000000`7ef7f000 Unfrozen
  12  Id: 4f0.f58 Suspend: 1 Teb: 00000000`7ef76000 Unfrozen
  13  Id: 4f0.28e8 Suspend: 1 Teb: 00000000`7efd5000 Unfrozen
. 14  Id: 4f0.1b80 Suspend: 1 Teb: 00000000`7ef79000 Unfrozen
# 15  Id: 4f0.1f80 Suspend: 1 Teb: 00000000`7efd8000 Unfrozen

0:016> ~~[5fc]s
wow64cpu!CpupSyscallStub+0x9:
00000000`74412e09 c3              ret

0:009> ~
   0  Id: 4f0.4f4 Suspend: 1 Teb: 00000000`7efdb000 Unfrozen
   1  Id: 4f0.5e0 Suspend: 1 Teb: 00000000`7ef9d000 Unfrozen
   2  Id: 4f0.604 Suspend: 1 Teb: 00000000`7ef9a000 Unfrozen
   3  Id: 4f0.61c Suspend: 1 Teb: 00000000`7ef97000 Unfrozen
   4  Id: 4f0.600 Suspend: 1 Teb: 00000000`7ef94000 Unfrozen
   5  Id: 4f0.610 Suspend: 1 Teb: 00000000`7ef91000 Unfrozen
   6  Id: 4f0.608 Suspend: 1 Teb: 00000000`7ef8e000 Unfrozen
   7  Id: 4f0.60c Suspend: 1 Teb: 00000000`7ef8b000 Unfrozen
   8  Id: 4f0.614 Suspend: 1 Teb: 00000000`7ef88000 Unfrozen
.  9  Id: 4f0.5fc Suspend: 1 Teb: 00000000`7ef85000 Unfrozen
  10  Id: 4f0.5f4 Suspend: 1 Teb: 00000000`7ef82000 Unfrozen
  11  Id: 4f0.5f8 Suspend: 1 Teb: 00000000`7ef7f000 Unfrozen
  12  Id: 4f0.f58 Suspend: 1 Teb: 00000000`7ef76000 Unfrozen
  13  Id: 4f0.28e8 Suspend: 1 Teb: 00000000`7efd5000 Unfrozen
  14  Id: 4f0.1b80 Suspend: 1 Teb: 00000000`7ef79000 Unfrozen
  15  Id: 4f0.17cc Suspend: 1 Teb: 00000000`7efd8000 Unfrozen
# 16  Id: 4f0.1538 Suspend: 1 Teb: 00000000`7ef7c000 Unfrozen

第一個命令“~”運行時，當前線程是14號線程，請注意3號線程前面有一小點；運行第二個命令，將當前線程切換爲9號線程；爲了檢驗結果，再次運行“~”命令，此時注意到小點移到9號線程前，表明9號線程爲當前線程。 

線程遍歷

仍然是~命令。它除了能夠作爲線程列表命令外，還可用來對線程進行遍歷，並執行指定命令。只需藉助通配符“*”即可。如：

• ~*k

顯示所有線程棧信息（此命令意指：對所有線程執行k指令）。下圖中，當前進程共包含兩個線程，顯示了這兩個線程各自的棧信息：

0:009> ~*k

   0  Id: 4f0.4f4 Suspend: 1 Teb: 00000000`7efdb000 Unfrozen
Child-SP          RetAddr           Call Site
0019e648 74412bf1 wow64cpu!CpupSyscallStub+0x9
0019e650 7448d07e wow64cpu!Thunk0ArgReloadState+0x23
0019e710 7448c549 wow64!RunCpuSimulation+0xa
0019e760 77084956 wow64!Wow64LdrpInitialize+0x429
0019ecb0 77081a17 ntdll!LdrpInitializeProcess+0x17e4
0019f1a0 7706c32e ntdll! ?? ::FNODOBFM::`string'+0x29220
0019f210 00000000 ntdll!LdrInitializeThunk+0xe

   1  Id: 4f0.5e0 Suspend: 1 Teb: 00000000`7ef9d000 Unfrozen
Child-SP          RetAddr           Call Site
00abebc8 74412bf1 wow64cpu!CpupSyscallStub+0x9
00abebd0 7448d07e wow64cpu!Thunk0ArgReloadState+0x23
00abec90 7448c549 wow64!RunCpuSimulation+0xa
00abece0 770be707 wow64!Wow64LdrpInitialize+0x429
00abf230 7706c32e ntdll! ?? ::FNODOBFM::`string'+0x29364
00abf2a0 00000000 ntdll!LdrInitializeThunk+0xe

其他有用的遍歷指令包括：

• ~*r

顯示線程寄存器信息。

• ~*e

上面的e是execute（執行）的縮寫，後可跟一個或多個Windbg命令。它遍歷線程並對每個線程執行指定命令，如：

• ~*e  k;r

此命令意爲：在所用線程環境中（~*），分別執行（e）棧指令（k）和寄存器指令（r）。

線程時間

在軟件調試的時候，若發現某線程佔用執行時間過多，就需要當心是否有問題。線程執行時間的多少，其實就是佔用CPU執行工作的時間多少。某線程佔用越多，此長彼消，則系統中其它線程佔用CPU的時間就越少。

線程的時間信息包括三個方面：自創建之初到現在的總消耗時間、用戶模式執行時間、內核模式執行時間。需注意的是，消耗時間一定會遠遠大於用戶時間+內核時間，多出來的是大量空閒時間（爲Idle進程佔用）。使用下面的命令查看線程時間：

• .ttime
• !runaway 7

在!runaway命令中加入標誌值7，將顯示線程的全部三種時間值。

這兩個命令的區別之處是，.ttime只能顯示當前線程的時間信息，!runaway能顯示當前進程的所有線程時間。下圖是這兩個命令的使用情況：

0:009> .ttime
Created: Wed Aug  7 16:47:29.011 2013 (UTC + 8:00)
Kernel:  0 days 0:00:00.031
User:    0 days 0:00:00.046
0:009> !runaway 7
 User Mode Time
  Thread       Time
   2:604       0 days 0:00:51.729
   4:600       0 days 0:00:47.159
   0:4f4       0 days 0:00:00.031
   3:61c       0 days 0:00:00.000
   1:5e0       0 days 0:00:00.000
 Kernel Mode Time
  Thread       Time
   4:600       0 days 0:13:45.073
   2:604       0 days 0:08:44.100
   3:61c       0 days 0:00:00.000
   1:5e0       0 days 0:00:00.000
   0:4f4       0 days 0:00:00.000
 Elapsed Time
  Thread       Time
   0:4f4       16 days 0:14:02.254
   4:600       16 days 0:14:02.207
   3:61c       16 days 0:14:02.207
   2:604       16 days 0:14:02.207
   1:5e0       16 days 0:14:02.207

            對上二圖進行對比，能看出兩個命令之間的功能差異。

3.3 異常與事件

在調試器語境中，事件是一個基本概念，Windbg是事件驅動的。Windows操作系統的調試子系統，是“事件”的發生源。調試器的所有操作，都是因事件而動，因事件被處理而中繼。Windows定義了9類調試事件，異常是其中一類（ID爲1）。所以異常和事件，這二者是前者包含於後者的關係。

系統對各種異常和調試事件進行了分類，執行sx命令可以列出針對當前調試目標的異常或非異常事件的處理。下面是一個片段：

0:009> sx
  ct - Create thread - ignore
  et - Exit thread - ignore
 cpr - Create process - ignore
 epr - Exit process - break
  ld - Load module - break
       (only break for livekd.exe)
  ud - Unload module - ignore
 ser - System error - ignore
 ibp - Initial breakpoint - break
 iml - Initial module load - ignore
 out - Debuggee output - output

  av - Access violation - break - not handled
asrt - Assertion failure - break - not handled
 aph - Application hang - break - not handled
 bpe - Break instruction exception - break
bpec - Break instruction exception continue - handled
  eh - C++ EH exception - second-chance break - not handled
 clr - CLR exception - second-chance break - not handled
clrn - CLR notification exception - second-chance break - handled
 cce - Control-Break exception - break
  cc - Control-Break exception continue - handled
 cce - Control-C exception - break
  cc - Control-C exception continue - handled
  dm - Data misaligned - break - not handled
dbce - Debugger command exception - ignore - handled
  gp - Guard page violation - break - not handled
  ii - Illegal instruction - second-chance break - not handled
  ip - In-page I/O error - break - not handled
  dz - Integer divide-by-zero - break - not handled
 iov - Integer overflow - break - not handled
  ch - Invalid handle - break
  hc - Invalid handle continue - not handled
 lsq - Invalid lock sequence - break - not handled
 isc - Invalid system call - break - not handled
  3c - Port disconnected - second-chance break - not handled
 svh - Service hang - break - not handled
 sse - Single step exception - break
ssec - Single step exception continue - handled
 sbo - Security check failure or stack buffer overrun - break - not handled
 sov - Stack overflow - break - not handled
  vs - Verifier stop - break - not handled
vcpp - Visual C++ exception - ignore - handled
 wkd - Wake debugger - break - not handled
 rto - Windows Runtime Originate Error - second-chance break - not handled
 rtt - Windows Runtime Transform Error - second-chance break - not handled
 wob - WOW64 breakpoint - break - handled
 wos - WOW64 single step exception - break - handled

   * - Other exception - second-chance break - not handled

可以看到這幾個調試事件，當發生進程退出（Exit Process）和初始化斷點（Initial breakpoint）事件的時候，調試器應當被中斷（Break）。模塊加載（Load Modual）以及有調試輸出（Debuggen Output）時，需要輸出相關信息；其他的都被忽略掉，不做處理(Ignore)。     我們分析一下前兩個事件。使用調試器調試記事本進程時，不管是用.attach掛載方式還是.create創建方式，在調試器正式侵入記事本進程前，都會有一箇中斷（Initial breakpoint異常）；調試開始後運行一段時間，在外面將記事本關閉，又會發生一箇中斷（Exit Process異常）。

可以通過Debug|Event Filters…打開事件設置對話框。這個對話框中列出了全部調試事件，用戶可分別對它們進行設置。

            這個對話框列出了對於當前調試會話可用的全部調試事件。針對每個調試事件，可設置其屬性。右列Execution和Continue兩組單選鍵，分別表示事件的中斷屬性與中繼屬性。右列Argument按鈕可設置調試事件執行參數（上圖中Load Module事件有一個Kernel32.dll參數，即當Kernel32.dll模塊被加載時，調試器將被中斷），Commands按鈕可設置事件兩輪機會發生時的執行命令。

更細緻的內容，本章無力鋪陳，請讀者參閱《Windows 高級調試》（Mario & Daniel 2009 機械工業出版社）第三章，及《軟件調試》（張銀奎 2008 電子工業出版社）第9、30章相關內容。 

sxr:

      此命令將當前所有對調試事件的設置，恢復到調試器的默認設置。最後一個字母r表示Reset。

sx{e|d|n|i}：

      這4個命令分別代表了圖8-38中Execution組（中斷屬性）中的四個按鈕，即Enable、Disable、Output、Ignore。Enable是開啓中斷，Disable是禁止事件中斷（但對於異常，只禁止第一輪機會，第二輪機會到來時仍會中斷到調試器），Output是禁止中斷但會輸出相關信息，Ignore表示完全忽略這個事件（對於異常，Output和Ignore兩選項使得兩輪機會都不會中斷到調試器）。

sx{e|d|n|i} -h：

      上述命令如果帶上-h選項，就不是設置中斷屬性，而是設置中繼屬性了。對應了圖8-38中的Continue組。其中sxe –h表示Handled，se{d|n|i} –h都表示Not Handled。

      下面繼續介紹異常、事件相關的其他調試命令：

.lastevent:

顯示最近發生的一個調試事件，往往是導致中斷髮生的那個。下圖顯示的是一個很典型的初始化斷點引發的中斷事件。

.exr:

      此命令顯示一個異常記錄的詳細內容，傳入一個異常記錄地址：

• .exr 記錄地址

如果僅僅爲了顯示最近的一條異常記錄，可以用-1代替異常記錄地址：

• .exr -1

由於異常是事件的一種，所以使用.exr -1命令得到的異常，可能和使用.lastevent命令獲取的事件（其實是異常），是同一個。但二者顯示的信息各有側重點。請對照圖8-39看下面，同樣的初始化斷點異常，使用.exr命令時所顯示的信息：

0:009> .lastevent
Last event: 4f0.1538: Break instruction exception - code 80000003 (first chance)
  debugger time: Fri Aug 23 16:58:02.995 2013 (UTC + 8:00)

還有一個類似的命令：!cppexr，他分析並顯示一個C++異常信息。

.bugcheck：

此命令不帶參數。在內核環境下，顯示當前bug check的詳細信息；可用於活動調試或者crash dump調試環境中。用戶環境不可用。見下圖：

0:009> .exr -1
ExceptionAddress: 0000000077090530 (ntdll!DbgBreakPoint)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 1
   Parameter[0]: 0000000000000000 

!analyze:  

此命令分析當前最近的異常事件（如果在進行dump分析，則是bug check），並顯示分析結果。這個異常事件，就是上面.lastevent命令對應的事件。

• -v：顯示異常的詳細信息，這個選項在調試錯誤的時候，最有用。
• -f：f是force的縮寫。強制將任何事件都當作異常來分析，即使僅僅是普通的斷點事件。將因此多輸出一些內容。
• -hang：這個選項很有用，對於遇到死鎖的情況，它會分析原因。在內核環境中，它分析內核鎖和DPC棧；在用戶環境中，它分析線程的調用棧。用戶環境中，調試器只會對當前線程進行分析，所以一定要將線程環境切換到最可能引起問題的那個線程中去，纔有幫助。這個參數非常有用，當真的遇到死鎖時，它可以救命（另一個分析死鎖的有效命令是!locks）。
•  -show bug-check-代碼 [參數]：在內核環境下，顯示指定的bug check的詳細信息。

!error:

此命令和VC裏面內置的errlook工具類似（請有興趣的讀者使用作者編寫的免費軟件e-look，它比errlook功能更好且易於使用）。用來根據錯誤碼，查看對應的可讀錯誤信息。微軟系統中常用的全局錯誤碼有兩套，一套是Win32錯誤碼，通過函數GetLastError()獲得的值；另一套是NTSTATUS值。!error命令對這二者都能支持。區別的方法，若錯誤碼後面無參數1，則爲win32錯誤碼；否則就是NTSTATUS錯誤碼。

            比如，獲取錯誤碼爲2的Win32錯誤信息，可用：!error 2

            獲取錯誤碼爲2的NTSTATUS錯誤信息，可用：!error 2 1 

!gle:

此命令是Get Last Error的縮寫。它調用Win32接口函數GetLastError()取得線程的錯誤值，並打印分析結果。如果帶有-all選項，則針對當前進程的所有線程（內核環境下爲所有用戶線程）執行GetLastError()操作；否則僅針對當前線程。

gh/gn：這兩個命令是g命令的擴展。

            gh是go with Exception handled的縮寫，意思是：把異常標識爲已處理而並繼續執行程序；注意這裏面的措辭，僅僅把異常“標識爲”已處理，而並非真的被處理了。gh的作用在於，當遇到某個可以忽略的非致命異常時，將它先放過一邊，而繼續執行程序。

            而gn是go with Exception not handled的縮寫，意思是，對異常不進行任何處理，而繼續執行程序。這時候，程序自己的異常處理模塊將有機會處理異常。

3.4 局部變量

有兩個命令可以打印當前的局部變量列表：x 和dv。x命令前文已經講過。dv是Display local Variable的縮寫。下面是對一段簡單的Win32控制檯代碼獲取其局部變量的情況：

            上圖無法體現dv比x命令在顯示局部變量上的高明之處。dv命令有幾個開關選項，介紹如下：

•             /v：顯示虛擬地址（virtual）；
•             /i：顯示變量詳細信息（information），包括局部變量、全局變量、形參、函數變量等。
•             /t：顯示變量類型（type），如int、char等等。
•             /f：可指定進行分析的函數，需指定函數名。

         命令中選項/f wmain是指針對wmain函數（即_tmain）分析其局部變量。看第一個變量argc，“prv param”對應/i開關選項；“@ebp+0×08”對應/v開關選項；“int”對應/t開關選項。

3.5 顯示類型

            利用dt命令可以查看結構體的類型定義。命令dt是Display Type的縮寫。當我們要查看一些內核結構體的定義時，dt命令是最直接有效的手段。

4. 斷點

4.1 軟件斷點

軟件斷點的本質是代碼改寫，即：將INT 3（代碼爲0xCC）指令替換到斷點所在指令處（第一個字節），並保存被替換掉的代碼（即一個字節內容）。等執行到斷點處時，調試器將因斷點而中斷，並將被替換的一字節內容恢復到原內存中。其原理和代碼補丁是一樣的。

源碼或彙編模式下，最簡單的斷點設置方式，是定位到正確的代碼處，並按下F9鍵。此外還有三種設置軟件斷點的指令，分別講解如下：

bp：

命令bp是BreakPoint的縮寫。其指令格式如下：

bp[ID] [Options] [Address [Passes]] ["CommandString"]

參數Address表示需設置斷點的地址，缺省情況下使用當前指令指針（EIP）的地址。ID是斷點號，一般不手動設置，由調試器內部編號。Passes是一個整數值，即第幾次經過斷點所在代碼時，調試器才需要中斷執行，默認爲1，即每次都中斷。CommandString用來設置一組命令，當斷點發生的時候，就執行這一組命令，比如可以把它設置爲“k”，這樣斷點處就會輸出當前的調用棧。

Options是一組可選開關項，有下面幾種：

/1：即阿拉伯數字1。這個選項表明這個被設置的斷點只會在第一次有效，此後斷點信息即被刪除。

/p：這個開關項後跟一個EPCOESS結構體指針，只能用在內核調試環境下。內核調試環境下，如果要把斷點設置到用戶程序地址（即用戶空間地址），需要使用這個開關，因爲用戶地址是進程相關的。

/t：這個開關項後跟一個ETHREAD結構體指針，只能用在內核調試環境下。此開關項與/p起到類似的作用，只不過前者定位到進程，後者更進一步定位到線程。

/c與/C：c或者C代表CallStack（調用棧）。這兩個開關項和調用棧深度有關，都後跟一個整數值。前者表示調用棧深度如果小於這個整數值，斷點纔會引發中斷，後者表示調用棧深度如果大於這個整數值，斷點纔會引發中斷。

bu：

此命令格式與bp類似，u代表了Unresolved。使用此命令設置的斷點雖登記到調試器，但它具體對應到哪處代碼或指令，尚未確定。

比如某EXE程序使用動態加載的方式加載DLL（使用函數LoadLibrary()），那麼當DLL尚未加載時，就可用bu指令設置DLL中的代碼斷點，等到DLL加載時，調試器再正式落實此斷點。

bm：

此命令用來批量設置代碼斷點，它帶有一個通配符字符串，凡是符合通配符格式的地址都將被設置斷點，如：

• bm /a ntdll!NtCreate*File

則諸如NtCreateFile\NtCreateMailslotFile\NtCreateNamedPipeFile等函數都將被設置斷點。

4.2 硬件斷點

硬件斷點的原理和軟件斷點完全不同，硬件斷點是通過CPU的斷點寄存器來實現的，亦即依靠硬件方式實現。由於CPU的調試寄存器數量是有限的，所以能設置的硬件斷點數量也是有限的。設置硬件斷點的命令是ba，a代表了Address。指令格式如下：

ba[ID] Access Size [Options] [Address [Passes]] ["CommandString"]

參數ID、Options、Passes及CommandString，含義與前文bp指令相同，此處不述。

參數Address是內存地址，有別於前文的指令地址，內存地址既可以是指令地址，也可以是數據地址。缺省爲當前指令寄存器地址（EIP）。參數Size表示地址長度，x86系統可選值爲1、2、4，X64系統可選值爲1、2、4、8。需要注意的是，Address地址必須對齊到Size，即Address值必須是Size的整數倍。參數Access是內存訪問類型，有下面幾種：

e：作爲指令執行；r：讀，或者寫；w：寫；i：執行IN/OUT操作。     比如：

• ba r4 @ebp-0×08

地址@ebp-8一定是一個局部變量地址，所以當CPU對這個局部變量執行讀寫操作時，將引發硬件中斷。

4.3 其他操作

            其他的斷點操作包括：顯示斷點列表、禁止或恢復斷點、刪除斷點等。

• bl：列出所有斷點
• bd：禁止斷點，d代表Disable。如bd 1，禁止斷點1。斷點被禁止後將不起作用，但亦未刪除。
• be：恢復斷點，e代表Enable。恢復被禁止的斷點。如be 1恢復1號斷點。
• bc：清除斷點，如：bc 1，清除斷點1；bc *，清除全部斷點。
• br：序號管理，r代表ReNumber，即重新排序。如：br 2 0，將2號斷點重設爲0號斷點。

5. 內存命令

這一節裏面，我們學習如何查看內存信息。內存是存儲數據、代碼的地方，通過內存查看命令可以分析很多問題。相關命令可以分爲：內存查看命令和內存統計命令。內存統計命令用來分析內存的使用狀況。

5.1 查看內存

            有非常豐富的內存查看命令，它們被統一爲d*格式，如下所示：

• d[類型]  [地址範圍]

            d代表Display，類型包括：字符、字符串、雙字等。具體來說，d*命令共有這幾種：d、 da、db、dc、dd、dD、df、dp、dq、du、dw、dW、dyb、dyd、ds、dS。解釋如下：

內存類型 

基本類型：

• dw = 雙字節WORD格式；
• dd = 4字節DWORD格式 ；
• dq = 8字節格式；
• df = 4字節單精度浮點數格式；
• dD =8字節雙精度浮點數格式；
• dp = 指針大小格式，32位系統下4字節，64位系統下爲8字節。

基本字符串：

• da = ASCII字符串格式；
• du = UNICODE字符串格式；
• db =字節 + ASCII字符串；
• dW = 雙字節WORD + ASCII字符串；
• dc = 4字節DWORD + ASCII字符串。

高級字符串：

• ds = ANSI_STRING類型字符串格式；
• dS = UNICODE_STRING類型字符串格式。

二進制 + 基本類型：

• byb = 二進制 + 字節；
• byd = 二進制 + DWORD值

如果讀者對此感覺不明白，特別是組合模式究竟是何種情形？看下例應能清楚。下例將同一個ASCII字符串，分別以ASCII字符串、Unicode字符串以及組合模式等共五種方式顯示：

此係列命令還有一些可加利用的開關選項，介紹如下：

/c 列數：指定列數。默認情況下，列數 等於16除以列長，如dd命令的默認列數即爲4列（=16/4）。例：

• dd  /c  8

此命令每列顯示8個DWORD數，即32字節內容。

/p：此選項用來顯示物理內存信息，只能用於內核模式中。不使用此命令時，都將顯示虛擬內存信息。如：

• d  /p  [地址範圍]

L 長度: 默認情況下，d命令只顯示固定長度的內存，一般爲128或64字節。L可指定長度，如下面的命令將顯示地址0×80000000開始處的0×100個字節內容：

• db  0×80000000  L100 

數組形式內存

難能可貴的是，d*命令還能夠以數組形式顯示一段內存信息，包括：dda, ddp、 ddu、dds、dpa、dpp、dpu、dps、dqa、dqp、dqu、dqs。

何謂“以數組形式顯示”呢？這一組命令能夠將指定地址處的內容，作爲一系列指針，進而顯示指針所指處內容。聽上去有點拗口吧，讀者這樣想會清楚些：前一組命令顯示address值，本節這一組命令顯示*address值。

程序代碼中如有類似“char *array[10]”的數組變量，可使用這些命令顯示數組內容。下面會有例子。這一系列命令實則由第一組命令演化而來，可分爲三組：

• 4字節DWORD爲單位的dd*系列數組指令；
• 指針長度爲單位的dp*系列數組指令；
• 8字節爲單位的dq*系列數組指令。

查看鏈表內存

            最後，d*命令的另一個變體是以鏈表形式顯示內存內容。命令如下：

• dl  開始地址

默認情況下，以正向從頭到尾遍歷鏈表；也可反向（由尾向頭）遍歷，指定b開關選項：

• dl  b  尾地址

應注意的是，命令dl是Display List的縮寫，這裏的鏈表不能是用戶自定義的鏈表，而專指符合LIST_ENTRY或SINGLE_LIST_ENTRY格式的鏈表。

5.2 內存信息

系統的內核空間很大的，想知道這麼廣大的內存空間裏面都有些什麼東西嗎？想要知道一個內存地址，到底是被一個內核棧使用着，亦或被堆管理器使用着嗎？我們這一節就領大家看看內存的地理概況。首先看Address命令：

• !address  [地址]

            顯示進程或系統的內存狀態、信息，!address是最好的工具。不加任何參數，在用戶模式下此命令將以內存塊爲單位，列出從地址0開始到0×80000000（略小於）的全部地址空間信息；內核模式下，將列出從地址0×80000000開始到0xFFFFFFFF（略小於）的全部地址空間信息；如指定地址值，則將顯示此地址所在內存塊的內存信息（此命令在Vista以後系統中，不能在內核模式下正常使用，此Bug應會在Windbg的以後版本中被修正）。下面分別截取了用戶與內核空間中的內存信息片段：

0:009> !address                            

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
------------------------------------------------------------------------------------------------------------------------
+        0`00000000        0`00010000        0`00010000             MEM_FREE    PAGE_NOACCESS                      Free       
+        0`00010000        0`00020000        0`00010000 MEM_MAPPED  MEM_COMMIT  PAGE_READWRITE                     Heap64     [ID: 1; Handle: 0000000000010000; Type: Segment]
+        0`00020000        0`00021000        0`00001000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       
+        0`00021000        0`00030000        0`0000f000             MEM_FREE    PAGE_NOACCESS                      Free       
+        0`00030000        0`00031000        0`00001000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                       
// 省略很多...

            上圖截取了兩段用戶區內存，第一段從0開始，長度0×10000，狀態爲釋放（FREE），表明這一段地址空間不可用；第二段從0×10000開始，長度0×1000，屬於私有內存，狀態爲已提交，保護模式爲可讀寫，此內存塊被用於環境塊。

下面給大家解釋一下內存塊中的幾個值：

內存類型：即Type值，共有四種：第一種是什麼都不是，即尚未被使用的；第二種是MEM_IMAGE，即地址映射於一個可執行鏡像文件片段，如DLL文件；第三種是MEM_ MAPPED，即地址映射於不可執行的鏡像文件片段，如頁文件；第四種是MEM_PRIVATE，即私有有內存，這裏的私有是針對進程而言的，私有內存無法在多個進程間共享；

保護模式：即Protect值，上例中見識了兩種保護模式，NOACCESS和READWRITE。從字面即很容易理解其意思，前者是不能做任何訪問的，因爲空閒內存是無效內存；後者則可讀可寫，但不能執行，說明是保存數據的地方。所有可用的保護包括：PAGE_NOACCESS（不可訪問），PAGE_READONLY（只讀），PAGE_READWRITE（讀寫），PAGE_EXECUTE（可執行）， PAGE_EXECUTE_READ（執行並可讀），PAGE_EXECUTE_READWRITE（執行並可讀寫），PAGE_WRITECOPY（寫時拷貝），PAGE_EXECUTE_WRITECOPY（執行，並寫時拷貝）， PAGE_GUARD（保護）。

內存狀態：即State值，共三種：MEM_FREE，即空閒內存；MEM_RESERVED，即保留內存，保留內存尚不能被實際使用，但其地址空間已被預留，尚需一個提交動作。最後是MEM_COMMIT，即內存已被提交，正在被使用。

內存用途：即Usage值，有這樣一些值和用途。RegionUsageIsVAD：表示此地址區域已被分配；RegionUsageFree：代表此地址區域已被釋放，既沒有保留也沒有被提交，將來可以申請使用；RegionUsageImage：代表此地址區域被映射到二進制文件的鏡像；Region UsageStack：代表此地址區域用於線程棧；RegionUsageTeb：代表此地址區域用於保存目標進程的所有線程的TEB結構；RegionUsageHeap：代表此地址區域用於堆內存；RegionUsage Pdb：代表此地址區域用於保存目標進程的PEB結構；RegionUsageProcessParameters：代表此內存塊用於保存目標進程的啓動參數；RegionUsageEnviromentBlock：代表此地址區域用於保存目標進程的環境塊。

用戶環境下可使用下面的命令顯示內存統計信息，包括內存用途、內存類型、內存狀態。

• !address  -summary

0:009> !address  -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    101        0`7a5ba000 (   1.912 Gb)           95.60%
Image                                   294        0`022b8000 (  34.719 Mb)  38.49%    1.70%
                                 7        0`0113a000 (  17.227 Mb)  19.10%    0.84%
Stack32                                  51        0`01100000 (  17.000 Mb)  18.84%    0.83%
Heap32                                   26        0`006e0000 (   6.875 Mb)   7.62%    0.34%
MappedFile                               12        0`0069e000 (   6.617 Mb)   7.34%    0.32%
Stack64                                  51        0`00440000 (   4.250 Mb)   4.71%    0.21%
Other                                     8        0`001c1000 (   1.754 Mb)   1.94%    0.09%
Heap64                                    9        0`00190000 (   1.563 Mb)   1.73%    0.08%
TEB64                                    17        0`00022000 ( 136.000 kb)   0.15%    0.01%
TEB32                                    17        0`00011000 (  68.000 kb)   0.07%    0.00%
PEB64                                     1        0`00001000 (   4.000 kb)   0.00%    0.00%
PEB32                                     1        0`00001000 (   4.000 kb)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE                             181        0`02f11000 (  47.066 Mb)  52.17%    2.30%
MEM_IMAGE                               295        0`022b9000 (  34.723 Mb)  38.49%    1.70%
MEM_MAPPED                               18        0`0086c000 (   8.422 Mb)   9.34%    0.41%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                101        0`7a5ba000 (   1.912 Gb)           95.60%
MEM_RESERVE                              94        0`02f5d000 (  47.363 Mb)  52.50%    2.31%
MEM_COMMIT                              400        0`02ad9000 (  42.848 Mb)  47.50%    2.09%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_EXECUTE_READ                        56        0`01414000 (  20.078 Mb)  22.26%    0.98%
PAGE_READONLY                           129        0`0117a000 (  17.477 Mb)  19.37%    0.85%
PAGE_READWRITE                          153        0`004b5000 (   4.707 Mb)   5.22%    0.23%
PAGE_WRITECOPY                           26        0`0004c000 ( 304.000 kb)   0.33%    0.01%
PAGE_READWRITE|PAGE_GUARD                34        0`00048000 ( 288.000 kb)   0.31%    0.01%
PAGE_EXECUTE_READWRITE                    2        0`00002000 (   8.000 kb)   0.01%    0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free                                      0`030b0000        0`6cf40000 (   1.702 Gb)
Image                                     0`75d71000        0`00879000 (   8.473 Mb)
                                 0`7f0e0000        0`00f00000 (  15.000 Mb)
Stack32                                   0`00cd0000        0`000fd000 (1012.000 kb)
Heap32                                    0`02f13000        0`0019d000 (   1.613 Mb)
MappedFile                                0`01a90000        0`002cf000 (   2.809 Mb)
Stack64                                   0`00160000        0`00039000 ( 228.000 kb)
Other                                     0`006b0000        0`00181000 (   1.504 Mb)
Heap64                                    0`02b90000        0`000bf000 ( 764.000 kb)
TEB64                                     0`7ef76000        0`00002000 (   8.000 kb)
TEB32                                     0`7ef78000        0`00001000 (   4.000 kb)
PEB64                                     0`7efdf000        0`00001000 (   4.000 kb)
PEB32                                     0`7efde000        0`00001000 (   4.000 kb)

上圖分別以內存使用、內存類型、內存狀態顯示用戶空間內存統計信息。

和!address命令類似的，用戶模式下還有下面兩個命令可用：

• !vprot  [地址]
• !vadump  [-v]

命令!vprot顯示指定內存塊的信息，側重於內存保護信息；命令!vadump顯示整個內存空間信息，dump者傾瀉也，開啓-v選項將顯示詳細（Verbose）信息。

上面講過，用戶環境下使用“!address  –summary”可顯示用戶空間的內存統計信息；現在再看兩個內核命令，在內核環境下顯示內存的統計信息：

• !memusage

此命令從物理內存角度顯示內存統計信息。無數個頁表信息將被打印出來，可以說是“最內存”的信息。此命令會查看所有的頁幀，所以運行時會非常地耗時。

• !vm

此命令從虛擬內存的角度顯示內存統計信息，不僅能從全局角度顯示虛擬內存的使用情況，還能以進程爲單位顯示內存使用情況。

5.3 其他命令

內核模式下，查看文件緩存信息，命令格式如下：

• !filecache

            此命令在用戶內核模式下，顯示文件緩存和頁表狀態。每一行信息表示一個虛擬地址控制塊 (VACB)。虛擬地址控制塊可能對應着一個命名文件，也可能對應着一個元數據塊。如果對應着一個命名文件，則此文件名稱將被顯示，否則顯示元數據名稱。

實驗：查看文件緩存

很多軟件都使用文件緩存的方式保存數據，比如Office Word。直接查看WORD文檔，由於其
內部格式不透明，故而不便分析。但如果使用WORD打開一個txt文本文檔，它就會以文本文檔
的方式來處理之，並且依舊使用文件緩存的方式。

讀者用WORD打開一個TXT文檔（比如：測試.txt）。
運行內核調試器並執行!filecache命令，在打印信息中查找“測試.txt”。

用戶模式下查看堆信息，命令格式如下：

• !heap

下面的清單顯示了某個進程中共有4個堆：

0:004> !heap -a
Index   Address  Name      Debugging options enabled
  1:   00150000
    Segment at 00150000 to 00250000 (00031000 bytes committed)

  2:   00250000
    Segment at 00250000 to 00260000 (00006000 bytes committed)

  3:   00260000
    Segment at 00260000 to 00270000 (00003000 bytes committed)

  4:   00390000
    Segment at 00390000 to 003a0000 (00008000 bytes committed)
    Segment at 01370000 to 01470000 (0007b000 bytes committed)

            堆資源是屬於進程的，每個進程都會創建若干個堆，如C運行時堆、進程默認堆等。以第一個堆爲例，地址範圍是[0x150000，0x250000]，已經有0×31000個字節被申請提交。

6 小結

本文到此結束。筆者並非調試方面的專家，斗膽寫了這許多內容，深心惶恐。本章主要着重於基礎知識，和基本指令的介紹，未免掛一漏萬，遺漏了許多有用指令。此外本書亦未能深入到調試原理、應用技巧等高級主題，國內著名的調試專家張銀奎老師所著的《軟件調試》（電子工業出版社 2008），是希望深入學習調試技術的讀者首選之作。

注：本文是筆者寫作的《竹林蹊徑》一書第8章經整理後所發表。