简介Windows DebuggerWindbg配套调试工具合集面向从事 Windows 应用开发、驱动编写与系统故障排查的开发者也适合希望系统掌握崩溃转储分析与内核态调试的技术人员。包内既有调试器运行所需的动态库与可执行程序也保留了示例工程源码与配置。全部内容共 307 个文件以 82 个 dll、39 个 exe 构成可运行主体42 个 h 与 19 个 cpp、6 个 c 支撑示例代码阅读另有 13 个 natvis 可视化配置、21 个 xml、8 个 cmd 脚本及 sys、inf、cat 等系统组件与说明文档压缩包合计 27.72MB按模块分层组织便于检索。已有 2051 人学习下载。读者可从中获得内存状态查看、堆栈跟踪、反汇编与源码级调试、符号服务器配置、扩展命令脚本化以及蓝屏转储分析等环节的实操素材配合 !analyze -v、k、dv 等常用命令反复练习逐步建立从用户态到内核态的排错思路。1. 一台业务机自己重启之后windows-windbg 资源包先看哪几眼凌晨两点一台业务机自己重启C:\Windows\Minidump 下多出一个几百 KB 的 dmp日志里只剩一行 BugCheck。在 windows 上能把这个黑匣子读出调用栈的工具就那么几个WinDbg 覆盖面最全用户态崩溃、内核蓝屏、驱动挂死都走同一套命令。windows-windbg 这份资源包放的是三样偏工程化的东西调试器落盘脚本、符号表配置与离线缓存方案、按 BugCheck 分类的 dump 分析笔记。它适合正在排查客户端崩溃、服务无故退出的开发者新手能跑出第一份 !analyze 报告熟手更在意符号和位数这些细节。2. 先装对再谈调三种调试器变体的选型与资源包落盘压缩包解开之后先别急着双击 exe。这类资源包通常把调试器本体、符号脚本、命令笔记混在一个目录里而「装完能打开」和「能读出结论」是两件事中间隔着版本选型、路径固定、符号路径三关。任何一关没过你在命令窗口里看到的都是问号、错误地址和一句莫名其妙的 symbols not loaded。我踩过最深的一次坑是路径里带了个中文目录名脚本传参被截断排查了两个小时才反应过来是路径问题这种翻车完全可以提前避开。2.1 三种变体经典版、新版界面版和命令行版同一个名字下面其实是三个可执行文件行为差异不小选错了会让后面所有操作都别扭。经典版 windbg.exe 随 Windows SDK 的调试工具组件分发整个目录是绿色的拷到脱机机器上就能跑。界面停留在十几年前的样子但内核调试链路和扩展生态最完整资源包里的大部分脚本都是按它的行为写的命令回显格式也和网上能搜到的分析笔记对得上。新版界面版走应用商店分发内置时间旅行调试TTD的录制与回放能力适合抓那种偶发、不易重现的用户态问题。命令体系与经典版一脉相承但部分老扩展的加载行为和窗口布局有差异照抄老笔记时要注意。命令行版 cdb.exe 和 ntsd.exe 没有图形界面适合在服务器上跑批、把 dump 分析塞进构建流水线。cdb 的-c参数可以直接把一串命令接起来配合-logo把输出重定向到文件就能做无人值守分析。变体典型文件适合场景需要注意经典版windbg.exe内核蓝屏、驱动 dump、扩展调试界面老旧大 dump 加载慢新版界面版WinDbgX.exe用户态偶发问题、TTD 录制回放老扩展行为有差异命令行版cdb.exe / ntsd.exe服务器跑批、流水线自动分析没有交互界面全靠脚本选型可以压成一句话分析蓝屏和内核 dump经典版足够要复现偶发且不易重现的用户态 bug用新版 TTD要批量跑就上 cdb。三者在同一台机器上共存没问题只要别互相覆盖目录用完整路径调用就不会串。2.2 目录与 PATH把工具固定到一个不会被清理的路径资源包解压到下载目录是临时做法。下载目录会被清理、会被同步工具搬走更麻烦的是路径里一旦出现空格或中文脚本里的参数解析就容易出问题。我一般会把调试器固定到一个短的英文路径下再把目录写进系统 PATH这样任何终端里都能直接敲cdb。# 把调试器固定到 D:\tools\windbg避免放在下载目录被清理 $dbg D:\tools\windbg New-Item -ItemType Directory -Force -Path $dbg | Out-Null # 经典版解压后一般包含 windbg.exe / cdb.exe / ntsd.exe整目录拷过去 Copy-Item -Path D:\download\windbg-pack\* -Destination $dbg -Recurse -Force # 写入机器级 PATH需要管理员权限的终端执行 $old [Environment]::GetEnvironmentVariable(PATH, Machine) if ($old -notlike *$dbg*) { [Environment]::SetEnvironmentVariable(PATH, $old;$dbg, Machine) } # 验证新开一个终端能看到解析到的完整路径 Get-Command cdb.exe | Select-Object -ExpandProperty Source这段脚本的关键点有三个-Force让重复执行不报错适合放进装机脚本里反复跑-Recurse保证扩展目录和帮助文档一起拷走很多扩展是相对路径加载的漏了目录就会出现「命令存在但扩展加载失败」写的是 Machine 级环境变量而不是当前会话改完必须新开终端才生效老窗口里敲cdb找不到命令是正常现象不是安装失败。还有个小细节别把调试器目录塞进 OneDrive 之类的同步盘。调试过程中会在同目录生成 workspace 文件和临时符号缓存同步工具一边扫描一边锁文件偶尔会让调试器卡在启动阶段。2.3 符号路径一句环境变量决定后面所有分析的质量符号表这件事值得单独说透。调试器手里只有 exe 和 dll 时栈上显示的全是裸地址只有加载了对应的 pdb地址才会翻译成「模块名!函数名偏移」再加行号。没有符号的!analyze -v输出基本等于猜谜你只能看到一个可疑模块名看不到它到底调了什么。符号服务器是按 pdb 内部的 GUID 加 age 建索引的所以同一个模块的不同编译产物不会串味——这也是为什么官方推荐直接连服务器而不是手工拷 pdb。srv*语法是三段式srv*本地缓存目录*符号源符号源既可以是 http 地址也可以直接指向一个本地目录内网离线副本就靠这个。# 三段式srv*缓存目录*符号源缓存目录用独立磁盘别和系统盘挤在一起 $sym srv*D:\Symbols*https://符号服务器/download/symbols [Environment]::SetEnvironmentVariable(NT_SYMBOL_PATH, $sym, Machine) # 单独指定符号缓存路径避免临时目录被清理后要重新下载 [Environment]::SetEnvironmentVariable(_NT_SYMCACHE_PATH, D:\SymbolsCache, Machine)参数含义D:\Symbols是下载下来的 pdb 的落地位置第一次分析某个系统 dll 时会比较慢之后就走本地命中https://符号服务器/download/symbols换成内网自建的符号缓存地址或者离线目录_NT_SYMCACHE_PATH是调试器自己的下载中转区和落地目录分开更好清理。进了调试器之后还有几条命令要会它们比环境变量更常用.sympath # 查看当前符号路径确认三段式有没有生效 .symfix D:\Symbols # 一键设成「官方公共符号源 本地缓存」两段式最省事 .reload /f # 强制重新加载所有模块符号改完路径必跑 .reload /f ntoskrnl.exe # 只重载单个模块大 dump 下比全量快很多 !sym noisy # 打开符号搜索日志加载失败时看它到底在找哪个路径 lm vm nt # 确认内核模块的 pdb 路径和时间戳是否对得上离线场景的做法是把内网符号服务器上的目录整棵同步到本地然后把符号路径写成D:\Symbols不带 srv 前缀调试器会直接按 GUID 在目录里找一个字节的网络请求都不发。这套做法在隔离环境里救过我好几次。3. 连上目标打开 dump、附加进程与内核双机调试的三条路调试器装好、符号配好之后剩下的是「连什么」。日常遇到的其实是三类目标已经躺在磁盘上的 dump 文件、还在跑的进程、以及整台机器的内核。三条路的启动参数完全不一样混着用是最常见的效率损失。3.1 打开 dump 与附加进程两条最常用的命令分析 minidump 是最高频的场景。我习惯在命令行里一次性把符号路径、首轮分析命令、日志输出全带上省得进界面再敲一遍。:: 打开 minidump同时指定符号路径、首轮命令和日志文件 windbg.exe -z C:\Windows\Minidump\030124-12345-01.dmp ^ -y srv*D:\Symbols*https://符号服务器/download/symbols ^ -c .reload; !analyze -v ^ -logo D:\reports\minidump-01.txt :: 附加到指定 PID-g 跳过初始断点-G 跳过第二次加载断点 windbg.exe -p 4321 -g -G :: 非侵入式附加只看不暂停适合排查卡死而不是崩溃 windbg.exe -pv -p 4321逐项说明-z指定 dump 文件路径引号不能省路径里带空格时尤其要注意-y覆盖本次会话的符号路径优先级高于环境变量临时换源很方便-c是会话启动后立刻执行的命令串分号分隔!analyze -v放在最后是因为它依赖前面的.reload-logo把整段输出落到文件回头写报告直接复制不用截图。-p后面跟 PID可以用任务管理器的「详细信息」页查也可以用tasklist /svc对服务。-g和-G这两个参数值得单独记不加的话调试器一附加就断了被调试进程卡在那儿不动很多人第一次附加就以为把程序搞挂了加上之后进程继续跑只有命中异常才停下来。-pv是非侵入式附加不修改目标进程的内存和线程状态代价是只能看栈和模块不能下断点。3.2 内核双机网络、串口与本地内核调试内核调试必须两台机器或者一台宿主机加一台虚拟机目标机开调试开关调试器侧连过去。网络方式现在最常用配置全在 bcdedit 里。:: 目标机被调试方执行开启内核调试并配置网络传输 bcdedit /debug on bcdedit /dbgsettings net hostip:192.168.1.10 port:50000 key:1.2.3.4 :: 确认写入结果改完必须重启目标机才生效 bcdedit /dbgsettings :: 调试器一侧地址为 192.168.1.10 的那台机器执行 windbg.exe -k net:port50000,key1.2.3.4 :: 串口方式虚拟机环境或网络隔离场景更省事 windbg.exe -k com:portCOM1,baud115200参数上有几个硬性约束hostip填的是调试器所在机器的地址不是目标机自己的key必须是x.x.x.x形式随便写个字符串会直接报参数错误port两端要一致防火墙要放行。串口方式带宽小加载符号慢但胜在不依赖网络栈目标机网卡驱动出问题时它还能用。本地内核调试用-kl只能调本机断下来整机停住办公机上不要随便开。提示内核调试开关写进启动配置后目标机每次启动都会等调试器连接如果调试器不在线开机可能卡在引导阶段。排查完记得bcdedit /debug off再重启一次。3.3 会话可复现workspace、脚本文件和 -c 参数调试过程最怕的是「刚才那几条命令怎么敲来着」。经典版有 workspace 机制退出时会把断点、符号路径、窗口布局存下来下次打开同一目标自动恢复。但 workspace 是绑定到具体目标的换个 dump 就失效。更通用的做法是把常用命令写成一个文本文件用$$a让它逐行执行。.symfix D:\Symbols .reload /f !analyze -v lm ~*k:: 把脚本文件塞进 -c执行完自动退出适合批量跑 windbg.exe -z D:\dumps\crash-01.dmp -c $$aD:\dbg\analyze.txt; q :: 需要在会话中间手动记录时用 .logopen 开日志 :: .logopen /t D:\reports\session.txt$$a的作用是把文件内容按行当命令执行q保证脚本跑完就退出进程否则批处理会一直挂着等交互。这一套组合配合前面的-logo就得到了一次完全无人值守的分析给定 dump 路径产出文本报告。脚本文件里建议不要写带交互的命令比如g之后等用户输入批处理模式下没人应答会直接卡死。4. 把 dump 读出结论!analyze -v 之后必须补的四类命令!analyze -v是入口不是终点。它给的是「最可能」的猜想一个 BugCheck 码、一个可疑模块、一段栈。真正定位到具体代码行还得靠后面这几类命令去验证和收敛。4.1 !analyze -v 的三块输出要看什么第一块是 BugCheck 码和四个参数。0xD1 一般指向驱动在错误的 IRQL 上访问了分页内存第一个参数往往就是出事的地址0x3B 是系统服务例程里发生了异常0x50 是无效的内存引用0x9F 是驱动电源状态切换卡住。这些码只能定方向不能定模块。第二块是 Probably caused by 那一行。它是由栈上最近的一个非系统模块推出来的准确率取决于符号是否完整。符号缺失时它会指向一个莫名其妙的地址或者直接写 unknown这时候不要急着相信结论先回去补符号。第三块是 FAILURE_BUCKET_ID 和栈。bucket 字符串对做统计很有用同一个 bucket 反复出现说明是同一个根因可以直接去查历史工单。4.2 栈回溯与符号缺失的判定判断符号到底有没有加载最直接的是lm vm 模块名看输出里有没有 pdb 路径、时间戳和「Loaded symbol image file」字样。如果只显示「deferred」或者路径为空就是没加载成功。.ecxr # 用户态 dump 必做切换到异常发生的上下文否则栈是错的 kb # 带参数和返回地址的栈最常用 kv # 带帧指针信息判断栈是否被破坏时看这个 ~*k # 所有线程的栈找谁在等锁、谁在跑 dds rsp L100 # 栈内存按地址扫一遍符号缺失时人工找返回地址用户态 dump 有一个高频错误打开之后直接敲k看到的栈是调试器当前线程的不是崩溃线程的。必须先.ecxr把异常上下文切回来栈才对得上。内核 dump 则是先!thread确认当前线程再用kb看它卡在哪。栈里如果出现大量纯地址、函数名全是0x00007ff...这种或者中间断层出现0x0000000000000000基本都是符号问题。可以.reload /f 模块名单独重载再不行就!sym noisy打开日志看调试器到底去哪个路径找 pdb、返回了什么错误码。4.3 内存与句柄!heap / !address / !htrace 的边界崩溃类问题看栈泄漏和卡死类问题就得看堆。这几条命令都有前置条件不知道边界会得出完全错误的结论。命令用途前置条件常见误用!heap -s列出所有堆的汇总看哪个堆在涨用户态 dump堆未损坏拿它当泄漏证据实际只反映当前快照!heap -p -a 地址反查某块内存的分配栈需开启用户态栈回溯ust没开 ust输出里只有大小没有栈!address查看地址空间的区域划分和状态任意 dump把保留区当成已提交内存!htrace追踪句柄的打开与关闭记录需提前开启 htracedump 是事后抓的没有历史记录!pool/!poolused内核池块与用量统计内核 dump池已损坏时命令本身也会失败!vm虚拟内存总体统计内核 dump用它判断进程级泄漏用户态栈回溯ust是要提前开的靠 gflags 给目标进程打上标记之后抓的 dump 里!heap -p -a才有分配栈。事后抓的 dump 里没有这段历史命令跑出来只有块大小很多人到这一步以为是命令用错了其实是数据本来就不在。这条经验属于典型的后悔药等出问题再开就晚了压力测试环境里应该默认打开。5. 避坑与排查符号、位数、权限与扩展加载的五个翻车现场下面五条是这类调试器资源包在使用中最常撞上的问题每一条我都至少遇到过一次按「现象、原因、解决」写清楚遇到了直接对号入座。5.1 符号加载了但栈还是全是地址现象执行!analyze -v之后可疑模块显示 unknownkb出来的栈里函数名全是裸地址lm vm显示模块状态是 deferred 或者 pdb 路径为空。原因九成是符号路径不可达或缓存目录不可写。剩下的一成是模块版本对不上——目标机打过补丁本地缓存的 pdb 和实际二进制不是同一次编译产物GUID 对不上就会被跳过。解决先!sym noisy打开搜索日志重跑.reload /f看日志里报的是 404、超时还是路径无权限。网络受限的环境把符号换成本地离线目录缓存目录别放在只读盘或者需要提权的目录下。确认模块版本可以用lm vm 模块名对比时间戳和 pdb 的 GUID。5.2 调试 32 位进程时栈断在 wow64 层现象附加到一个 32 位进程栈顶全是wow64、wow64cpu、ntdll之类的模块看不到自己的业务代码断点也打不中。原因64 位调试器附加 32 位进程时默认停在 64 位的 WOW64 转换层业务代码跑在下面的 32 位上下文里。解决在调试器里执行!wow64exts.sw切到 32 位上下文再kb就能看到业务栈或者干脆用 32 位版本的 cdb.exe 附加。位数不匹配还会影响扩展加载!heap、!htrace这类命令在错误的上下文里会直接报错症状看着像扩展坏了其实是位数问题。5.3 附加进程直接报拒绝访问现象windbg.exe -p PID报 0x80070005 拒绝访问或者附加上去之后目标进程卡住不动。原因前者的常见原因是调试器权限低于目标进程比如目标是以管理员身份启动的服务后者多半是没加-g调试器在初始断点停下进程自然不动。解决用同样或更高权限的终端启动调试器服务类进程要先确认它的会话和权限级别附加时统一带上-g -G。对于受系统保护的进程普通调试器附加不上是设计如此只能走它自己的诊断通道别在这上面耗时间。5.4 扩展 DLL 加载失败现象.load pykd或者!ext.xxx报 0x8007007E「找不到指定的模块」但文件明明在扩展目录里。原因最常见的是位数不一致——64 位调试器加载 32 位扩展其次是扩展自身依赖的运行库缺失再次是路径里带中文或空格加载器解析失败。解决先确认调试器位数和扩展位数一致vertarget能看到当前会话架构把扩展放到纯英文短路径下用!analyze内置的扩展优先别乱加载第三方。实在查不出来!sym noisy的思路同样适用——把加载失败的详细原因打出来。5.5 dump 文件打不开或提示版本不匹配现象-z指定 dump 后调试器提示无法打开或者打开后栈完全不可读。原因minidump 只保留了很少的内存遇到堆损坏、栈被覆盖这类问题信息量不够也可能是 dump 写到一半被截断或者用了版本过旧的调试器去解新版系统的 dump。解决把转储类型改成核心内存转储或完整内存转储配置文件在系统属性的「启动和故障恢复」里事后补抓可以用任务管理器 → 右键进程 → 创建转储文件或者在调试器里.dump /ma D:\dumps\full.dmp生成完整 dump。调试器本身尽量用较新的版本老版本解新系统的结构体经常读错字段。6. 把重复劳动压成一条命令批量分析模板与时间旅行调试一台机器一晚上蓝屏三四次Minidump 目录里躺着一堆 dmp逐个双击打开是最没效率的做法。我现在的做法是写一个批处理脚本把所有 dump 一次性跑完产出一堆文本报告再按 FAILURE_BUCKET_ID 分组看哪一类占大头。# 批量分析 Minidump 目录每个文件产出一份文本报告 $cdb D:\tools\windbg\cdb.exe $sym srv*D:\Symbols*https://符号服务器/download/symbols New-Item -ItemType Directory -Force -Path D:\reports | Out-Null Get-ChildItem C:\Windows\Minidump\*.dmp | ForEach-Object { $out D:\reports\$($_.BaseName).txt $cdb -z $_.FullName -y $sym -c .reload; !analyze -v; q -logo $out } # 汇总所有报告里的失败桶按出现次数排序 Select-String -Path D:\reports\*.txt -Pattern FAILURE_BUCKET_ID | ForEach-Object { $_.Line.Trim() } | Group-Object | Sort-Object Count -Descending | Select-Object Count, Name这段脚本的价值在最后那几行单份报告只能告诉你这次崩在哪聚合之后才能看出「同一类崩溃占了七成」排查优先级立刻就清楚了。参数上注意-c里必须有q否则 cdb 会一直等交互-logo的目录要提前建好文件路径不存在时 cdb 不会自动创建父目录。再往前一步是时间旅行调试。新版调试器可以录一段执行过程之后像拖进度条一样前后移动任意时刻的寄存器、内存、调用栈都能回看。对于那种「跑一万次崩一次」的问题录制一次比反复复现省事得多。启动时加-ttd录制回放时用!tt 0跳到起点、g-反向执行、dx $curprocess.TTD查看可用的事件索引。它不能替代 dump 分析但在定位「到底哪一步把指针写成空」这类问题上比在栈上猜要踏实。自检项怎么确认不通过的表现符号是否真加载lm vm 模块名看 pdb 路径栈里全是裸地址位数是否匹配vertarget看会话架构扩展加载失败、栈断在 wow64dump 类型是否够用文件大小与生成方式堆信息缺失、栈不可读调试器版本帮助里的版本号解析新系统结构体出错从那以后我每次拿到一个 dump都强制先跑一遍lm和vertarget确认符号和位数这两件事再往下看别再让两个环境问题伪装成业务 bug。希望帮到你。本文还有配套的精品资源点击获取