Filter Manager and Contexts

NTFSD
1

Hi.

I do have question concerning contexts. My MiniFilter uses Stream- and
StreamHandle-contexts. Is it safe to have an unreferenced pointer to a
Stream-context in my StreamHandle-context structure? Or with other words: is
a Stream-context guaranteed to stay as long as at least one
StreamHandle-context exists?

Thanks
Frank

2

I would guess so. But why keep it unreferenced ?
The stream context exists as long as the SCB is still available ( I would guess) so by implication it means the stream-handle must exist.
I don’t know for sure the deeper implementation of the contexts ( by the filter manager) but I would guess that keeping it referenced would be a better idea)

3

wrote news:xxxxx@ntfsd…
> … But why keep it unreferenced ?

FilterDriverDeveloperGuide says: “It is advised that a minifilter not hold
on to contexts across operations”. So I decided to keep the pointer weak.

4

Hi Frank,

I’m afraid the StreamContext is not guaranteed to stick around as long as
there is a StreamHandleContext. Their life spans are unrelated. It might
usually look like the StreamContext is guaranteed to be there, but there are
cases where it goes away and your pointer will be invalid (if the filter
calls FltDeleteContext for example or even
FltSetStreamContext(…,FLT_SET_CONTEXT_REPLACE_IF_EXISTS,…)).

“The stream context exists as long as the SCB is still available” -> this is
not entirely correct. In other words it’s true that once the SCB is
destroyed the context is destroyed as well, but it does not imply that
whenever an SCB is valid there must be a valid StreamContext associated with
it or that there can only be one StreamContext associated with the SCB for
the duration of its lifetime. The guarantee is that there is only at most
one StreamContext per SCB per filter at any given time.

Your quote from the FilterDriverDeveloperGuide is incomplete. This is the
full quote:
" It is advised that a minifilter not hold on to contexts across operations.
Context tracking is very efficient and it is intended that a minifilter
query for desired contexts on each operation. "

So the point the document is trying to make is that you should call
FltGetStreamContext() every time you need it instead of stashing a pointer
to it. This is also because even if you keep a referenced pointer to the
StreamContext in your StreamHandleContext it might still become invalid if
someone deletes or replaces the pointer (even though it won’t be freed so
you won’t necessarily be touching freed memory).

I have a post on how filter manager contexts work on my blog here, it might
help explain the reference model and how a context is associated with the
underlying structure…
http://fsfilters.blogspot.com/2010/02/context-usage-in-minifilters.html.

Thanks,
Alex.

5

Thanks for the info. I will drop the idea of context pointer and query instead. Hoping that this is not a performance degrade in read/write path.

Thanks again
Frank