If you are getting calls after close, there is something interfering
with normal dereference operation. This can happen (for example) with
interactions between file system filter drivers. I also had a case
where someone (above the FSD) was receiving the IRP_MJ_CLEANUP and then
bumping and dropping the reference count - the drop triggered a call to
IRP_MJ_CLOSE before the IRP_MJ_CLEANUP was called.
While the latter case is not terribly likely, you can test for it - in
your IRP_MJ_CLEANUP handler make sure that you set FO_CLEANUP_COMPLETE.
Then in IRP_MJ_CLOSE you can test that this bit is set (if it isn’t you
have an out-of-order close.)
Another case I’ve seen (now that I’m thinking about it) is that if you
are calling CcPurgeCache this can cause the IRP_MJ_CLOSE to arrive
before you have completed the IRP_MJ_CLEANUP processing. But this
probably doesn’t match very well either (although note that the purge
may trigger a CLOSE operation on a different file object than the
CLEANUP on which you are currently operating.)
What you have is most likely a reference count bug - you think the
reference on your FCB is zero when in fact it is not. Were I debugging
this problem I’d be looking at the file object the cache manager is
passing in to you - and then walking back through your logs (you ARE
using WPP tracing, so you can easily look at this information, right?)
and find where you think this file object went away - because it didn’t.
Also, another suggestion: defer calling CcInitializeCacheMap until the
first read. While not *required* for correct behavior, many open calls
never do I/O to the file, and setting up and tearing down the cache map
is a relatively expensive operation, particularly when you aren’t going
to use it (not necessary, but merely an observation on efficient
implementation tricks.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roger Tawa
Sent: Wednesday, January 18, 2006 9:00 PM
To: ntfsd redirect
Subject: Re: [ntfsd] CcInitializeCacheMap and PinAccess argument
Hi Tony,
Where do you call CcUninitalizeCacheMap?
First, I call CcInitializeCacheMap() when handling CREATE. I call it
only when FO_NO_INTERMEDIATE_BUFFERING is not specified.
I call CcUninitializeCacheMap(fileobj,0,0) in CLEANUP. I call it
unconditionally for all file objects, whether I called
CcInitializeCacheMap() or not. Additionally in CLEANUP, if this is
the last file object for this FCB, and the FCB is marked for
delete-on-close, I call CcPurgeCacheSection(sop,0,0,TRUE) *before*
calling CcUninitializeCacheMap().
Finally, in CLOSE, if this is the last file object for this FCB, I
free the memory allocated for the FCB. I also set the FsContext field
in the file object to null.
=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com