Hi All,
I have this mini filter driver that monitors files coming to a volume. I’m using file stream context to pass some data from post create to Pre cleanup IRP. But I think I’m having a memory leak somewhere because when I unload the mini filter driver, I can see that bunch of file stream contexts gets released. The more file I have ingested to the volume, the more contexts get released after driver unload.
Basically this is what I’m doing:
In the Post create IRP:
status = FltAllocateContext( FileMonData.Filter,
FLT_STREAM_CONTEXT,
sizeof(FILEMON_STREAM_CONTEXT),
PagedPool,
&streamContext );
if (NT_SUCCESS( status ))
{
< do some stuff>
status = FltSetStreamContext( FltObjects->Instance,
FltObjects->FileObject,
FLT_SET_CONTEXT_KEEP_IF_EXISTS,
pFileMonContext,
&pFileMonOldContext );
if(pFileMonOldContext)
{
< do some stuff>
FltReleaseContext( pFileMonOldContext );
}
FltReleaseContext( pFileMonContext );
}
In the Pre Cleanup IRP:
status = FltGetStreamContext( FltObjects->Instance,
FltObjects->FileObject,
&pFileMonContext);
if (NT_SUCCESS( status ) )
{
FltReleaseContext( pFileMonContext ); }
What is that I’m doing wrong here? Thanks for your help. Payman
Just some hints: if the driver unloads cleanly (without crash / hang even with Driver Verifier), then it is perfectly normal to see a lot of context cleanup callbacks on unload.
Also, you might check for STATUS_FLT_CONTEXT_ALREADY_DEFINED status from FltSetStreamContext.
Sandor is absolutely correct in his statements. A minifilter will not
unload if you are leaking a stream context.
Fltmc Unload will hang and you’ll have to Ctrl-C out of it.
I conducted an experiment once where I allocated a context and then intentionally used FltReferenceContext without calling* *FltReleaseContext to see what would happen when unloading the driver. Since the object’s reference count was increased with the reference call, the context was never destroyed before the attempted unload and I saw the above behavior.
Matt
slukacs@.com wrote:
>Just some hints: if the driver unloads cleanly (without crash / hang even with Driver Verifier), then it is perfectly normal to see a lot of context cleanup callbacks on unload. > >
In post create you attach the context. In PreCleanup you do nothing. When
the detach comes in filter manager detaches all the contexts that you had
attached to streams which are still cached or otherwise open. Because you
are not referencing them the contexts then get deleted.
Think of it as reference counting. FltRelease downs the count by one,
FltAllocate and FltGet up the count. When you set the context the context
is reference again to indicate that it is attached to the Stream. When the
detach comes in the contexts get detached, dereferenced and because the
count is zero they go away.
wrote in message news:xxxxx@ntfsd… > Hi All, > I have this mini filter driver that monitors files coming to a volume. I’m > using file stream context to pass some data from post create to Pre > cleanup IRP. But I think I’m having a memory leak somewhere because when I > unload the mini filter driver, I can see that bunch of file stream > contexts gets released. The more file I have ingested to the volume, the > more contexts get released after driver unload. > Basically this is what I’m doing: > > 1) In the Post create IRP: > status = FltAllocateContext( FileMonData.Filter, > FLT_STREAM_CONTEXT, > sizeof(FILEMON_STREAM_CONTEXT), > PagedPool, > &streamContext ); > > if (NT_SUCCESS( status )) > { > < do some stuff> > status = FltSetStreamContext( FltObjects->Instance, > FltObjects->FileObject, > FLT_SET_CONTEXT_KEEP_IF_EXISTS, > pFileMonContext, > &pFileMonOldContext ); > if(pFileMonOldContext) > { > < do some stuff> > FltReleaseContext( pFileMonOldContext ); > } > > FltReleaseContext( pFileMonContext ); > } > > > 2) In the Pre Cleanup IRP: > status = FltGetStreamContext( FltObjects->Instance, > FltObjects->FileObject, > &pFileMonContext); > > if (NT_SUCCESS( status ) ) > { > > FltReleaseContext( pFileMonContext ); > } > > What is that I’m doing wrong here? > Thanks for your help. > Payman > > > >
I have a mini-filter and I see the same behaviour. If you leave it
running for a while then you will see context clean up for the stream
contexts are getting called without unloading the filter. May be the
FltMgr implements some delayed close/cleanup mechanism for the
file/stream contexts.
If you have an outstanding reference for stream context the
mini-filter refuses to unload.
Bala
On 11/13/07, xxxxx@hotmail.com wrote: > Hi All, > I have this mini filter driver that monitors files coming to a volume. I’m using file stream context to pass some data from post create to Pre cleanup IRP. But I think I’m having a memory leak somewhere because when I unload the mini filter driver, I can see that bunch of file stream contexts gets released. The more file I have ingested to the volume, the more contexts get released after driver unload. > Basically this is what I’m doing: > > 1) In the Post create IRP: > status = FltAllocateContext( FileMonData.Filter, > FLT_STREAM_CONTEXT, > sizeof(FILEMON_STREAM_CONTEXT), > PagedPool, > &streamContext ); > > if (NT_SUCCESS( status )) > { > < do some stuff> > status = FltSetStreamContext( FltObjects->Instance, > FltObjects->FileObject, > FLT_SET_CONTEXT_KEEP_IF_EXISTS, > pFileMonContext, > &pFileMonOldContext ); > if(pFileMonOldContext) > { > < do some stuff> > FltReleaseContext( pFileMonOldContext ); > } > > FltReleaseContext( pFileMonContext ); > } > > > 2) In the Pre Cleanup IRP: > status = FltGetStreamContext( FltObjects->Instance, > FltObjects->FileObject, > &pFileMonContext); > > if (NT_SUCCESS( status ) ) > { > > FltReleaseContext( pFileMonContext ); > } > > What is that I’m doing wrong here? > Thanks for your help. > Payman > > > > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
>May be the FltMgr implements some delayed close/cleanup mechanism for the file/stream contexts.
I think, that actually the FSDs are which keep the underlying FCBs and stream contexts alive for a while, after you close the last handle of a file. Also, AFAIK, there is no known mechanism to influence or determine the number or lifetime (after close) of them. In practice, I observed that NTFS for example keeps a lot of contexts (few thousands sometimes) alive, then, at some point (maybe after some time, maybe at high load, I don’t really know) it just releases some of them (sometimes a lot of them at once).
I believe Rod is right on the money. Don’t confuse your reference count
on the stream context with the reference count maintained by the filter
manager. I believe that normally, these will be released by the filter
manager in the IRP_MJ_CLOSE path (after your pre-close callback). When
you unload your filter, the filter manager has to dereference and
hopefully tear down all the contexts it holds reference counts for. You
would be in trouble if you are NOT seeing all these contexts getting
cleaned up at unload time. That would be more indicative of a reference
count leak on your part.
Rod Widdowson wrote:
I don’t see any problem here:
In post create you attach the context. In PreCleanup you do nothing. When
the detach comes in filter manager detaches all the contexts that you had
attached to streams which are still cached or otherwise open. Because you
are not referencing them the contexts then get deleted.
Think of it as reference counting. FltRelease downs the count by one,
FltAllocate and FltGet up the count. When you set the context the context
is reference again to indicate that it is attached to the Stream. When the
detach comes in the contexts get detached, dereferenced and because the
count is zero they go away.
wrote in message news:xxxxx@ntfsd… > >> Hi All, >> I have this mini filter driver that monitors files coming to a volume. I’m >> using file stream context to pass some data from post create to Pre >> cleanup IRP. But I think I’m having a memory leak somewhere because when I >> unload the mini filter driver, I can see that bunch of file stream >> contexts gets released. The more file I have ingested to the volume, the >> more contexts get released after driver unload. >> Basically this is what I’m doing: >> >> 1) In the Post create IRP: >> status = FltAllocateContext( FileMonData.Filter, >> FLT_STREAM_CONTEXT, >> sizeof(FILEMON_STREAM_CONTEXT), >> PagedPool, >> &streamContext ); >> >> if (NT_SUCCESS( status )) >> { >> < do some stuff> >> status = FltSetStreamContext( FltObjects->Instance, >> FltObjects->FileObject, >> FLT_SET_CONTEXT_KEEP_IF_EXISTS, >> pFileMonContext, >> &pFileMonOldContext ); >> if(pFileMonOldContext) >> { >> < do some stuff> >> FltReleaseContext( pFileMonOldContext ); >> } >> >> FltReleaseContext( pFileMonContext ); >> } >> >> >> 2) In the Pre Cleanup IRP: >> status = FltGetStreamContext( FltObjects->Instance, >> FltObjects->FileObject, >> &pFileMonContext); >> >> if (NT_SUCCESS( status ) ) >> { >> >> FltReleaseContext( pFileMonContext ); >> } >> >> What is that I’m doing wrong here? >> Thanks for your help. >> Payman >> >> >> >> >> > > > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@vipmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
Thanks tor your input.
I have ran my mini filter driver with driver verifier and it did not catch any memory leak and base on your comments it seems that it is normal that filter manager queues these contexts and release ithem after driver gets unload.
One question that I have is, let’s say I’m ingesting bunch of files to th volume, and filter manager queues all these file stream context. Wouldn’t this eating up my memory and causes memory leak?
Or does filter manager eventually releases these contexts without mini filter driver being unloaded?