Question about the life of a stream handle context

NTFSD
1

I have a minifilter which attaches a stream handle context in
post-create and then deletes said stream handle context in either pre-
or post-cleanup. When I set the stream handle context in the
post-create, I am specifing FLT_SET_CONTEXT_KEEP_IF_EXISTS and once in
awhile FltSetStreamHandleContext() is returning
STATUS_FLT_CONTEXT_ALREADY_DEFINED. Everytime I see this status, the
file object happens to be a directory. I wasn’t expecting to see a
stream handle context attached at this point in time; is there a reason
why a stream handle context would (still) be attached to a file object
at this point?

thanks

2

Since the ctx sample uses FLT_SET_CONTEXT_REPLACE_IF_EXISTS for stream
handle contexts on PostCreate, I guess it’s normal that there may be an
attached stream handle context at this point…even if you really *delete*
the context on cleanup. Or did you re-assure in your ContextFreeCallback
that the context has been deleted immediately?

Regards
Frank

“Vossen, Joseph (ISS Atlanta)” wrote
>news:xxxxx@ntfsd…
>I have a minifilter which attaches a stream handle context in
>post-create and then deletes said stream handle context in either pre-
>or post-cleanup. When I set the stream handle context in the
>post-create, I am specifing FLT_SET_CONTEXT_KEEP_IF_EXISTS and once in
>awhile FltSetStreamHandleContext() is returning
>STATUS_FLT_CONTEXT_ALREADY_DEFINED. Everytime I see this status, the
>file object happens to be a directory. I wasn’t expecting to see a
>stream handle context attached at this point in time; is there a reason
>why a stream handle context would (still) be attached to a file object
>at this point?
>
>thanks

3

FltDeleteStreamHandleContext() is invoked to remove the context during
the cleanup callback, but I ignore the return value. I also specify
NULL for the old context since I really don’t need to ‘see’ it at that
point; I let my context callback routine deal with cleaning it up (all
code paths that use FltGetStreamHandleContext() are matched up with a
call to FltReleaseContext() so there shouldn’t be any lingering
references, but I’ll double check that)

Thanks

Since the ctx sample uses FLT_SET_CONTEXT_REPLACE_IF_EXISTS for stream

handle contexts on PostCreate, I guess it’s normal that there may be
an
attached stream handle context at this point…even if you really
*delete*
the context on cleanup. Or did you re-assure in your
ContextFreeCallback
that the context has been deleted immediately?

Regards
Frank

>I have a minifilter which attaches a stream handle context in
>post-create and then deletes said stream handle context in either
pre-
>or post-cleanup. When I set the stream handle context in the
>post-create, I am specifing FLT_SET_CONTEXT_KEEP_IF_EXISTS and once
in
>awhile FltSetStreamHandleContext() is returning
>STATUS_FLT_CONTEXT_ALREADY_DEFINED. Everytime I see this status, the
>file object happens to be a directory. I wasn’t expecting to see a
>stream handle context attached at this point in time; is there a
reason
>why a stream handle context would (still) be attached to a file
object
>at this point?
>
>thanks