I think you’re wrong here. Contexts returned from FltAllocateContext
should have a reference count of 1. This allows you to delete the context
with FltReleaseContext if, for example, you have a failure initialializing
the context, or you use FltSetXXXContext with
FLT_SET_CONTEXT_KEEP_IF_EXISTS and the context already exists.
In the 3790.1812 documentation of FltAllocateContext, I can not find a
statement to the effect that the Filter Manager’s portion ot the context is
uninitialized. It says:
“FltAllocateContext does not initialize the contents of the mini-filter
specific portion of the context structure.”
That refers to your portion of the context.
You should look at the ctx minifilter sample for examples of how to handle
contexts.
Maybe trying to make sense of these docs is a silly exercise in
general.
IMNSHO, the docs could use some work in their descriptions of reference
counting. I would like to see it explicitly stated that FltAllocateContext
initializes the refcount to 1, and explicit indications for other routines
indicating under what conditions they increment a reference count.
The reference counting works properly and reasonably, but the docs describe
it badly. I look forward to someday seeing the doc section IFS Kit
Documentation->Design Guide->File System Minifilter Drivers->Using Contexts.
The logical place for me to put the matching release for the allocation call
is in context-cleanup, but doing a FltReleaseContext in context-cleanup
This is not right. The context cleanup routine is called when the context
reference count goes to zero. Calling FltReleaseContext in context cleanup
would likely have no effect. You should release the context when you are
done with it.
However, while I have not verified it, I also strongly suspect that
contexts are explicitly deleted by Filter Manager when their associated
objects go away. As was discussed in another thread on this list, without
implementing some reference counting of your own, there is no good way to
know whether the close of a stream handle is the last close for that
stream, so you don’t know whether you’re done with the stream context.
Perhaps Neal or Molly would be kind enough to shed more light.
At 08:05 PM 3/24/2005 -0800, you wrote:
That seems like a contradiction but I’ll try it. How could you pass an
uninitialized structure you got from allocate to FltReleaseContext? Maybe
it is initialized to a value of two in SetContext. Or maybe the docs are
just wrong about it not being initialized for the filter manager when
allocated. Maybe trying to make sense of these docs is a silly exercise in
general.
The logical place for me to put the matching release for the allocation call
is in context-cleanup, but doing a FltReleaseContext in context-cleanup
seems silly since it’s about to go away anyway. I wonder if the call to
context cleanup is delayed until there are no more outstanding accesses. If
so then I’ve got a big catch-22 on my hands. I’ll put a FltReleaseContext
in context-cleanup and give it a try.
The whole idea of having reference counts for context structures seems quite
redundant to me since they are obviously not needed after the object they
are linked to goes away. They make no sense for avoiding leaks since they
won’t leak if they are linked to an object that doesn’t leak.
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> > Nope. Look at the description of ReturnedContext for FltAllocateContext:
> >
> > “The caller is responsible for calling FltReleaseContext to release this
> > context when it is no longer needed.”
> >
> > Ken
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> > Sent: Thursday, March 24, 2005 6:26 PM
> > To: Windows File Systems Devs Interest List
> > Subject: Re:[ntfsd] sc stop is hanging
> >
> > I don’t think FltAllocateContext needs a matching context release because
> > the docs say that the context it returns is not initialized, not even the
> > filter manager part. You must have been thinking of FltSetXXXContext
> > which
> > does the init and needs a matching release.
> >
> > So unless I’m mistaken we can say that only the “sets” and “gets” need
> > matching releases.
> >
> > “Ken Cross” wrote in message news:xxxxx@ntfsd…
> >> Mark:
> >>
> >> This is most likely a reference that hasn’t been de-referenced somewhere.
> >> I
> >> know of no automated way to find them – you have to track every
> >> reference
> >> to make sure they’re de-referenced.
> >>
> >> In addition to the obvious FltGetxxxContext and FltSetxxxContext
> >> routines,
> >> there are a number of routines that cause a reference that you could
> >> miss,
> >> such as:
> >>
> >> FltAllocateContext
> >> FltGetFileNameInformation
> >> FltGetDestinationFileNameInformation
> >> FltGetDiskDeviceObject
> >> FltGetDeviceObject
> >>
> >> You can try ObGetObjectPointerCount() to get the reference count on
> >> objects.
> >> Otherwise, it’s pretty manual.
> >>
> >> Good luck,
> >> Ken
> >>
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> >> Sent: Thursday, March 24, 2005 3:03 PM
> >> To: Windows File Systems Devs Interest List
> >> Subject: [ntfsd] sc stop is hanging
> >>
> >> When my mini-filter is loaded, I can do “sc query myfilter” with no
> >> problem.
> >>
> >> If I do “sc stop myfilter” it calls my filter’s unload routine, I free
> >> all
> >> my resources (at least I think I do), I return a success status, but the
> >> sc
> >> program never finishes. It just sits there until I hit CTRL-C. After
> >> that
> >> every sc command to my filter, including queries, hangs the same way.
> >>
> >> Does anyone have any idea what I could be doing wrong to make this
> >> happen?
> >> Is leaving some object referenced (object leak) a possible cause?
> >>
> >> Is there some way to use Windbg to trace down what’s happening? Any
> >> suggestions on chasing this would be appreciated.
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@comcast.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@privtek.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
