内存转储分析不能直接确认驱动程序内存泄漏，因其仅保存崩溃瞬间快照，无法反映长期分配历史；需通过!analyze -v查bugcheckcode（如0xc2/0xd1）、!poolfee定位高占用tag、结合poolmon实时监控等交叉验证。

内存转储分析本身不能直接确认“驱动程序内存泄漏”，因为标准蓝屏转储（尤其是 minidump 或 kernel dump）不记录长期运行中的内存分配历史、未释放堆块或池使用趋势——它只保存崩溃**瞬间**的内存快照。所谓“内存泄漏导致蓝屏”，实际多表现为：泄漏持续消耗非分页池（nonpagedpool），最终触发 0x000000c2（bad_pool_caller）、0x000000d1（driver_irql_not_less_or_equal）或 0x000000ef（critical_process_died）等错误，本质是池耗尽后驱动在高 irql 下非法访问空指针或已释放内存。

先确认是否真为池泄漏型蓝屏

打开 WinDbg Preview 加载 .dmp 后，执行：
!analyze -v
重点看三处：

• BugCheckCode 是否为 0xC2、0xD1、0xEF、0x50（PAGE_FAULT_IN_NONPAGED_AREA，常因池耗尽后访问无效地址）
• POOL_CORRUPTION 或 POOL_BYTE_COUNT 类关键词是否出现在分析摘要中
• Probably caused by 行指向的驱动，是否在后续堆栈中反复出现在 ExAllocatePoolWithTag / ExFreePoolWithTag 调用上下文里

查非分页池占用大户（关键步骤）

执行以下命令定位异常消耗者：

• !poolfee —— 显示按 Tag 分组的非分页池总用量（单位：字节）。重点关注占用 >10MB 的 Tag，例如 VADa、Ntfs、Drvr 等；第三方驱动常用自定义 Tag，如 RT64（瑞昱网卡）、NVDA（NVIDIA）、AVXX（某杀软）
• !poolfind —— 例如 !poolfind NVDA，列出该 Tag 所有分配块地址，可配合 !pool
  查单个块归属
• !memusage —— 查看整体内存分布，确认 NonPagedPoolUsage 是否接近系统上限（通常 Windows 10/11 x64 默认上限约 75% 物理内存）

结合驱动模块验证泄漏嫌疑

一旦锁定可疑 Tag 和驱动名（如 nvlddmkm.sys 或 xxxfilter.sys）：

Windows-Android_SSH_Remote_Control

通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。

下载

• 执行 lmvm （如 lmvm nvlddmkm），检查文件版本、时间戳、是否签名有效
• 执行 !drivers，看该驱动状态是否为 ACTIVE，且 Pool Usage 列数值异常高
• 对比多次蓝屏的 minidump：用 BlueScreenView 打开多个 .dmp，观察同一驱动是否在每次崩溃中都出现在堆栈顶部，且 !poolfee 中对应 Tag 持续增长

辅助验证与收尾动作

仅靠单次 dump 无法证明“泄漏”，需交叉印证：

• 用 poolmon.exe（WDK 工具）在复现前开启实时监控：
  poolmon -b -p（按池类型排序），观察可疑 Tag 的 Alloc/Frees 差值是否持续扩大
• 检查事件查看器中 ID 1001 日志，看 BugcheckString 是否含 POOL_CORRUPTION 或 BAD_POOL_HEADER
• 卸载或回退该驱动至旧版（尤其注意 NVIDIA/AMD/Realtek/杀软驱动的“最新版”常引入池管理缺陷）