WinDbg中文调试手册：从用户模式调试到崩溃转储分析

简介：这份《WinDbg 中文调试手册》面向需要分析故障转储、调试用户模式与内核模式代码的开发者、驱动工程师及系统管理员，也可供准备深入理解 Windows 调试机制的中高级技术人员查阅。内容围绕 WinDbg 的安装与更新、支持的系统与处理器架构、预览版迁移、故障排查与反馈渠道展开，并延伸至 KD、NTKD、CDB、NTSD 等命令行调试器、符号文件、蓝屏与崩溃转储分析、调试环境中的主机与目标机划分，以及 Visual Studio 与 WDK 相关调试环境的选择。资源包为单个 PDF 文件，压缩包约 79.77MB，适合离线阅读和按章节检索。目前已有 1117 人学习，可作为查阅 WinDbg 功能体系、梳理调试工具链和建立排错思路的中文参考。

1. 从一个蓝屏说起：WinDbg 到底是干什么用的

程序跑到一半突然消失，屏幕上只剩一个错误码；或者电脑毫无征兆地蓝屏重启，重启之后一切正常，仿佛刚才什么都没发生。这种时候多数人的第一反应是「再打开一次试试」，试完发现又能用了，事情就翻篇了——真正的问题被留在原地，下次换个时间再炸一遍。WinDbg 就是专门对付这类「说不清哪里坏了」的工具，而这份WinDbg 中文调试手册做的事，是把它的英文命令和满屏术语，翻译成你能看懂的话。

WinDbg 是 Windows 平台上的调试器，能干三件事：分析程序崩溃后留下的转储文件、在程序运行时盯着它一步步执行、查看 CPU 寄存器和内存里到底存了什么。它不像普通软件那样双击就出结果，第一次打开只看到一个空白的命令行窗口，很多人就卡在这一步放弃了。

这份手册不是给熟手查命令用的，它假设你连「断点」「符号」都没听过。所以下面不会一上来就讲原理，而是先让你明白它解决什么麻烦，再手把手跑通两个例子。跑完你会发现，那些看起来像黑匣子的崩溃现场，其实是有迹可循的。

2. 为什么值得学：先把「用户模式、内核模式、符号」这三件事搞明白

写代码的人几乎都遇到过这种场景：线上程序偶尔挂掉一次，日志里只有一句「程序异常退出」，没有任何有用信息，最后只能靠猜和重启撑过去。调试器的价值就在这儿——它不猜，它给你证据。但证据要用得上，得先听懂它说的三句「行话」，否则装好了也只会对着窗口发呆。

2.1 为什么一个命令行窗口值得专门花时间学

新手最常见的疑问是：都有日志了，为什么还要学一个黑底白字的命令行工具？因为日志是你提前想到要记的东西，而崩溃往往发生在你没想到的地方。日志能告诉你「程序在第 300 行附近出错了」，调试器能告诉你「崩在哪个函数、它的参数是什么、是谁调用的它、当时寄存器里的值是多少」——这是「大概」和「确定」的差别。

举个具体的对比。同样是一次整数除零导致的崩溃，日志里可能只留下「进程已退出，代码 -1073741676」；而用调试器打开现场，你能看到错误指令、出错那一行源码、以及完整的一层层调用链。前者让你知道出了事，后者让你知道该改哪一行。这个差距在排查偶发问题时尤其明显，一个能复现的 bug 靠打印也能查，一个一周才出现一次的 bug，基本只能靠调试器。

另一个现实理由是：崩溃转储文件本身不会说话。用户把电脑上的崩溃文件发给你，你不装调试器，那个文件就是一堆二进制垃圾；装了、会用了，它就是一份完整的案发现场记录。学会读它，等于给自己的排查能力加了一层「后悔药」。

2.2 用户模式与内核模式：你的程序在哪一层出事

WinDbg 的第一道分岔路口，是选择调试用户模式还是内核模式。这个听起来很抽象，用写字楼打个比方就清楚了。用户模式像是楼里的租户，各家有各自的房间，门一关互不干扰，你在自己屋里怎么折腾都不会影响到隔壁；内核模式像是物业的水电总闸层，那里的操作能影响到整栋楼，一旦出错就是全楼停电。

具体到系统上：普通应用程序、你写的控制台程序、浏览器、记事本，都跑在用户模式；操作系统核心功能、各种硬件驱动，跑在内核模式。为什么这个区分对新手这么重要？因为它决定了两件完全不同的准备工作——用户模式调试，一台电脑就够，打开调试器挂上去就能干活；内核模式调试，通常要两台机器，一台跑调试器当「主机」，一台跑被调试的系统当「目标机」，中间还得用线连起来，或者干脆开一台虚拟机充当目标机。

判断标准也很好记：程序崩溃、界面卡死、功能报错，先按用户模式查；电脑蓝屏、驱动加载失败、开机就挂，才往内核模式想。刚入门的时候，九成的时间都该花在用户模式上，因为它的反馈快、代价小、不容易把系统搞坏。内核调试放到后面再说，那是个需要准备好几台设备的活儿。

2.3 符号文件：调试器的「地图」，没有它就等于看天书

符号文件是新手最容易翻车的地方，也是决定你调试体验是「一目了然」还是「满屏乱码」的关键。所谓符号文件，是一种叫 pdb 的附属文件，里面存着函数名、变量名、源码行号这些信息。程序编译成可执行文件之后，这些名字都被抹掉了，只剩下一串串内存地址。调试器拿到地址能干活，但要显示成「崩在 MyFunction 第 7 行」，就必须靠符号文件把地址翻译回名字。

打个比方：调试器像是一个拿着坐标找东西的人，符号文件就是那张地图。有地图，他能告诉你「在A栋3层」，没地图，他只能说「在坐标 0x7ff63be11064」。所以几乎每次开始调试，第一件事都是告诉 WinDbg 去哪儿找符号文件——这个路径设置对应一条命令叫.sympath，设置完之后再用.reload让它重新扫描加载一遍。

好消息是大部分系统模块的符号文件不用你自己准备，配好一个符号路径，调试器会在需要的时候自动下载缓存。坏消息是这一步在没网的机器上会卡住，而且报错提示非常含糊，很多人第一次就被这里劝退。记住一句话就行：只要看到满屏都是地址、看不到任何函数名，先怀疑符号没配好，这比怀疑程序本身要有效得多。

2.4 装 WinDbg 的两种方式和位数怎么选

装 WinDbg 本身不难，难的是选对版本。它支持的系统是 Windows 10 周年更新（1607）及以上，以及 Windows 11 全部版本；处理器架构支持 x64 和 ARM64。安装方式有三种，按你的目的选：

装完之后真正要小心的是位数问题。安装目录下会同时有 x64 和 x86 两套调试器，很多新手随便点开一个，然后在附加进程时失败，又看不出原因。规则很简单：64 位系统上调试 64 位程序，用 x64 那个；调试 32 位程序，用 x86 那个。拿不准的时候，先看一眼要调的程序的位数，再决定打开哪个，比事后翻车再回头找要省事得多。

3. 第一个例子：用记事本跑通你的第一次用户模式调试

理论讲再多，第一次动手还是得从最简单的开始。这个例子用的是系统自带的记事本程序，不需要你写一行代码，也不用准备任何工程文件，目的只有一个：让你亲手经历一遍「附加程序 → 配符号 → 下断点 → 跑起来 → 看调用栈」这条完整链路，把陌生感去掉。第一次学的时候，我建议就把这一串命令敲一遍，别急着理解每个参数，先让流程跑通。

3.1 打开 WinDbg 并附加一个记事本

先找到调试器的安装目录，64 位系统一般是C:\Program Files (x86)\Windows Kits\10\Debuggers\x64这样的路径，进去之后运行 WinDbg.exe。打开之后界面看着空荡荡，这是正常的，因为还没有任何被调试的目标。

接下来在「文件」菜单里选「打开可执行文件」，在弹出的对话框里定位到C:\Windows\System32，文件名填notepad.exe，点打开。此时记事本窗口会弹出来，同时调试器窗口底部会出现一个命令行提示符，前面带着0:000>这样的前缀——第一个数字是处理器编号，后三个是线程编号。看到这个提示符，说明你已经挂上去了。

如果你在菜单里找不到对应的项，也可以用命令行方式启动，效果一样：

windbg.exe C:\Windows\System32\notepad.exe

这条命令的意思是「启动调试器，并把记事本作为被调试程序一起拉起来」。好处是省去在图形界面里点好几层，坏处是路径必须写全。刚开始建议还是走菜单，让你心里有个「我现在做的是附加一个进程」的明确感觉。

3.2 设符号路径，让调试器认得函数名

程序挂上去了，但此刻调试器其实还不认识记事本里面的代码结构。在命令行里依次输入下面两条：

.sympath srv* .reload

第一条.sympath srv*是在设置符号搜索路径，srv*表示「使用系统默认的符号服务器和缓存位置」，调试器会去那里按需下载。第二条.reload是让它立刻执行一次搜索，把当前已经加载的模块所需的符号文件找出来。执行完之后，屏幕会打印出当前的符号搜索路径，以及展开后的完整路径，看到这两行就说明设置生效了。

这里有个细节值得留意：符号加载不是一次性做完的，它是「用到才加载」。有些模块一直显示成 deferred（延迟），并不代表出错了，只代表暂时还没需要它。等你在后面真的调到了，.reload一下它就会补上。新手常常因为看到一堆 deferred 就以为符号配坏了，其实是被这个词吓到了。

3.3 下断点、跑起来、看调用栈

接下来是这套流程里最有成就感的部分。先确认一下记事本模块里有哪些符号可用：

x notepad!wWin*

x是「检查符号」的意思，后面跟的notepad!wWin*表示列出记事本模块里以wWin开头的符号。输出里会看到notepad!wWinMain这样的函数名，那就说明符号已经正常工作——这是第一个能验证配置成功的信号。

接着在程序入口处下一个断点，然后让它跑起来：

bu notepad!wWinMain bl g

bu是「在未解析的符号上设置断点」，好处是即使模块还没完全加载也能先记下来；bl列出所有断点，用来确认刚才那一条确实设上了，你会看到它显示为启用状态；g是「继续运行」，按下之后记事本开始初始化，直到撞上断点才会停住。

停住之后，看两样东西就够了：

lm k

lm列出当前进程加载的全部模块，你能看到每个模块的名字、起止地址，以及符号是否加载成功；k显示当前的调用栈，也就是「从程序入口一路调用到这个函数」的完整路径。第一眼看调用栈可能有点懵，但至少能读出一个信息：最上面一行是当前停住的位置，往下每一行都是它的调用者。

3.4 这几条命令各自在做什么

把上面用到的命令集中看一遍，比零散地记要清楚：

还有两个收尾用的命令值得记住。~列出当前进程里所有线程，能看到每个线程的编号和状态；~0s是把 0 号线程切换成当前线程，输入之后提示符前面的线程编号会跟着变，之后敲的k就是那个线程的调用栈了。最后想退出又不影响被调试的记事本，用：

qd

qd是「退出并分离」，调试器关掉，记事本继续正常运行。如果你用q，被调试的进程通常也会被一起结束——这个区别新手经常搞混，随手一按结果把目标程序杀了，再执行一次又会得到相同的结果。

4. 第二个例子：程序崩了怎么用 !analyze -v 找到出错那行代码

第一个例子里，程序是被你强行停下来的，属于「我让它停它就停」。真实场景恰恰相反：程序自己崩了，你想知道为什么。这一章就拿一个故意写坏的小程序当靶子，把「崩了之后怎么定位到具体哪一行」这件事走一遍。走完你会发现，!analyze -v这个命令基本相当于崩溃现场的法医报告，读得懂那几个字段，八成的问题当场就有方向了。

4.1 先写一个注定会崩的小程序

先准备一份会出问题的代码，别用真实项目，就用这个小文件练手：

// MyApp.cpp —— 一个故意会崩的小程序，专门用来练手 #include <stdio.h> void MyFunction(long p1, long p2, long p3) { long x = p1 + p2 + p3; long y = 0; y = x / p2; // 第 7 行：p2 传进来是 0，这里整数除零 } int main() { long a = 2; long b = 0; // 故意传 0 MyFunction(a, b, 5); return 0; }

这段代码的问题在MyFunction里：p2参数传进来是 0，而第 7 行做了x / p2，整数除以零会直接触发异常。用 x64 的 Debug 配置编译，让它生成MyApp.exe和配套的MyApp.pdb，两者放在同一个目录里。pdb 文件一定要留着，它是这个练习能成功的一半；很多人编译完只拷走了 exe，结果调试器里一行源码都看不到，白折腾半天。

4.2 打开可执行文件，把断点设在 main

重新打开 WinDbg，在「文件」菜单里选「打开可执行文件」，定位到刚才编译输出的目录，选中MyApp.exe。程序会立刻启动并暂停在初始状态，此时命令行提示符已经出现。

先告诉调试器去哪里找这个程序自己的符号和源码：

.symfix .sympath+ C:\MyApp\x64\Debug .reload bu MyApp!main g

.symfix是把符号路径先恢复成系统默认值，避免上一次调试留下的路径干扰；.sympath+结尾那个加号表示「追加」，把本次程序的输出目录接到已有路径后面，这样系统模块和你的程序符号都能找到；.reload重新扫描；bu MyApp!main在 main 函数开头下断点；最后g跑起来。

跑起来之后程序会停在 main 的入口处，界面上通常还会同时显示源码窗口和命令行窗口。这一点对新手特别友好，你能直接看到代码行和当前执行位置的对应关系，不用全靠想象。

4.3 单步走到崩溃，让异常停在调试器里

停在 main 之后，用单步执行一条一条往下走，快捷键是 F11（对应菜单里的「单步执行」）。单步的过程中你会看到执行位置在源码上移动：进入MyFunction，算出x，初始化y，然后走到第 7 行。

就在执行y = x / p2这一行的瞬间，程序会中断到调试器里，命令行刷出一段提示，大意是「整数除零异常，首次机会」。这里有个概念值得解释一下：所谓「首次机会异常」，是指异常刚发生、还没有交给程序自己的异常处理逻辑之前，调试器先截住了它。很多异常在正常运行中会被程序自己处理掉，不算 bug，所以首次机会异常不等于崩溃；但这个例子里没人处理它，它就是真崩了。

如果单步的时候发现执行位置和源码对不上，或者显示的是汇编而不是源码，多半是符号或源码路径没配好，回到 4.2 那一步检查.sympath+后面的路径有没有写错。

4.4 用 !analyze -v 读出「哪一行、什么错、谁调用的」

崩了之后，直接敲这条命令：

!analyze -v

它会把异常记录、出错指令、调用栈、可能的源码位置全部整理成一份报告。输出很长，新手不用全看，盯住四个字段就够：

EXCEPTION_CODE是最好用的入口，一串十六进制数字对应一种异常类型，常见的除零、访问违例、栈溢出各有各的码，记不住也没关系，报告里一般会附一句英文描述，读那句就行。FAULTING_SOURCE_LINE是最终的答案，它直接把问题定位到源码的某一行，省去了你从头翻代码的时间。

这里要提醒一句：!analyze -v的结论是「高度可能」而不是「绝对正确」，尤其是优化过的发布版本，行号可能对不上。遇到这种情况，看FAULTING_IP指向的函数名，再结合调用栈判断，比死磕行号靠谱。

4.5 这套流程能照搬到什么场景

上面这套动作不只是用来调自己写的程序。最典型的真实用法是分析故障转储文件：用户在别人电脑上崩了，把生成的 dmp 文件发过来，你在调试器里打开这个文件，一样敲!analyze -v，一样能读到异常类型和调用栈。区别只在于程序已经死了，不能单步，但该有的现场信息都在。

打开转储文件的方式也很简单，菜单里选「打开转储文件」，或者命令行直接带上路径启动。分析完之后如果需要深入，可以再用lm看当时加载了哪些模块、用~看崩溃时有多少线程、用k挨个看它们的调用栈。这套组合拳打熟了，日常八成的崩溃排查都能自己搞定。

5. 新手避坑清单：符号加载不上、断点打不中到底为什么

调试器这类工具的坑有个共同特点：它不报错，只是安静地什么都不给你，让你以为是自己操作错了。下面这五条是最常见的翻车点，每条都按「看到什么现象 → 为什么会这样 → 怎么解决」写，遇到问题对照着看就行。

5.1 断点设上了，跑起来却不停

现象：用bu下了断点，bl里也能看到，但一敲g程序直接跑完或者停在别处，断点毫无反应。

原因：最常见的是断点设在了还没加载的模块上。模块是按需加载的，程序刚启动时很多模块根本不在内存里，断点只能先挂着，等模块进来才生效。第二种可能是符号没解析成功，断点被记成了一个地址，而那个地址和实际代码错位了。

解决：先g让程序跑一段，等模块加载后再bl看一眼断点是否已经解析成符号形式；如果还不行，.reload之后重新下一次断点。判断标准很简单——bl里断点显示的是函数名就正常，显示的是一串地址就说明符号没到位。

5.2 满屏都是地址，一个函数名都看不到

现象：调用栈里全是0x00007ff...这样的十六进制数字，lm里每个模块后面都写着 no symbols，源码窗口一片空白。

原因：符号文件没找到。可能是符号路径没设，可能是网络不通导致下载失败，也可能是你自己的程序编译时根本没生成 pdb，或者 pdb 和 exe 没放在一起。

解决：先.sympath srv*恢复默认，再.reload重新加载，然后看输出的路径展开结果对不对。如果是自己写的程序缺符号，回去检查编译配置里调试信息有没有打开。实在查不出来，用!sym noisy打开详细日志，它会告诉你每一步去哪个路径找了、为什么没找到，比盯着结果猜高效得多。

5.3 附加进程失败，或者附加上了看不到东西

现象：在菜单里选附加进程，列表里找不到目标程序，或者找到了但点确定之后报错；偶尔能附加成功，但调用栈看着完全不像那个程序。

原因：位数不匹配。用 32 位调试器去调 64 位程序，或者反过来，就会出现这种「能连上但看不懂」的状态。另一种可能是权限不够，目标程序以更高权限运行，调试器没权限挂上去。

解决：先确认目标程序的位数，再打开对应目录下的调试器。权限问题就两边保持一致，都用同样的权限级别启动。这两个原因能覆盖绝大多数附加失败的情况，排查顺序也按这个来。

5.4 内核调试一直卡在等待连接

现象：主机这边启动内核调试后，屏幕停在一行等待重连的提示上，一直不动；目标机那边看起来也在正常运行，就是不进断点。

原因：内核调试是两台机器之间的事，连接方式、端口、启动配置任何一环不对都会这样。常见的是目标机没有开启调试启动项，或者网络端口被挡住，或者主机和目标机配的不是同一个连接方式。

解决：按「连接方式 → 端口 → 启动配置」的顺序逐项核对。第一次配建议直接用虚拟机当目标机，出问题重置一下就行，不会把主力机器搞成开不了机。内核调试这块新手翻车的代价比用户模式大得多，我自己的血泪经验是：先把主机侧的命令行参数抄下来，确认一遍再上目标机。

5.5 调试完把目标程序一起关了

现象：想收工，敲了q退出调试器，结果发现被调试的程序也没了，之前跑出来的状态全丢，得重来一遍。

原因：q是「退出」，会连带结束被调试的进程；qd才是「退出并分离」，调试器走人、目标程序继续活着。两个命令只差一个字母，效果差很远。

解决：只要你还想留着目标程序继续跑，一律用qd。养成习惯之后，几乎所有场景都不需要q。这个坑我见过太多次，尤其在内核调试的时候，一个手滑就得重启目标机重来，代价相当不划算。

6. 下一步学什么：从「会跑例子」到「能查真问题」

两个例子跑通之后，你其实已经跨过了最难的那道坎——不再害怕那个黑窗口了。接下来往哪走，取决于你手上的实际问题长什么样。这里给三条路线，你对号入座就行。

6.1 三条可以往下走的路线

路线一：专攻崩溃转储分析。如果你的日常工作就是处理用户反馈的崩溃文件，那重点练三件事：打开 dmp 文件、跑!analyze -v、顺着调用栈找到自己代码的那一帧。练熟之后可以再学~*k一次性看所有线程的栈，很多卡死类问题就藏在这里。

路线二：专攻用户模式下的程序调试。想搞清楚程序运行时到底在干什么，就把断点玩熟：条件断点、断点命中后自动执行命令、按模块下断点。这类技巧能让你在几万行代码里精准停到「第三次调用这个函数且参数等于某个值」的那一刻。

路线三：往内核模式走。只有当你确实要调驱动、查蓝屏时再开始。准备两台机器或者一台虚拟机，把主机目标和连接方式先搭起来，再谈调试技巧。这条路线的前置成本明显更高，不建议作为入门第一站。

6.2 一张可以贴在屏幕边上的命令表

下面这些是入门阶段真正高频的，先背这几条，其余的用到再查：

想查某个命令的详细说明，在调试器里敲.hh 命令名，它会弹出本地帮助。这个功能比翻资料快，而且不会因为版本不同导致命令对不上。

6.3 一个值得坚持的小习惯

最后说个小习惯：每次开始调一个新问题，先花三十秒做三件事——确认符号路径、确认调试器位数、确认当前是用户模式还是内核模式。听起来像废话，但我自己的血泪经验是，翻车绝大多数都发生在跳过这三步的时候。有一次查一个偶发崩溃，折腾了快两个小时，怀疑是内存越界、怀疑是多线程竞争，最后发现是打开的调试器位数不对，符号从头到尾就没加载成功过。

从那以后我每次开调试会话，不管多急，都强制走一遍这三步再动手。慢三十秒，省两小时，这笔账很划算。希望这份手册能帮你把这三十秒变成肌肉记忆，也希望帮到你。

本文还有配套的精品资源，点击获取