I’m having a heck of a time trying to find a leaked reference that is preventing my filter from unloading. It’s hanging at FltUnregisterFilter. Just to clear the common suggestions, I don’t have any outstanding pool allocations or any ActiveOpens (WinDbg printouts below). I also removed all of my communications code to help find the leak but still no dice.
I thought I narrowed it down to a file reference that wasn’t being closed, but I added a linked list of currently opened files and then looped through to close any open ones during the Instance Cleanup routine. I’m kind of running out of ideas on where it may be but more importantly how to find it. Any suggestions would be appreciated. Thanks.
kd> !verifier 3
Verify Level 809 … enabled options are:
Special pool
All pool allocations checked on unload
Miscellaneous checks enabled
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0
Pool Allocations Attempted 0x4a8
Pool Allocations Succeeded 0x4a8
Pool Allocations Succeeded SpecialPool 0x4a8
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x27 for 00005B44 bytes
kd> !fltkd.filters DRIVER
Filter List: fffffa80027cf0c0 “Frame 0”
FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
RundownRef : 0xfffff88002f5f961
Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address: fffff88002f5f960
PointerCount : 0x00000002
PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
Frame : fffffa80027cf010 “Frame 0”
Flags : [00000006] FilteringInitiated NameProvider
DriverObject : fffffa80042f5e70
FilterLink : [fffffa8004054750-fffffa80027cf0c0]
PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
PostVolumeMount : 0000000000000000 (null)
FilterUnload : fffff88003395010 DRIVER!FilterUnload
InstanceSetup : fffff88003395110 DRIVER!Setup
InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
InstanceTeardownStart : fffff880033749b0 DRIVER!InstanceTeardownStart
InstanceTeardownComplete : fffff88003374ac0 DRIVER!InstanceTeardownComplete
ActiveOpens : (fffffa8002f8b8e8) mCount=0
Communication Port List : (fffffa8002f8b938) mCount=0
Client Port List : (fffffa8002f8b988) mCount=0
VerifierExtension : 0000000000000000
Operations : fffffa8002f8b9e0
OldDriverUnload : 0000000000000000 (null)
Could not read field “AllocationType” of FltMgr!_ALLOCATE_CONTEXT_HEADER from address: 202444c74838ec83
Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from address: 0000000000000000
—
You don’t mention the OS where you are seeing this. If it’s Windows Vista, search the archive for an old issue with mini-filter unloading. AFAIK, that fix never made it to Vista, but I haven’t looked at it in quite some time.
Phil
Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant (2012-2014)
Perfect 5-Star Rating in SC Magazine (2009-2014)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, September 08, 2014 9:08 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Unload hangs at FltUnregisterFilter
I’m having a heck of a time trying to find a leaked reference that is preventing my filter from unloading. It’s hanging at FltUnregisterFilter. Just to clear the common suggestions, I don’t have any outstanding pool allocations or any ActiveOpens (WinDbg printouts below). I also removed all of my communications code to help find the leak but still no dice.
I thought I narrowed it down to a file reference that wasn’t being closed, but I added a linked list of currently opened files and then looped through to close any open ones during the Instance Cleanup routine. I’m kind of running out of ideas on where it may be but more importantly how to find it. Any suggestions would be appreciated. Thanks.
kd> !verifier 3
Verify Level 809 … enabled options are:
Special pool
All pool allocations checked on unload
Miscellaneous checks enabled
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0
Pool Allocations Attempted 0x4a8
Pool Allocations Succeeded 0x4a8
Pool Allocations Succeeded SpecialPool 0x4a8
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x27 for 00005B44 bytes
kd> !fltkd.filters DRIVER
Filter List: fffffa80027cf0c0 “Frame 0”
FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
RundownRef : 0xfffff88002f5f961
Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address: fffff88002f5f960
PointerCount : 0x00000002
PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
Frame : fffffa80027cf010 “Frame 0”
Flags : [00000006] FilteringInitiated NameProvider
DriverObject : fffffa80042f5e70
FilterLink : [fffffa8004054750-fffffa80027cf0c0]
PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
PostVolumeMount : 0000000000000000 (null)
FilterUnload : fffff88003395010 DRIVER!FilterUnload
InstanceSetup : fffff88003395110 DRIVER!Setup
InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
InstanceTeardownStart : fffff880033749b0 DRIVER!InstanceTeardownStart
InstanceTeardownComplete : fffff88003374ac0 DRIVER!InstanceTeardownComplete
ActiveOpens : (fffffa8002f8b8e8) mCount=0
Communication Port List : (fffffa8002f8b938) mCount=0
Client Port List : (fffffa8002f8b988) mCount=0
VerifierExtension : 0000000000000000
Operations : fffffa8002f8b9e0
OldDriverUnload : 0000000000000000 (null)
Could not read field “AllocationType” of FltMgr!_ALLOCATE_CONTEXT_HEADER from address: 202444c74838ec83 Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from address: 0000000000000000
—
—
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I can’t tell what’s wrong at a first glance. Is it possible there’s a
reference count leak count ? Like, the PointerCount on the FLT_OBJECT is
0x00000002 (it may be right, I don’t remember exactly how that works )…
Try to load passthrough, put a breakpoint on unload and compare the
reference counts.
Alex.
On Mon, Sep 8, 2014 at 8:08 AM, wrote:
> I’m having a heck of a time trying to find a leaked reference that is
> preventing my filter from unloading. It’s hanging at FltUnregisterFilter.
> Just to clear the common suggestions, I don’t have any outstanding pool
> allocations or any ActiveOpens (WinDbg printouts below). I also removed
> all of my communications code to help find the leak but still no dice.
>
> I thought I narrowed it down to a file reference that wasn’t being closed,
> but I added a linked list of currently opened files and then looped through
> to close any open ones during the Instance Cleanup routine. I’m kind of
> running out of ideas on where it may be but more importantly how to find
> it. Any suggestions would be appreciated. Thanks.
>
>
> kd> !verifier 3
>
> Verify Level 809 … enabled options are:
> Special pool
> All pool allocations checked on unload
> Miscellaneous checks enabled
>
> Summary of All Verifier Statistics
>
> RaiseIrqls 0x0
> AcquireSpinLocks 0x0
> Synch Executions 0x0
> Trims 0x0
>
> Pool Allocations Attempted 0x4a8
> Pool Allocations Succeeded 0x4a8
> Pool Allocations Succeeded SpecialPool 0x4a8
> Pool Allocations With NO TAG 0x0
> Pool Allocations Failed 0x0
> Resource Allocations Failed Deliberately 0x0
>
> Current paged pool allocations 0x0 for 00000000 bytes
> Peak paged pool allocations 0x0 for 00000000 bytes
> Current nonpaged pool allocations 0x0 for 00000000 bytes
> Peak nonpaged pool allocations 0x27 for 00005B44 bytes
>
> kd> !fltkd.filters DRIVER
> Filter List: fffffa80027cf0c0 “Frame 0”
> FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
> FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
> RundownRef : 0xfffff88002f5f961
> Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address:
> fffff88002f5f960
> PointerCount : 0x00000002
> PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
> Frame : fffffa80027cf010 “Frame 0”
> Flags : [00000006] FilteringInitiated NameProvider
> DriverObject : fffffa80042f5e70
> FilterLink : [fffffa8004054750-fffffa80027cf0c0]
> PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
> PostVolumeMount : 0000000000000000 (null)
> FilterUnload : fffff88003395010 DRIVER!FilterUnload
> InstanceSetup : fffff88003395110 DRIVER!Setup
> InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
> InstanceTeardownStart : fffff880033749b0
> DRIVER!InstanceTeardownStart
> InstanceTeardownComplete : fffff88003374ac0
> DRIVER!InstanceTeardownComplete
> ActiveOpens : (fffffa8002f8b8e8) mCount=0
> Communication Port List : (fffffa8002f8b938) mCount=0
> Client Port List : (fffffa8002f8b988) mCount=0
> VerifierExtension : 0000000000000000
> Operations : fffffa8002f8b9e0
> OldDriverUnload : 0000000000000000 (null)
> Could not read field “AllocationType” of FltMgr!_ALLOCATE_CONTEXT_HEADER
> from address: 202444c74838ec83
> Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from
> address: 0000000000000000
> —
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Sorry. Win7 x64 running in a VM.
Thanks Alex. I’ve read your various postings (
http://fsfilters.blogspot.com/2011/12/debugging-minifilters-using-fltkdfilter.html
,
http://fsfilters.blogspot.com/2011/02/tracking-minifilters-activeopens-files.html)
on this issue but no luck. I’ll try with passthrough and compare.
On Mon, Sep 8, 2014 at 12:09 PM, Alex Carp
wrote:
> I can’t tell what’s wrong at a first glance. Is it possible there’s a
> reference count leak count ? Like, the PointerCount on the FLT_OBJECT is
> 0x00000002 (it may be right, I don’t remember exactly how that works )…
> Try to load passthrough, put a breakpoint on unload and compare the
> reference counts.
>
> Alex.
>
>
> On Mon, Sep 8, 2014 at 8:08 AM, wrote:
>
>> I’m having a heck of a time trying to find a leaked reference that is
>> preventing my filter from unloading. It’s hanging at FltUnregisterFilter.
>> Just to clear the common suggestions, I don’t have any outstanding pool
>> allocations or any ActiveOpens (WinDbg printouts below). I also removed
>> all of my communications code to help find the leak but still no dice.
>>
>> I thought I narrowed it down to a file reference that wasn’t being
>> closed, but I added a linked list of currently opened files and then looped
>> through to close any open ones during the Instance Cleanup routine. I’m
>> kind of running out of ideas on where it may be but more importantly how to
>> find it. Any suggestions would be appreciated. Thanks.
>>
>>
>> kd> !verifier 3
>>
>> Verify Level 809 … enabled options are:
>> Special pool
>> All pool allocations checked on unload
>> Miscellaneous checks enabled
>>
>> Summary of All Verifier Statistics
>>
>> RaiseIrqls 0x0
>> AcquireSpinLocks 0x0
>> Synch Executions 0x0
>> Trims 0x0
>>
>> Pool Allocations Attempted 0x4a8
>> Pool Allocations Succeeded 0x4a8
>> Pool Allocations Succeeded SpecialPool 0x4a8
>> Pool Allocations With NO TAG 0x0
>> Pool Allocations Failed 0x0
>> Resource Allocations Failed Deliberately 0x0
>>
>> Current paged pool allocations 0x0 for 00000000 bytes
>> Peak paged pool allocations 0x0 for 00000000 bytes
>> Current nonpaged pool allocations 0x0 for 00000000 bytes
>> Peak nonpaged pool allocations 0x27 for 00005B44 bytes
>>
>> kd> !fltkd.filters DRIVER
>> Filter List: fffffa80027cf0c0 “Frame 0”
>> FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
>> FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
>> RundownRef : 0xfffff88002f5f961
>> Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address:
>> fffff88002f5f960
>> PointerCount : 0x00000002
>> PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
>> Frame : fffffa80027cf010 “Frame 0”
>> Flags : [00000006] FilteringInitiated
>> NameProvider
>> DriverObject : fffffa80042f5e70
>> FilterLink : [fffffa8004054750-fffffa80027cf0c0]
>> PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
>> PostVolumeMount : 0000000000000000 (null)
>> FilterUnload : fffff88003395010 DRIVER!FilterUnload
>> InstanceSetup : fffff88003395110 DRIVER!Setup
>> InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
>> InstanceTeardownStart : fffff880033749b0
>> DRIVER!InstanceTeardownStart
>> InstanceTeardownComplete : fffff88003374ac0
>> DRIVER!InstanceTeardownComplete
>> ActiveOpens : (fffffa8002f8b8e8) mCount=0
>> Communication Port List : (fffffa8002f8b938) mCount=0
>> Client Port List : (fffffa8002f8b988) mCount=0
>> VerifierExtension : 0000000000000000
>> Operations : fffffa8002f8b9e0
>> OldDriverUnload : 0000000000000000 (null)
>> Could not read field “AllocationType” of FltMgr!_ALLOCATE_CONTEXT_HEADER
>> from address: 202444c74838ec83
>> Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from
>> address: 0000000000000000
>> —
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Here’s the printout for passthrough. PointerCount is 0x2 like mine.
However, RundownRef values are very different (value vs pointer to
something). And if you notice on the printout I posted earlier, there’s an
error right under the RundownRef value (“Could not read field “Count” of
nt!_EX_RUNDOWN_WAIT_BLOCK from address: fffff88002f5f960”).
Alex, I’ve read your write up on RundownRef. Do you have any more insight
into this? Thanks.
Filter List: fffffa80027cf0c0 “Frame 0”
FLT_FILTER: fffffa8004272850 “PassThrough” “370030”
FLT_OBJECT: fffffa8004272850 [02000000] Filter
RundownRef : 0x000000000000000a (5)
PointerCount : 0x00000002
PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
On Mon, Sep 8, 2014 at 12:52 PM, Paul wrote:
> Sorry. Win7 x64 running in a VM.
>
> Thanks Alex. I’ve read your various postings (
> http://fsfilters.blogspot.com/2011/12/debugging-minifilters-using-fltkdfilter.html
> ,
> http://fsfilters.blogspot.com/2011/02/tracking-minifilters-activeopens-files.html)
> on this issue but no luck. I’ll try with passthrough and compare.
>
>
> On Mon, Sep 8, 2014 at 12:09 PM, Alex Carp
> wrote:
>
>> I can’t tell what’s wrong at a first glance. Is it possible there’s a
>> reference count leak count ? Like, the PointerCount on the FLT_OBJECT is
>> 0x00000002 (it may be right, I don’t remember exactly how that works )…
>> Try to load passthrough, put a breakpoint on unload and compare the
>> reference counts.
>>
>> Alex.
>>
>>
>> On Mon, Sep 8, 2014 at 8:08 AM, wrote:
>>
>>> I’m having a heck of a time trying to find a leaked reference that is
>>> preventing my filter from unloading. It’s hanging at FltUnregisterFilter.
>>> Just to clear the common suggestions, I don’t have any outstanding pool
>>> allocations or any ActiveOpens (WinDbg printouts below). I also removed
>>> all of my communications code to help find the leak but still no dice.
>>>
>>> I thought I narrowed it down to a file reference that wasn’t being
>>> closed, but I added a linked list of currently opened files and then looped
>>> through to close any open ones during the Instance Cleanup routine. I’m
>>> kind of running out of ideas on where it may be but more importantly how to
>>> find it. Any suggestions would be appreciated. Thanks.
>>>
>>>
>>> kd> !verifier 3
>>>
>>> Verify Level 809 … enabled options are:
>>> Special pool
>>> All pool allocations checked on unload
>>> Miscellaneous checks enabled
>>>
>>> Summary of All Verifier Statistics
>>>
>>> RaiseIrqls 0x0
>>> AcquireSpinLocks 0x0
>>> Synch Executions 0x0
>>> Trims 0x0
>>>
>>> Pool Allocations Attempted 0x4a8
>>> Pool Allocations Succeeded 0x4a8
>>> Pool Allocations Succeeded SpecialPool 0x4a8
>>> Pool Allocations With NO TAG 0x0
>>> Pool Allocations Failed 0x0
>>> Resource Allocations Failed Deliberately 0x0
>>>
>>> Current paged pool allocations 0x0 for 00000000 bytes
>>> Peak paged pool allocations 0x0 for 00000000 bytes
>>> Current nonpaged pool allocations 0x0 for 00000000 bytes
>>> Peak nonpaged pool allocations 0x27 for 00005B44 bytes
>>>
>>> kd> !fltkd.filters DRIVER
>>> Filter List: fffffa80027cf0c0 “Frame 0”
>>> FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
>>> FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
>>> RundownRef : 0xfffff88002f5f961
>>> Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address:
>>> fffff88002f5f960
>>> PointerCount : 0x00000002
>>> PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
>>> Frame : fffffa80027cf010 “Frame 0”
>>> Flags : [00000006] FilteringInitiated
>>> NameProvider
>>> DriverObject : fffffa80042f5e70
>>> FilterLink : [fffffa8004054750-fffffa80027cf0c0]
>>> PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
>>> PostVolumeMount : 0000000000000000 (null)
>>> FilterUnload : fffff88003395010 DRIVER!FilterUnload
>>> InstanceSetup : fffff88003395110 DRIVER!Setup
>>> InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
>>> InstanceTeardownStart : fffff880033749b0
>>> DRIVER!InstanceTeardownStart
>>> InstanceTeardownComplete : fffff88003374ac0
>>> DRIVER!InstanceTeardownComplete
>>> ActiveOpens : (fffffa8002f8b8e8) mCount=0
>>> Communication Port List : (fffffa8002f8b938) mCount=0
>>> Client Port List : (fffffa8002f8b988) mCount=0
>>> VerifierExtension : 0000000000000000
>>> Operations : fffffa8002f8b9e0
>>> OldDriverUnload : 0000000000000000 (null)
>>> Could not read field “AllocationType” of FltMgr!_ALLOCATE_CONTEXT_HEADER
>>> from address: 202444c74838ec83
>>> Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from
>>> address: 0000000000000000
>>> —
>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> OSR is hiring!! Info at http://www.osr.com/careers
>>>
>>> For our schedule of debugging and file system seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>> http://www.osr.com/careers For our schedule of debugging and file system
>> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
>> List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
Hi Paul,
Hmm so in your case it looks like something is waiting for the RundownRef
to be released, where for Passthrough there is no waiter yet (at least,
based on how I recall the RundownRef works). That could simply be because
you’re stopped in a different place in the code (since in your case you’re
not in the same place as the breakpoint you added for PassThrough). You
could do a !search for the FLT_FILTER address (fffffa8002f8b750, which is
the same as the FLT_OBJECT address) and see if you can tell what all the
allocations are for… Still, this isn’t usually an effective technique for
investigating refcount leaks… Alternatively, you could try to remove all
calls for the FltObjectReference/FltObjectDereference pair for your
FLT_FILTER object and see if that changes anything…
Sorry I can’t offer more help…
Alex.
On Mon, Sep 8, 2014 at 11:53 AM, Paul wrote:
> Here’s the printout for passthrough. PointerCount is 0x2 like mine.
> However, RundownRef values are very different (value vs pointer to
> something). And if you notice on the printout I posted earlier, there’s an
> error right under the RundownRef value (“Could not read field “Count” of
> nt!_EX_RUNDOWN_WAIT_BLOCK from address: fffff88002f5f960”).
>
> Alex, I’ve read your write up on RundownRef. Do you have any more insight
> into this? Thanks.
>
> Filter List: fffffa80027cf0c0 “Frame 0”
> FLT_FILTER: fffffa8004272850 “PassThrough” “370030”
> FLT_OBJECT: fffffa8004272850 [02000000] Filter
> RundownRef : 0x000000000000000a (5)
> PointerCount : 0x00000002
> PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
>
> On Mon, Sep 8, 2014 at 12:52 PM, Paul wrote:
>
>> Sorry. Win7 x64 running in a VM.
>>
>> Thanks Alex. I’ve read your various postings (
>> http://fsfilters.blogspot.com/2011/12/debugging-minifilters-using-fltkdfilter.html
>> ,
>> http://fsfilters.blogspot.com/2011/02/tracking-minifilters-activeopens-files.html)
>> on this issue but no luck. I’ll try with passthrough and compare.
>>
>>
>> On Mon, Sep 8, 2014 at 12:09 PM, Alex Carp
>> wrote:
>>
>>> I can’t tell what’s wrong at a first glance. Is it possible there’s a
>>> reference count leak count ? Like, the PointerCount on the FLT_OBJECT is
>>> 0x00000002 (it may be right, I don’t remember exactly how that works )…
>>> Try to load passthrough, put a breakpoint on unload and compare the
>>> reference counts.
>>>
>>> Alex.
>>>
>>>
>>> On Mon, Sep 8, 2014 at 8:08 AM, wrote:
>>>
>>>> I’m having a heck of a time trying to find a leaked reference that is
>>>> preventing my filter from unloading. It’s hanging at FltUnregisterFilter.
>>>> Just to clear the common suggestions, I don’t have any outstanding pool
>>>> allocations or any ActiveOpens (WinDbg printouts below). I also removed
>>>> all of my communications code to help find the leak but still no dice.
>>>>
>>>> I thought I narrowed it down to a file reference that wasn’t being
>>>> closed, but I added a linked list of currently opened files and then looped
>>>> through to close any open ones during the Instance Cleanup routine. I’m
>>>> kind of running out of ideas on where it may be but more importantly how to
>>>> find it. Any suggestions would be appreciated. Thanks.
>>>>
>>>>
>>>> kd> !verifier 3
>>>>
>>>> Verify Level 809 … enabled options are:
>>>> Special pool
>>>> All pool allocations checked on unload
>>>> Miscellaneous checks enabled
>>>>
>>>> Summary of All Verifier Statistics
>>>>
>>>> RaiseIrqls 0x0
>>>> AcquireSpinLocks 0x0
>>>> Synch Executions 0x0
>>>> Trims 0x0
>>>>
>>>> Pool Allocations Attempted 0x4a8
>>>> Pool Allocations Succeeded 0x4a8
>>>> Pool Allocations Succeeded SpecialPool 0x4a8
>>>> Pool Allocations With NO TAG 0x0
>>>> Pool Allocations Failed 0x0
>>>> Resource Allocations Failed Deliberately 0x0
>>>>
>>>> Current paged pool allocations 0x0 for 00000000 bytes
>>>> Peak paged pool allocations 0x0 for 00000000 bytes
>>>> Current nonpaged pool allocations 0x0 for 00000000 bytes
>>>> Peak nonpaged pool allocations 0x27 for 00005B44 bytes
>>>>
>>>> kd> !fltkd.filters DRIVER
>>>> Filter List: fffffa80027cf0c0 “Frame 0”
>>>> FLT_FILTER: fffffa8002f8b750 “DRIVER” “140001”
>>>> FLT_OBJECT: fffffa8002f8b750 [02000001] Filter DRAINING
>>>> RundownRef : 0xfffff88002f5f961
>>>> Could not read field “Count” of nt!_EX_RUNDOWN_WAIT_BLOCK from address:
>>>> fffff88002f5f960
>>>> PointerCount : 0x00000002
>>>> PrimaryLink : [fffffa8004054750-fffffa80027cf0c0]
>>>> Frame : fffffa80027cf010 “Frame 0”
>>>> Flags : [00000006] FilteringInitiated
>>>> NameProvider
>>>> DriverObject : fffffa80042f5e70
>>>> FilterLink : [fffffa8004054750-fffffa80027cf0c0]
>>>> PreVolumeMount : fffff8800338abc0 DRIVER!PrePassThrough
>>>> PostVolumeMount : 0000000000000000 (null)
>>>> FilterUnload : fffff88003395010 DRIVER!FilterUnload
>>>> InstanceSetup : fffff88003395110 DRIVER!Setup
>>>> InstanceQueryTeardown : fffff880033965b0 DRIVER!QueryTeardown
>>>> InstanceTeardownStart : fffff880033749b0
>>>> DRIVER!InstanceTeardownStart
>>>> InstanceTeardownComplete : fffff88003374ac0
>>>> DRIVER!InstanceTeardownComplete
>>>> ActiveOpens : (fffffa8002f8b8e8) mCount=0
>>>> Communication Port List : (fffffa8002f8b938) mCount=0
>>>> Client Port List : (fffffa8002f8b988) mCount=0
>>>> VerifierExtension : 0000000000000000
>>>> Operations : fffffa8002f8b9e0
>>>> OldDriverUnload : 0000000000000000 (null)
>>>> Could not read field “AllocationType” of
>>>> FltMgr!_ALLOCATE_CONTEXT_HEADER from address: 202444c74838ec83
>>>> Could not read field “Next” of FltMgr!_ALLOCATE_CONTEXT_HEADER from
>>>> address: 0000000000000000
>>>> —
>>>>
>>>>
>>>> —
>>>> NTFSD is sponsored by OSR
>>>>
>>>> OSR is hiring!! Info at http://www.osr.com/careers
>>>>
>>>> For our schedule of debugging and file system seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>>> http://www.osr.com/careers For our schedule of debugging and file
>>> system seminars visit: http://www.osr.com/seminars To unsubscribe,
>>> visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file system
> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>