ADK/SDK/WDK与WinDbg/poolmon：Windows调试工具链

我经常被问到一类问题：ADK、SDK、WDK到底什么关系？WPT、WPR、WPA是不是一套东西？poolmon和WinDbg平时怎么配合？说实话，这些缩写堆在一起确实容易劝退新手，因为微软官方文档把每个工具都单独铺开讲，却很少有人讲清楚它们之间的层级和协作关系。这篇文章我想从实际使用的角度，把这条工具链拆开揉碎，讲清楚每个工具的定位、它们怎么配合、安装时有哪些坑、以及我自己排查问题时的完整思路。

这套东西不是给普通应用开发者准备的，而是面向驱动程序开发、系统性能分析、内核调试、部署镜像评估这类偏底层的工作。如果你写应用层代码，可能只需要SDK；如果你碰驱动、碰内核、碰性能调优，那ADK、WDK、WinDbg、poolmon这些迟早要打交道。下面按我的理解，把整个体系串一遍。

1. 先分清楚ADK、SDK、WDK：三兄弟各有各的地盘

1.1 从定位上看，这三个包根本不是一回事

很多人把ADK、SDK、WDK混在一起，因为它们名字里都有“Kit”，安装目录也都默认装在Windows Kits下面。但它们的服务对象完全不同。

• SDK（Windows Software Development Kit）：面向应用开发者，提供头文件、库文件、编译器工具链、调试接口定义。你做普通的Windows桌面程序、服务程序、UWP应用，都需要SDK。
• WDK（Windows Driver Kit）：面向驱动开发者，提供驱动专用的头文件、库、构建环境、签名工具、以及一批驱动调试和验证工具（包括poolmon、devcon、verifier等）。WDK本身依赖SDK，安装WDK之前必须先装对应版本的SDK。
• ADK（Windows Assessment and Deployment Kit）：面向系统部署和性能评估，包含部署工具、镜像工具、以及本文重点要讲的Windows Performance Toolkit（WPT）。它跟开发者的日常编译关系不大，更多是给系统管理员、性能工程师、OEM厂商用的。

用一个不太严谨但好记的类比：SDK是一套“盖房子用的标准建材”，WDK是一套“盖特殊结构房屋的专业建材和检测设备”，ADK则是“房屋验收与体检工具包”。三者各有侧重，但都归微软Windows生态体系管。

1.2 WPT藏在ADK里，poolmon藏在WDK里

这里有个特别容易忽略的点：大家熟知的WPT（Windows Performance Toolkit），也就是WPR和WPA，不是独立安装包，而是ADK的一个可选组件。安装ADK时，安装器会列出一堆组件，其中有一个叫“Windows Performance Toolkit”的选项，默认不勾选，你得手动勾上。很多教程直接告诉你“安装ADK”就完事了，结果你装完发现找不到wpr.exe和wpa.exe，就是因为漏了这一步。

poolmon则在WDK里面。完整路径类似：

它不在系统PATH里，也不在开始菜单里。你装完WDK之后，得手动去Tools目录下找，建议自己把它复制到一个顺手的目录，或者加进PATH。

如果你只想做性能采集分析，不需要写驱动，那其实只需要ADK里的WPT就够了，SDK和WDK都不用装。反过来，如果你想做内核调试，只装WDK也能拿到经典版WinDbg，但新版WinDbg（WinDbg Preview）是通过Microsoft Store分发的，跟WDK安装包无关。

1.3 安装选型的实用逻辑

我的建议是，只要你打算长期在这条技术线上深入，就把SDK、WDK、ADK三件套都装上，并按顺序装：先是Visual Studio，然后SDK，再WDK，最后ADK。这个顺序能避免很多版本兼容问题。后面第4章我会专门讲版本不匹配的坑。

2. 每件工具的本事和适用场景

2.1 WPR/WPA：性能数据的采集与剖析

WPR（Windows Performance Recorder）负责录，WPA（Windows Performance Analyzer）负责分析。它们的底层依赖是ETW（Event Tracing for Windows），一个贯穿Windows内核和用户态的事件追踪机制。

我见过不少人的用法是：开WPR，录一会儿，拖到WPA里看CPU占比。这当然没错，但WPT的价值远不止看“谁占CPU高”。它能同时记录线程调度、DPC/ISR中断活动、磁盘I/O、网络I/O、内存页错误、电源状态切换、注册表访问等系统级行为，而且录制开销很低，对系统运行状态的影响可以忽略不计。

实际使用中，WPR命令行更常用：

然后双击output.etl，会用WPA打开。WPA左侧是Graph Explorer，右侧是分析区。你可以把“CPU Usage (Sampled)”里的栈视图按函数聚合，在设置里指定加载符号文件，就能看到热点函数名称，而不只是十六进制地址。这是最常用的性能瓶颈定位流程。

2.2 WinDbg：双机调试与事后分析的工具箱

WinDbg是个调试器，但它的定位跟Visual Studio调试器完全不同。VS调试器适合断点调试应用代码，WinDbg更适合内核调试、崩溃转储分析、内存数据检查。它支持通过串口、USB、网络、VMware管道等方式连接目标机器做内核调试，也支持打开dump文件做事后分析。

用WinDbg最频繁的三个场景：

第一，分析蓝屏dump。系统配置了内核转储后，每次蓝屏产生一个MEMORY.DMP，WinDbg打开后直接执行!analyze -v，几秒钟就能告诉你崩溃发生在哪个模块、哪个函数、错误码是什么、参数是什么含义。

第二，内核态断点调试。驱动开发时经常需要在内核函数上下断点，比如bu nt!IofCallDriver，然后单步查看IRP的传递路径。

第三，用户态进程分析。WinDbg可以attach到本地进程，做!heap堆分析、看线程栈、查句柄泄漏，这部分功能在分析应用程序内存问题时也很实用，不一定非得等蓝屏。

2.3 poolmon：盯内核池内存的唯一捷径

poolmon（Pool Monitor）是监视内核池内存分配与释放的工具。内核里驱动申请内存时带一个4字符的PoolTag，poolmon按Tag分组显示Allocs、Frees、Diff、Bytes等数据。它的核心用法就是抓“池泄漏”——某个驱动反复分配内存但没释放，你通过观察哪个Tag的Diff和Bytes持续增长，就能锁定嫌疑对象。

要注意，poolmon必须管理员权限运行，而且为了得到更全的Tag信息，建议配合Driver Verifier使用。这个我在第5章会展开讲一个完整案例。

2.4 SDK在你不需要写应用时也有用

单看标题里的SDK，很多人会以为只有写应用才需要。但在驱动开发里，Windows SDK提供的signtool.exe、inf2cat.exe经常被用到：驱动编译完需要签名，测试签名命令就是signtool sign /v /s MyCertStore /n MyCertName /t http://timestamp.digicert.com xxx.sys；做WHQL认证或创建驱动程序包目录文件时，又得用inf2cat。这些工具都来自SDK。所以别小看SDK，它是整个工具链的底层依赖。

3. 一套典型组合：驱动开发中的“调试+追踪+内存审计”工作流

3.1 先定工作流，再决定用哪个工具

单独介绍每个工具没有意义，关键是怎么组合使用。我自己的驱动开发调试流程一般是这样：

一个驱动模块拿到手，先做一次静态审查，然后装上目标机。如果性能有疑虑，先用WPR录一段系统运行数据，用WPA看DPC/ISR延迟和中断占比；如果稳定性有问题，比如随机蓝屏或内存被踩，就用WinDbg接双机调试；如果怀疑是内存池泄漏，直接用poolmon加Driver Verifier锁tag。

这套组合的思路是：WPR/WPA回答“系统为什么慢”，WinDbg回答“系统为什么崩”，poolmon回答“内存去哪了”。三者面对的问题不同，但共享同一个底层——Windows内核调试符号和ETW事件。所以把符号路径配置好是整个工作流的地基。

3.2 性能追踪与调试回放怎么联动

一个比较进阶的玩法是：先用WPR录制，得到etl文件后，在WPA里打开，定位到性能异常的线程，然后双击线程栈里的某个函数地址，切到WinDbg里对同一地址下断点分析。因为etl带时间戳，你还能在WPA里看某个区间内的调用栈分布，反推在哪个阶段触发问题。

实际操作中，我会给WPA配置符号路径，让栈解析出函数名。WPA的Trace -> Configure Symbol Paths里填上本地符号缓存和微软符号服务器地址。这样分析结果直接能看到函数级别的热点，而不是一堆unresolved模块。

3.3 多工具协同时的符号与路径约定

多工具协同最怕的是版本混乱。我在不同的项目里见到过各种乱象：WDK是个版本，调试器是另一个版本，符号缓存又指向一套不匹配的路径。建议在一开始就统一约定：

• 把所有工具装在同一台专用构建机或开发机上；
• 符号缓存目录固定，比如C:\Symbols，通过环境变量_NT_SYMBOL_PATH统一指向；
• 内核调试的目标机和主机之间使用固定IP或管道名；
• 出问题时，先!analyze -v拿第一手信息，再决定要不要开poolmon或WPR，不要盲目乱试。

4. 安装和配置中反复踩的坑

4.1 版本不匹配：SDK、WDK、Visual Studio的三角关系

这是最多人栽跟头的地方。WDK对SDK版本要求非常严格，比如WDK for Windows 11要求特定版本的SDK和Visual Studio 2022，装错版本，编译驱动的过程中会报各种莫名其妙的头文件错误或链接错误。最典型的是ntddk.h和wdm.h里结构体定义对不上。

我建议的安装方式是：先装Visual Studio（选C++桌面开发工作负载），再装SDK，然后马上装对应版本的WDK，系统会自动检测到SDK。装完在Visual Studio里创建一个Driver项目模板，如果模板能正常编译，说明配套成功。如果编译报错，先检查三个组件的版本号是否匹配官网的兼容表。

4.2 使用WinDbg之前必须配置好符号服务器

WinDbg第一坑是符号。很多人装上WinDbg，打开一个dump，发现栈全是十六进制地址，函数名全是nt+0x1234之类，以为电脑坏了。其实只是没配符号。

设置方法很简单，环境变量里加：

这样WinDbg会自动从微软公共符号服务器下载所需符号到本地缓存。注意，别把缓存路径跟系统盘放在一起，符号包动辄几个G，放在C盘容易爆。

4.3 poolmon不显示tag的应对办法

poolmon默认只会显示系统中已经有分配记录的tag，但很多驱动在加载早期释放了全部内存，poolmon看不到它的活动。这就要用Driver Verifier的Pool Tracking功能。执行：

重启后，verifier会强制启用池追踪，poolmon就能看到该驱动申请的所有tag。这是排查驱动池泄漏的标准前置操作，不开启的话，漏检率很高。

4.4 WPT组件默认不装的陷阱

前面提过，ADK安装器里有一堆组件：Deployment Tools、Imaging And Configuration Designer (ICD)、Windows Performance Toolkit等。默认装的往往只有Deployment Tools。如果你发现没有WPR，回到安装程序里勾选WPT组件单独补装即可，不需要重装整个ADK。

5. 实操案例：用poolmon加WinDbg定位一次非分页池泄漏

5.1 先看现象，再抓基线

假设现在有一个过滤驱动，运行一段时间后系统内存占用持续攀升，任务管理器显示非分页池数值不断上涨。普通工具很难看出是哪个驱动吃的，这时候就该poolmon出场。

先以管理员身份打开命令行，运行：

/p按非分页池排序，/n 20只显示前20行。第一次看到的结果就是基线。正常情况下，稳定系统的poolmon输出里，每个Tag的变化很小；如果某个Tag下的Diff和Bytes单调递增，基本就能锁定它。

5.2 用Driver Verifier让证据更明显

池泄漏的tag不一定能在poolmon里直接看到，因为驱动可能把tag标记成了特殊值，poolmon默认过滤掉了。所以回到前面说的，先给嫌疑驱动开启Driver Verifier的池追踪：

重启后再次运行poolmon，漏掉的tag就会冒出来。此时还可以观察Paged和Nonpaged两列数值，一般驱动内存泄漏以非分页池居多，因为非分页池一旦申请不释放，系统内存会很快告急。

5.3 用WinDbg确认泄漏的调用来源

poolmon只能告诉你哪个tag在涨，不能告诉你谁申请的。定位到Tag之后，用WinDbg的内核内存扩展命令做二次确认：

这个命令会扫描内核池，列出这个Tag对应的所有分配记录，并尝试把分配大小、关联进程信息带出来。如果查不到详细信息，还有一个做法是直接在WinDbg里下断点：在ExAllocatePool2这类分配函数上加断点，然后检查返回地址和调用栈，看是哪个驱动模块发出的请求。

经过这几步，定位基本收敛到具体模块。最后回到源码里，检查该路径下是否存在忘记释放或释放条件不满足的分支。实践中最常见的泄漏原因有两个：一是错误路径上没走到释放代码，二是引用计数管理混乱，导致释放被延迟或跳过。

6. 从会用到用好：我建议的学习路线和心得

很多初学者一上来就啃WinDbg帮助文档，或者满世界找调试技巧，效果其实不好。我建议的路线是先建立“分层认知”：

第一层，先搞清楚每个工具的定位，对应什么问题。不要急着背命令，先明白WPT管性能、WinDbg管崩溃和内存、poolmon管池内存、WDK管驱动构建和签名。

第二层，把每一类工具的基本流程跑通。比如先用WinDbg打开一个历史上真实的蓝屏dump，跑一遍!analyze -v；用WPR录制一次开机过程，用WPA看看启动阶段的热点；用poolmon观察一个正常系统的池分配基线。每个流程循环几遍，形成肌肉记忆。

第三层，开始组合使用，处理真实问题。这时候你才会理解符号配置、版本匹配、驱动验证器这些基础工作的重要性。这个阶段遇到的问题，才是真正值钱的经验。

我自己踩过最大的坑就是版本不匹配。一次为了图方便，在VS2019环境上装了一套新版本WDK，结果编译出的驱动在目标机上报出结构体大小不一致，蓝屏一串错误码，排查了半天才发现是头文件版本导致的内存布局错位。从那以后，我养成了习惯：每次搭建调试环境，先把版本兼容表存下来，装完必须跑一遍模板编译加真实调试验证。

如果你刚接触这套工具链，不要被缩写数量吓到。把ADK、SDK、WDK当成三套独立又互相依赖的“工具箱”，把WPT、WinDbg、poolmon当成工具箱里的三件主力工具，从一条完整的排查流程入手，一步一步走通，比单独学每个工具的命令要快得多。