8、设备栈与IO路径：设备栈概念、IO请求下发、过滤驱动原理、设备栈遍历
设备栈，说白了就是Windows内核里驱动们排队干活的一个结构。你想想看，一个USB鼠标插上去，从总线驱动到功能驱动，中间可能还夹着过滤驱动，它们怎么协作？靠的就是设备栈。我个人习惯把设备栈想象成一个多层蛋糕，每一层都是一个设备对象，IO请求从顶层往下传，处理完了再原路返回。
8.1 设备栈的核心概念
每个设备在Windows内核中都有一个对应的设备对象（DEVICE_OBJECT）。这些设备对象按照一定的顺序串在一起，就形成了设备栈。最顶层通常是功能驱动创建的FDO（功能设备对象），最底层是总线驱动创建的PDO（物理设备对象），中间可能还有过滤驱动创建的FiDO（过滤设备对象）。
我在项目中遇到过一个问题：一个存储设备的读写速度异常慢。排查了半天，发现是某个杀毒软件在设备栈里插了一个过滤驱动，每个IO请求都要经过它扫描一遍。这就是设备栈的典型影响——每一层都会增加开销。
设备栈的关键角色：
- PDO（物理设备对象）：由总线驱动创建，代表物理硬件
- FDO（功能设备对象）：由功能驱动创建，实现设备的主要功能
- FiDO（过滤设备对象）：由过滤驱动创建，用于拦截或修改IO请求
嗯，这里要注意：设备栈的建立顺序是固定的。PnP管理器先加载总线驱动，总线驱动枚举设备后创建PDO。然后PnP管理器根据设备硬件ID查找匹配的功能驱动和过滤驱动，依次加载并创建设备对象，最终形成完整的设备栈。
8.2 IO请求的下发路径
当一个应用程序调用ReadFile或WriteFile时，IO管理器会创建一个IRP（IO请求包）。这个IRP从设备栈的顶层开始，一层一层往下传。每一层的驱动都可以处理这个IRP，也可以直接传给下一层。
IRP的下发过程，我习惯用「接力赛」来理解。每一棒（驱动）拿到IRP后，要么自己处理完就结束比赛（完成IRP），要么传给下一棒。如果某一棒处理不了，就原样往下传。最底层的总线驱动通常负责和硬件打交道，处理完后再把结果原路返回。
个人经验：调试IRP下发路径时，我最常用的工具是 !irp 扩展命令。在WinDbg里输入 !irp [IRP地址]，就能看到IRP当前在哪个设备对象上，以及已经经过了哪些驱动。我曾经靠这个命令定位过一个网卡驱动蓝屏问题——发现IRP在某个过滤驱动里被错误地完成了两次。
IRP的下发有几个关键步骤：
- 创建IRP：IO管理器根据用户请求创建IRP，设置MajorFunction和MinorFunction
- 查找设备栈：通过文件对象找到设备栈的顶层设备对象
- 调用派遣函数：调用当前设备对象的派遣函数，驱动处理IRP
- 传递IRP：驱动调用IoCallDriver将IRP传给下一层设备对象
- 完成IRP：底层驱动处理完后，调用IoCompleteRequest完成IRP
8.3 过滤驱动的工作原理
过滤驱动，说白了就是「插队」的驱动。它不直接管理硬件，而是在设备栈中拦截IRP，做一些额外处理。比如加密过滤驱动可以在写入数据前加密，读取数据后解密；监控过滤驱动可以记录所有IO操作。
我曾经接手过一个项目，客户要求对U盘的所有读写操作进行审计。正常思路是改文件系统驱动，但那太复杂了。我选择写一个上层过滤驱动，挂在卷设备栈上。每次IRP经过时，我把操作类型、文件名、时间戳记录下来。嗯，这个方案两周就搞定了，客户很满意。
避坑指南：写过滤驱动时，最容易犯的错误是忘记调用IoSkipCurrentIrpStackLocation。如果你不跳过当前栈位置，直接调用IoCallDriver，IRP的栈位置会被覆盖，导致下层驱动拿不到正确的参数。我曾经因为这个bug调试了整整两天，最后发现就是少了一行代码。
过滤驱动的注册方式有两种：
| 注册方式 | 说明 | 适用场景 |
|---|---|---|
| 服务方式 | 通过SCM注册为服务，在注册表中添加UpperFilters或LowerFilters值 | 设备类过滤驱动，影响整个设备类 |
| INF方式 | 在驱动INF文件中指定过滤关系 | 设备实例过滤驱动，只影响特定设备 |
8.4 设备栈遍历技术
有时候我们需要查看当前设备栈里有哪些驱动。比如排查性能问题，或者确认过滤驱动是否成功加载。遍历设备栈的核心API是IoGetDeviceObjectPointer和IoGetLowerDeviceObject。
我个人习惯写一个辅助函数，递归遍历设备栈并打印每个设备对象的信息。下面是一个简化版的实现：
// 遍历设备栈并打印信息
void TraverseDeviceStack(PDEVICE_OBJECT DeviceObject)
{
PDEVICE_OBJECT current = DeviceObject;
int level = 0;
while (current != NULL)
{
// 获取设备对象的驱动对象
PDRIVER_OBJECT driverObj = current->DriverObject;
DbgPrint("[Level %d] Device: 0x%p, Driver: %wZ\n",
level, current,
driverObj ? &driverObj->DriverName : NULL);
// 获取下层设备对象
PDEVICE_OBJECT lower = IoGetLowerDeviceObject(current);
// 释放引用计数
if (lower != NULL)
{
ObDereferenceObject(lower);
}
current = lower;
level++;
}
}关键点：调用IoGetLowerDeviceObject返回的设备对象会增加引用计数，使用完后必须调用ObDereferenceObject释放。否则会造成内存泄漏，这在长时间运行的内核驱动中是致命的。
遍历设备栈时，有几个实用技巧：
- 从文件对象出发：通过IoGetRelatedDeviceObject从文件对象获取顶层设备对象
- 检查设备类型：通过DeviceObject->DeviceType判断设备类型（FILE_DEVICE_DISK等）
- 查看标志位：DeviceObject->Flags包含DO_BUFFERED_IO等重要标志
- 注意同步：遍历过程中设备栈可能发生变化，建议在遍历前获取适当的锁
你想想看，掌握了设备栈遍历，就等于有了X光机，能看清驱动层的每一层结构。调试时遇到IRP没被正确处理，第一件事就是遍历设备栈，看看是不是有过滤驱动插在中间捣乱。
嗯，最后说一句。设备栈是Windows驱动开发的基石，理解了它，你就理解了IO请求的整个生命周期。从应用层到硬件，中间经过的每一层驱动都在设备栈里各司其职。写过滤驱动时，时刻记住：你只是设备栈中的一个过客，不要破坏上下层之间的契约。