转载注明>> 【作者：张佩】【原文：】

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]

||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)

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

2.2 模块信息

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) <公司名>。保留所有权利。

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

模块相关的知识点讲完了，下面讲符号有关命令。和符号相关的知识点包括：符号路径、符号服务器、符号缓存、符号加载以及符号的使用等。

2.3 符号路径

什么是符号路径呢？就是调试器寻找符号文件的方向，它可以是本地文件夹路径、可访问的UNC路径、或者是符号服务器路径。什么是符号服务器呢？如果调试过程中，需要涉及到成千上万个符号文件，以及同一个符号文件存在不同平台下的不同符号文件版本的时候，那么一一手动设置符号路径肯定是不现实的，于是引入符号服务器的概念。符号服务器有一套命名规则，使得调试软件能够正确找到需要的符号文件。一般来说，符号服务器比较大，都是共用的，放在远程主机上。为了降低网络访问的成本，又引入了符号缓存的概念，即将从服务器上下载到的符号文件，保存在本地缓存中，以后调试器需要符号文件的时候，先从缓存中寻找，找不到的时候再到服务器上下载。下面分几部分一一来看。

设置符号路径：

设置符号路径的语法如下：

• .sympath  [+]  [路径]

如果不加入任何参数执行.sympath命令，将显示当前的路径设置：

• .sympath

如要覆盖原来的路径设置，使用新路径即可：

• .sympath  <新路径>

要在原有路径的基础上添加一个新路径，可使用：

• .sympath+  <新增路径>

要注意的是，使用.sympath改变或新增符号路径后，符号文件并不会自动更新，应再执行.reload命令以更新之。

这里要谈一谈延迟加载的知识点。延迟加载使得模块的符号表，只在第一次真正使用的时候才被加载。这加快了程序启动，不用在一开始耗费大量时间加载全部的符号文件。

使用.symopt +4和.symopt -4来开启或关闭延迟加载设置。

在已经启动了延迟加载的情况下，如想临时改变策略，立刻将指定模块的符号加载到调试器中，可以使用ld或者.reload /f命令。

符号服务器与符号缓存：

设置符号服务器的基本语法是：

• SRV*[符号缓存]*服务器地址

语法由SRV引导，符号缓存和服务器地址的前面各有一个星号引导。符号缓存一般也叫做下游符号库。如某公司有一台专门的符号服务器，地址为，则他们公司的所有开发人员都应该在他们的调试器中使用类似下面的命令：

• .sympath+ srv*c:\symbols*\\symsrv\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

可用的符号选项请见下表：

表8-1 符号选项

2.4 符号加载

本节分下面几个子题目分别讲解。

立刻加载：

其命令格式如下：

• ld 模块名 [/f 符号文件名]

加载指定模块的符号。调试器默认采用延迟模式加载符号，也就是直到符号被使用的时候，才将符号文件加载到调试器中并进行解析。ld使得延迟模式被打破，让指定模块的符号文件立刻加载到调试器中。此指令可为模块的符号文件设置自定义的匹配名称，比如：

• ld  123  /f  abc

这样一来，abc.pdb将成为123.exe的符号文件。正常情况下，这是不可能的，只能是abc.pdb对应abc.exe。

重新加载：

如果对自己正在使用的符号文件感到疑惑，比如源代码和行号明显不匹配，最好的做法就是重新加载一下符号文件。此命令语法如下：

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

符号验证：

上面讲到.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 源码命令

如果含有源码信息，可使得调试过程能够以源码模式逐行进行。和源码相关的命令包括下面几个： 

            值得注意的是，进入源码模式和进入汇编模式的命令分别为：

• 源码模式：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在内核模式下显示进程列表，和指定进程的详细信息，也能显示进程中的线程和调用栈内容。典型格式如下：

• !dml_proc [进程号|进程地址]

进程信息

进程环境块（Process Enviroment Block）是内核结构体，使用!peb命令参看其信息，但也可以用dt命令查看完整的结构体定义。格式如下：

进程切换

进程环境的切换，将伴随着与进程相关的寄存器、堆栈的切换。在不同进程环境中进行的调试结果有天壤之别。上文在讲“|”命令的时候，讲过用户环境下多进程间如何互相切换，使用命令：

• |  [进程号]  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

使用此命令可进行的线程操作包括：线程切换、线程环境、线程时间等。

线程冰冻

运行Windbg，并选择调试记事本程序（Notepad.exe）。程序起来后，CTL+BREAK中断程序运行，输入命令： 

~0f 

再输入g命令让记事本继续运行。 

此时尝试用鼠标定位到notepad软件，发现软件界面无法被定位、移动、最大小化，甚至“清空桌面”操作也无济于事。这是因为0号线程为notepad的主线程，被冻住后整个软件都失去响应。 

更严重的是，“清空桌面”操作（Win + D）也会失效，应是Notepad拒绝响应的缘故。

线程挂起 

参数n和m分别代表increase和resume，前者增加一个线程挂起计数，后者减少一个线程挂起计数。如果两次增加线程挂起计数（即达到2），则必须两次resume才能让线程恢复到运行状态。

把上面实验中的~0f命令改变成~0n，也能达到相似的效果。

线程切换

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

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

• .ttime
• !runaway 7

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 异常与事件

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