Is there any way aside from tracking pool tags to figure which items
are leaking during filter unload?
I have a branded version of the main driver which for some reason
won’t unload, but I can’t figure what is leaking from the pool tags.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Installing the Checked-build Filter Manager driver may be helpful.
Also turn on the driver verifier for your filter may also be helpful.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> Is there any way aside from tracking pool tags to figure which items
> are leaking during filter unload?
> I have a branded version of the main driver which for some reason
> won’t unload, but I can’t figure what is leaking from the pool tags.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
Driver Verifier doesn’t help here, FltMgr waits on the filter to release all the allocations (not just memory
but other Flt references) before allowing the unload.
I don’t think the checked FltMgr would help either unless it says “waiting for driver to release xxx before
proceeding with unload”?
Shangwu wrote:
Installing the Checked-build Filter Manager driver may be helpful.
Also turn on the driver verifier for your filter may also be helpful.“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
> >
> > Is there any way aside from tracking pool tags to figure which items
> > are leaking during filter unload?
> > I have a branded version of the main driver which for some reason
> > won’t unload, but I can’t figure what is leaking from the pool tags.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
Checked FltMgr has a lot of assertions in its code. It helped me fixed some
issues on unloading.
“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> Driver Verifier doesn’t help here, FltMgr waits on the filter to
> release all the allocations (not just memory
> but other Flt references) before allowing the unload.
> I don’t think the checked FltMgr would help either unless it says
> “waiting for driver to release xxx before
> proceeding with unload”?
>
> Shangwu wrote:
>
>> Installing the Checked-build Filter Manager driver may be helpful.
>> Also turn on the driver verifier for your filter may also be helpful.
>>
>> “Dejan Maksimovic” wrote in message
>> news:xxxxx@ntfsd…
>> >
>> > Is there any way aside from tracking pool tags to figure which items
>> > are leaking during filter unload?
>> > I have a branded version of the main driver which for some reason
>> > won’t unload, but I can’t figure what is leaking from the pool tags.
>
> –
> Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
> http://www.alfasp.com
> File system audit, security and encryption kits.
>
>
>
Of course, I strongly urge everyone to use a checked filter manager in development. We’ve also added a lot more asserts and verifier checks in the Win7 one, so once you have access to it testing on a win7 machine with checked filter manager and driver verifier might uncover problems that the older versions didn’t find.
Other than that there are also some !fltkd commands that display reference count information and contexts and such. We use them internally to figure out unloading problems.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
In Vista or beyond, fltmgr verifier will track objects referenced by the
minifilter and complain if you leak them on unload. Enabling IO
Verification in Driver Verifier will enable fltmgr verifier on your driver.
“!filter 8 0” will give you this usage information at
any time.
kd> !filter 95cc2a68 8 0
FLT_FILTER: 95cc2a68 “luafv” “135000”
InstanceList : (95cc2a98)
FLT_INSTANCE: 94b56a20 “luafv” “135000”
Object usage/reference information:
References to FLT_CONTEXT : 0
Allocations of FLT_CALLBACK_DATA : 1
Allocations of FLT_DEFERRED_IO_WORKITEM : 0
Allocations of FLT_GENERIC_WORKITEM : 0
References to FLT_FILE_NAME_INFORMATION : 0
Open files : 1
References to FLT_OBJECT : 0
“!filter 8 1” will give you more details on the objects
in use.
kd> !filter 95cc2a68 8 1
…
List of objects used/referenced::
FLT_VERIFIER_OBJECT: 8cf32fd8
Object: 89f9e8e0 Type: FILE_OBJECT RefCount: 00000001
FLT_VERIFIER_OBJECT: 97dcafd8
Object: 97dfce40 Type: FLT_CALLBACK_DATA RefCount: 00000001
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
Alexandru Carp wrote:
> Of course, I strongly urge everyone to use a checked filter manager in development. We’ve also added a lot more asserts and verifier checks in the Win7 one, so once you have access to it testing on a win7 machine with checked filter manager and driver verifier might uncover problems that the older versions didn’t find.
>
> Other than that there are also some !fltkd commands that display reference count information and contexts and such. We use them internally to figure out unloading problems.
>
> Regards,
> Alex.
> This posting is provided “AS IS” with no warranties, and confers no rights.
>
>