聊一聊 .NET 高级调试内核模式堆泄露-51CTO.COM

一、背景

1. 讲故事

前几天有位朋友找到我，说他的机器内存在不断的上涨，但在任务管理器中查不出是哪个进程吃的内存，特别奇怪，截图如下：

图片

在我的分析旅程中都是用户态模式的内存泄漏，像上图中的异常征兆已经明确告诉你了，不是用户态程序吃的内存，那就是内核态程序吃的，比如：

某些驱动程序
操作系统

从概率上来说一般都是某些第三方程序内存泄露导致的，这一篇我们就来聊一聊这种问题该如何解决。

二、内核模式堆泄露分析

1. 驱动程序是如何分配内存的

相信有很多朋友都知道，用户态的程序是直接或者间接的调用 VirtualAlloc 方法来向操作系统要内存，包括 C# 的 GC 堆也是一样，它的方法签名如下：

LPVOID VirtualAlloc(
  [in, optional] LPVOID lpAddress,
  [in]           SIZE_T dwSize,
  [in]           DWORD  flAllocationType,
  [in]           DWORD  flProtect
);1.
2.
3.
4.
5.
6.

那内核中的驱动程序是如何向操作系统要内存的呢？一般都是调用 ExAllocatePool2 方法来要内存的，签名如下：

DECLSPEC_RESTRICT PVOID ExAllocatePool2(
  POOL_FLAGS Flags,
  SIZE_T     NumberOfBytes,
  ULONG      Tag
);1.
2.
3.
4.
5.

上面有两个参数要详细解释一下：

Flags 参数

一般用的多的就是 POOL_FLAG_NON_PAGED 和 POOL_FLAG_PAGED 两种，前者表示分配的内存是需要永久驻留内存，不可以交换到硬盘的。后者分配的内存是可以交换到硬盘的。

Tag 参数

这个参数的本意就是方便日后洞察内存泄露的，它强行让一块内存和这个 Tag(4byte的ascii 字符串) 做了强绑定，到时候通过这个 tag 就知道是谁分配的内存。

2. 制造内核模式堆泄露

为了能够让驱动程序泄露，可以使用微软提供的 NotMyFault 工具，这个工具利用 myfault.sys 驱动不断的向操作系统分配内存。官方网址为：https://learn.microsoft.com/zh-cn/sysinternals/downloads/notmyfault

打开 myfault 工具然后输入 40M/s 的泄露，并分配在非换页池中，同时配置下内核态转储dump，代码和截图参考如下：

ExAllocatePool2(POOL_FLAG_NON_PAGED,40*1024*1024,"Leak");1.

图片

在泄露的过程中，通过 Process Explorer 很明显的发现提交了 6.7G 的内存，其中有 4.9G 是在 NonPaged 中，即通过上图中的 POOL_FLAG_NON_PAGED 标记分配的，截图如下：

图片

接下来在 MyFault 上切换到 Crash 选项卡，强行让操作系统蓝屏来生成 dump 文件。

3. dump 分析

拿到dump后，先通过 !vm 观察下操作系统级的虚拟内存的分布情况。

3: kd> !vm
...
Physical Memory:          2069421 (    8277684 Kb)
Available Pages:           445015 (    1780060 Kb)
ResAvail Pages:            707292 (    2829168 Kb)
Locked IO Pages:                0 (          0 Kb)
Free System PTEs:      4295052431 (17180209724 Kb)
...
Modified Pages:             11479 (      45916 Kb)
Modified PF Pages:          11479 (      45916 Kb)
Modified No Write Pages:        0 (          0 Kb)
NonPagedPool Usage:       1219892 (    4879568 Kb)
NonPagedPoolNx Usage:       24512 (      98048 Kb)
NonPagedPool Max:      4294967296 (17179869184 Kb)
PagedPool Usage:            32907 (     131628 Kb)
PagedPool Maximum:     4294967296 (17179869184 Kb)
...
NonPagedPool Commit:      1246469 (    4985876 Kb)
...
Sum System Commit:        1409562 (    5638248 Kb)
Total Private:             279673 (    1118692 Kb)

********** Sum of individual system commit + Process commit exceeds overall commit by 1952 Kb ? ********
Committed pages:          1688747 (    6754988 Kb)
Commit limit:             4166573 (   16666292 Kb)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.

从卦中的 NonPagedPool Usage 指标可以看到，当前的非换页池占用了 4.8G 内存，总计 121w 的内存页。

接下来就是要深挖下非换页池，看看到底都是什么 Tag 分配的，可以使用 !poolused 2 命令。

3: kd> !poolused 2
....
 Sorting by NonPaged Pool Consumed

               NonPaged                  Paged
 Tag     Allocs         Used     Allocs         Used

 Leak       119   4991221760          0            0 UNKNOWN pooltag 'Leak', please update pooltag.txt
 ConT       238     14499840          0            0 UNKNOWN pooltag 'ConT', please update pooltag.txt
 KETR     16410      8117664          0            0 UNKNOWN pooltag 'KETR', please update pooltag.txt
 EtwB       196      7565568          2       131072 Etw Buffer , Binary: nt!etw
 2872         6      5660864          0            0 UNKNOWN pooltag '2872', please update pooltag.txt
 287R      1026      4183040          0            0 UNKNOWN pooltag '287R', please update pooltag.txt
 File      9734      3877408          0            0 File objects 
 Thre      1257      3217920          0            0 Thread objects , Binary: nt!ps
 EtwR     12141      2672640          0            0 Etw KM RegEntry , Binary: nt!etw
...1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

从卦中数据看，有一个神秘的 Tag=Leak 的内存分配，它分配了 119 次，总大小 4.99G。哈哈，其实就是刚才通过 MyFault 做的 40M/s 的内存分配。

接下来的问题是：这个 Leak 是哪一个驱动程序所为呢？最简单的办法就是在各个驱动的内存空间中做内存搜索，看看谁里面有 Leak 的asc硬编码，对吧，有了这个思路，先用 lm 看看里面都有哪些 sys 。

3: kd> lm
start             end                 module name
ffffc25c`891b0000 ffffc25c`89480000   win32kbase   (deferred)             
ffffc25c`8a190000 ffffc25c`8a545000   win32kfull   (deferred)     
...                  
fffff807`22600000 fffff807`23646000   nt         (pdb symbols) 
fffff807`23c00000 fffff807`23d16000   clipsp     (deferred)             
fffff807`47f30000 fffff807`47f4b000   monitor    (deferred)             
fffff807`47f50000 fffff807`47f59000   myfault    (deferred)             
...          

Unloaded modules:
fffff807`3c6e0000 fffff807`3c6ec000   360Sensor64.sys
fffff807`31550000 fffff807`31560000   dump_storport.sys
fffff807`315a0000 fffff807`315d3000   dump_storahci.sys
fffff807`31000000 fffff807`3101e000   dump_dumpfve.sys
fffff807`26b80000 fffff807`26bac000   luafv.sys
fffff807`26b20000 fffff807`26b30000   dump_storport.sys
fffff807`26b70000 fffff807`26ba3000   dump_storahci.sys
fffff807`26bd0000 fffff807`26bee000   dump_dumpfve.sys
fffff807`28130000 fffff807`2814c000   dam.sys 
fffff807`24200000 fffff807`2420a000   360elam64.sys
fffff807`25230000 fffff807`25241000   hwpolicy.sys1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

接下来就是写脚本在每个 sys 的 start ~ end 区间做 s 搜索，这个脚本我就不放了，非常简单，最终就在 myfault.sys 中成功找到了 Leak 硬编码，参考如下：

3: kd> lmvm myfault
Browse full module list
start             end                 module name
fffff807`47f50000 fffff807`47f59000   myfault    (deferred)             
    Image path: \??\C:\Windows\system32\drivers\myfault.sys
    Image name: myfault.sys
    Browse all global symbols  functions  data
    Timestamp:        Fri Sep 30 00:17:31 2022 (6335C51B)
    CheckSum:         00010CED
    ImageSize:        00009000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
    
3: kd> ? fffff807`47f59000 - fffff807`47f50000
Evaluate expression: 36864 = 00000000`00009000

3: kd> s -a fffff807`47f50000 L?0x9000  "Leak"
fffff807`47f51559  4c 65 61 6b 0f 42 c1 41-8d 49 fd 8b d0 ff 15 0c  Leak.B.A.I......
fffff807`47f515c7  4c 65 61 6b 0f 42 c1 33-c9 8b d0 ff 15 a0 1a 00  Leak.B.3........1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

三、总结

在过往的dump分析中都是用户态程序的泄露，内核态模式堆的的泄露还是第一次分析，不是朋友提供的这次机会，真的就没缘分啦！在这次dump分析过程中，也让大家看到了 windbg 是多么的强大！