Memory leak with mini driver

NTFSD
1

I just inherited this mini filter driver with a memory leak bug (but not in it’s own pools). When the driver is active, I’m getting a lot of memory being consumed in the following pool:
FMfn - fltmgr.sys - NAME_CACHE_NODE structure
which I assume is the Name Cache of the filter manager.

Can anyone give me some quick ideas to look for (ie what is the driver doing/not doing to cause the filter manager to keep consuming memory from this pool). With the driver enabled, the pool keeps going up via poolmon.

BTW this filter keeps track of what files have been modified, created, renamed etc.

Thanks,

Bernie

2

This is a guess as I am not sure that this is the tag the fltmgr is using for the file name information structure but maybe you are not calling FltReleaseFileNameInformation after retrieving the name of a file with FileGetFileNameInformation?

Thanks,
G.

3

Have you enabled the target for debug and done any investigation? Looked for
memory allocations without a balancing free? A ONCE IN NEVER OUT (ONO??)
queue? Stuck IRP?

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, May 22, 2011 8:27 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Memory leak with mini driver

I just inherited this mini filter driver with a memory leak bug (but not in
it’s own pools). When the driver is active, I’m getting a lot of memory
being consumed in the following pool:
FMfn - fltmgr.sys - NAME_CACHE_NODE structure
which I assume is the Name Cache of the filter manager.

Can anyone give me some quick ideas to look for (ie what is the driver
doing/not doing to cause the filter manager to keep consuming memory from
this pool). With the driver enabled, the pool keeps going up via poolmon.

BTW this filter keeps track of what files have been modified, created,
renamed etc.

Thanks,

Bernie

NTFSD is sponsored by OSR

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

__________ Information from ESET Smart Security, version of virus signature
database 6143 (20110522) __________

The message was checked by ESET Smart Security.

http://www.eset.com

4

If your filter is supposed to be unloadable your absolute best bet is to run
it verified under Win7 and try to unload it. If it doesn’t unload it will
break in the debugger and give you instructions on tracing what’s leaked.
If it does unload then there is a very good chance that it isn’t leaking
memory but that the memory is just be kept around because there is no
pressure to drop it.

Actually even if it isn’t unloadable run it under verifier in Win7 and then
when you think you have problems break in the debugger and issue a

!Fltkd.filter 8 7

(get the address from! fltkd.filters).

R

wrote in message news:xxxxx@ntfsd…

I just inherited this mini filter driver with a memory leak bug (but not in
it’s own pools). When the driver is active, I’m getting a lot of memory
being consumed in the following pool:
FMfn - fltmgr.sys - NAME_CACHE_NODE structure
which I assume is the Name Cache of the filter manager.

Can anyone give me some quick ideas to look for (ie what is the driver
doing/not doing to cause the filter manager to keep consuming memory from
this pool). With the driver enabled, the pool keeps going up via poolmon.

BTW this filter keeps track of what files have been modified, created,
renamed etc.

Thanks,

Bernie

5

The FMfn tag is indeed for a NAME_CACHE_NODE which is allocated for filter manager’s name cache.

There are two ways I can think of where a minifilter could be directly responsible for a leak:

  1. As already mentioned the minifilter is leaking FLT_FILE_NAME_INFORMATION structure references. If this is the case verifier will let you know when the filter unloads.
  2. The filter is leaking references on files which prevents the fileobjects or streams from being torn down when no longer needed.

Otherwise it is probably not a leak. When you call FltGetFileNameInformation with a flag that allows caching filter manager keeps a reference to the name for its name cache. The name reference will be released and the pool freed automatically when the stream or fileobject is torn down.

Scott Brender
Microsoft File System Filter Team