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
[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