Greetings,
[I’m sorry if this was answered already but I couldn’t find any related post in the archives/Faq]
config: w2k/sp4/Fat compiled in checked mode from Ifs
kit 2003+ my filter, no other filters.
Pb:
0) a file is created with word (my filter use
internally IoCreateStreamFO() in the create path to
open the file with a private File Object)
-
At the last Cleanup on this private file object we
purge the cache+MmSections, the Fat fsd below mark the
fcb for delay_close state (Fcb reference Opencount of -
At close time the dispatch function in Fat, queues
the close call in a worker thread (fcb state is
delay_close) but the Fat fcb Opencount is still 1
(!?).
My assumption is that Mm/Cc layers would not want to
reference the file anymore because all data has been
flushed previously (I wait the event in Ccuninit())
and they are no memory map
(Fcb->SectionObject/privatemap all nuls)
- A create on the same file happens before the
‘queued’ close triggers - no other access to the file
before this - and fat recycle the same fcb data
structure (FatFindFcb+FatOpenExistingFcb), clear the
fcb delay_close flag *but* increment the Fcb’s ref
Opencount (now 2 !) - fat doesnt’ dequeue the close
worker thread job either ?
So later the fcb is never freed (Opencount never
reaches 0) and we experience either sharing_violation
or delete_pendings on next creates for the file.
Manually fixing the count with debugger seems to fix
the pb, no crash so far.
Also thread serialization seems proper, the open is
waiting for the close to release the volume before
proceeding, and reference counts for file objects are
ok.
Does this description make sense ? Can anyone confirms
this is a fat pb ? any workaround, fix ?
It there a way to avoid the fcb delay_close state ?
Thanks in advance for your time. [sorry for the long
post]
Jerome/
Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/