驱动程序内存泄漏深度排查指南

52JinY 助手

最近排查了一次驱动程序内存泄漏，感触挺深。很多人一提到内存泄漏，第一反应就是“某个分配没有释放”，这当然没错，但放在驱动层面，事情往往没有这么直白。驱动运行在内核态，生命周期复杂，错误路径多，资源类型也不只是普通内存，还包括 MDL、IRP、句柄、引用计数对象、DMA 缓冲区等。真正难的不是发现泄漏，而是判断它到底在哪条路径上被遗忘了。

我个人觉得，分析驱动内存泄漏最重要的一点，是先把“资源所有权”理清楚。谁申请，谁释放；谁增加引用，谁减少引用；对象是否跨线程、跨回调、跨设备状态流转，这些都要明确。很多泄漏并不是主流程里忘了释放，而是在异常分支、设备移除、初始化失败回滚、请求取消回调里漏掉了一步。尤其是驱动初始化阶段，如果第 4 步失败，前 3 步申请的资源是否都按相反顺序释放，特别容易被忽略。

工具方面，Windows 驱动可以优先看 PoolMon、Driver Verifier、WPP/ETW 日志以及 WinDbg。PoolMon 很适合从 Tag 入手，看某个池标签的分配数量和字节数是否持续增长。Driver Verifier 则更“狠”一些，可以暴露很多平时不容易复现的问题，比如池损坏、IRQL 不匹配、引用计数异常等。我的经验是，不要一上来就开全部选项，否则系统可能很快蓝屏，定位反而变得混乱。先针对目标驱动开启专项检查，配合稳定复现路径，效率更高。

代码层面，内存分配最好统一封装，并且强制使用有意义的 Pool Tag。一个清晰的 Tag 能节省大量时间。反过来，如果整个驱动里到处都是随手分配、Tag 混乱，后期排查就会非常痛苦。还有一点容易被低估：日志必须记录关键资源的创建和销毁，尤其是对象指针、大小、状态、请求 ID。日志不是越多越好，而是要能串起对象的一生。

分析泄漏时，我通常会先做压力测试，看内存是否随操作次数线性增长。如果每执行一次打开关闭设备、发送 IOCTL、插拔设备，池内存就稳定增加，那基本可以锁定在对应路径。然后缩小范围，比如只跑打开关闭、不发请求；只发同步请求、不发异步请求；只走成功路径、不触发取消路径。驱动问题怕的不是复杂，而是没有切分。只要能把复现路径压缩到最小，后面就是体力活。

还有一种情况比较隐蔽：看起来像泄漏，其实是缓存或延迟释放。比如驱动内部维护 lookaside list、对象池，或者系统本身对某些内核对象有延迟回收机制。这时候不能只看瞬时内存增长，而要看长期趋势和释放触发条件。判断泄漏一定要结合业务语义，不能看到数字涨了就下结论。

最后想说，驱动内存泄漏分析不太适合靠“猜”。它更像是在还原一条资源流转链：资源从哪里来，经过谁，什么时候应该结束，为什么没有结束。平时写代码时多做成对释放、统一出口、失败回滚和引用计数检查，排查时就会轻松很多。驱动开发里，稳定性往往不是靠最后一轮测试补出来的，而是在每一次资源管理细节里慢慢攒出来的。