Does a minifilter context pointer outlive its context?

NTFSD
1

Hi,

I’m experimenting with minifilter contexts by changing a bunch of code in the minispy example minifilter, and I don’t understand the lifetime of a StreamHandle context pointer.

In my pre-CREATE callback, I call FltAllocateContext() to allocate a STREAMHANDLE context. In the post-CREATE callback, I call FtlSetStreamHandleContext() [and then FltReleaseContext()] to attach the context to the opened file stream.

In subsequent “pre-” callback operations (e.g. READs, WRITEs, CLEANUPs, and CLOSEs), I call FltGetStreamHandleContext() to try to obtain the associated stream handle. If I can get the STREAMHANDLE context, then I call FltReleaseContext() to release it.

I also have a context cleanup handler that logs when it has been called to cleanup the given context.

Given all this, when I copy a tiny file from drive E: to F:, the sequence of callbacks that I see for the particular file is as follows (ignoring the FastIO queries and stuff)…

  1. pre-CREATE (open the file, allocate StreamHandle context)
  2. post-CREATE (attach the StreamHandle context)
  3. pre-CLEANUP (successfully get the StreamHandle context)
  4. pre-CLOSE (successfully get the StreamHandle context)
  5. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  6. pre-CREATE (open file, allocate StreamHandle context)
  7. post-CREATE (attach the StreamHandle context)
  8. pre-READ
  9. pre-CLOSE (successfully get the StreamHandle context)
  10. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  11. pre-CREATE (open the file, allocate StreamHandle context)
  12. post-CREATE (attach the StreamHandle context)
  13. pre-CLEANUP (successfully get the StreamHandle context)
  14. pre-CLOSE (successfully get the StreamHandle context)
  15. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  16. pre-CLEANUP is called and successfully fetches the StreamHandle context pointer.

Hence the file is opened 3 times and each time a StreamHandle context is created along the way. Likewise, the file is closed 3 times and the ContextCleanup handler is called 3 times.

However, after the 3rd time that my ContextCleanup callback has been called, my pre-CLEANUP callback gets called. I’m not concerned about the timing of this call (should I be?), but am puzzled because it successfully calls FltGetStreamHandleContext() to fetch the pointer to a StreamHandle context. I had thought that this context would not exist at this time - since 3 such contexts had previously been created and destroyed.

Does this mean that FltGetStreamHandleContext() can return a pointer to a previously-destroyed StreamHandle context? In other words, can the pointer returned by FltGetStreamHandleContext() outlive the context that it points to?

Thanks for any & all advice…

Kind regards,

David

2

From everything I’ve read in the docs, this should not happen ever.
However, I’ve seen it myself - there are several threads
in the archive that detail this exact problem, but it seems the boys and
girls at MS think we’re all full of crap.

I have had successful returns from FltGetStreamHandleContext after the
context was supposedly destroy, only to reference it
with success and have the data I stored there, and then have the damn
thing dissapear a second later thus resulting in a system crash.

Perhaps they’ll start looking into this phenomenon now since it has been
brought up several times now.

m.

xxxxx@optushome.com.au wrote:

Hi,

I’m experimenting with minifilter contexts by changing a bunch of code in the minispy example minifilter, and I don’t understand the lifetime of a StreamHandle context pointer.

In my pre-CREATE callback, I call FltAllocateContext() to allocate a STREAMHANDLE context. In the post-CREATE callback, I call FtlSetStreamHandleContext() [and then FltReleaseContext()] to attach the context to the opened file stream.

In subsequent “pre-” callback operations (e.g. READs, WRITEs, CLEANUPs, and CLOSEs), I call FltGetStreamHandleContext() to try to obtain the associated stream handle. If I can get the STREAMHANDLE context, then I call FltReleaseContext() to release it.

I also have a context cleanup handler that logs when it has been called to cleanup the given context.

Given all this, when I copy a tiny file from drive E: to F:, the sequence of callbacks that I see for the particular file is as follows (ignoring the FastIO queries and stuff)…

  1. pre-CREATE (open the file, allocate StreamHandle context)
  2. post-CREATE (attach the StreamHandle context)
  3. pre-CLEANUP (successfully get the StreamHandle context)
  4. pre-CLOSE (successfully get the StreamHandle context)
  5. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  6. pre-CREATE (open file, allocate StreamHandle context)
  7. post-CREATE (attach the StreamHandle context)
  8. pre-READ
  9. pre-CLOSE (successfully get the StreamHandle context)
  10. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  11. pre-CREATE (open the file, allocate StreamHandle context)
  12. post-CREATE (attach the StreamHandle context)
  13. pre-CLEANUP (successfully get the StreamHandle context)
  14. pre-CLOSE (successfully get the StreamHandle context)
  15. ContextCleanup handler is called (presumably as the object that the StreamHandle context is attached to, is torn down)
  16. pre-CLEANUP is called and successfully fetches the StreamHandle context pointer.

Hence the file is opened 3 times and each time a StreamHandle context is created along the way. Likewise, the file is closed 3 times and the ContextCleanup handler is called 3 times.

However, after the 3rd time that my ContextCleanup callback has been called, my pre-CLEANUP callback gets called. I’m not concerned about the timing of this call (should I be?), but am puzzled because it successfully calls FltGetStreamHandleContext() to fetch the pointer to a StreamHandle context. I had thought that this context would not exist at this time - since 3 such contexts had previously been created and destroyed.

Does this mean that FltGetStreamHandleContext() can return a pointer to a previously-destroyed StreamHandle context? In other words, can the pointer returned by FltGetStreamHandleContext() outlive the context that it points to?

Thanks for any & all advice…

Kind regards,

David

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