Mini-filter的资源的引用计数的泄露一例

2: kd> g
[FltMgr] Mini-filter verification enabled for "MagicArmorDrv" filter.
FILTER VERIFIER ERROR:   A filter (Filter = FFFFDE02BC2C0680 (MagicArmorDrv)) leaked references to the following resources:
00000000 Filter Context Structures
00000000 FLT_CALLBACK_DATA structures
00000000 FLT_DEFERRED_IO_WORKITEM structures
00000000 FLT_GENERIC_WORKITEM structures
00000000 FLT_FILE_NAME_INFORMATION structures
00000016 FILE_OBJECT structures
00000000 FLT_OBJECT structures
00000000 ECP context structures
Type "!fltkd.filter FFFFDE02BC2C0680 8 1" in the debugger for a list of leaked

Break, ignore, zap or remove ? b
b
Breaking in... (press g<enter> to return to assert menu)
Break instruction exception - code 80000003 (first chance)
FLTMGR!FltpvPrintErrors+0x1ed:
fffff801`4471da15 cc              int     3
4: kd> !fltkd.filter FFFFDE02BC2C0680 8 1

FLT_FILTER: ffffde02bc2c0680 "MagicArmorDrv" "[ERROR READING NAME]"
   InstanceList             : (ffffde02bc2c06e8)
      Resource (ffffde02bc2c0750) List [ffffde02bc2c0750-ffffde02bc2c0750] rCount=0
   Object usage/reference information:
      References to FLT_CONTEXT                : 0
      Allocations of FLT_CALLBACK_DATA         : 0
      Allocations of FLT_DEFERRED_IO_WORKITEM  : 0
      Allocations of FLT_GENERIC_WORKITEM      : 0
      References to FLT_FILE_NAME_INFORMATION  : 0
      Open files                               : 16
      References to FLT_OBJECT                 : 0
   List of objects used/referenced::
      FLT_VERIFIER_OBJECT: ffffde02bea033e0
         Object: ffffde02bc6497f0  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bea03b00
         Object: ffffde02bc6499a0  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bea12c20
         Object: ffffde02bc64a3c0  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bea11f00
         Object: ffffde02be049760  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bf88f9a0
         Object: ffffde02be04c850  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bd4cda20
         Object: ffffde02bf423140  Type: FILE_OBJECT  RefCount: 00000002
      FLT_VERIFIER_OBJECT: ffffde02bea04dc0
         Object: ffffde02bf42f350  Type: FILE_OBJECT  RefCount: 00000002
      FLT_VERIFIER_OBJECT: ffffde02bea11780
         Object: ffffde02bf431d80  Type: FILE_OBJECT  RefCount: 00000005
      FLT_VERIFIER_OBJECT: ffffde02bea12b00
         Object: ffffde02bf43b560  Type: FILE_OBJECT  RefCount: 00000001
      FLT_VERIFIER_OBJECT: ffffde02bf87ba20
         Object: ffffde02bf8ba220  Type: FILE_OBJECT  RefCount: 00000001
4: kd> !fileobj ffffde02bf8ba220



Device Object: 0xffffde02b271d8f0   \Driver\cdrom
Vpb is NULL

Flags:  0x40802
Synchronous IO
Direct Device Open
Handle Created

CurrentByteOffset: 0


--------------------------------------------------------------------------------------------------


刚开始以为是：FLT_CALLBACK_DATA导致的。
又怀疑是FLT_FILE_NAME_INFORMATION导致的。

其实上面写的很清楚，是FILE_OBJECT导致的。

检查代码，上下文该释放的都释放了。
最后用代码二分屏蔽发定位到了某个函数。
看这个函数，句柄也没有泄露，该关闭的也都关闭了。

猛地看到：ZwClose，但是它的句柄是FltCreateFile获取的。
是不是这里的问题？

经过查看FltCreateFile的文档发现：
Any handle that is obtained from FltCreateFile must eventually be released by calling FltClose.

把ZwClose改为FltClose，再也没有出现这个问题了。

看来ZwClose和FltClose还是有差别的，至少在处理上下文的处理上不一样。

made by correy
https://correy.webs.com