Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


What is the difference between stream-context and stream-handle-context?

ShangwuShangwu Member Posts: 185
My minifilter traces a directory rename operation by setting stream-handle
context. It sets the context under the POST-CREATE, changes some data under
PRE-SETINFORMATION, and clear the context under PRE-CLEANUP.
But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
same fileobject as the following sequence shows:

PostCreate Called, fileObj: 86a65720
PreCleanup Called, fileObj: 86a65720
PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
PostCreate Called, fileObj: 86a65720
PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
PreCleanup Called, fileObj: 86a65720

So before the SETINFORMATION IRP uses the stream handle context, the context
is already cleared by another CLEANUP IRP.
Why is the same file object reused by multiple CREATE IRPs?
Should I use a CLOSE callback to clear the context?
Some old OSR threads say that a CLOSE IRP may not come for a long time.

Thanks for any comment.

Shangwu

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,158
    Are you tracing CLOSE operations? If not I don't see any problems with the
    trace below - The IoManager is reusing the same address for three
    (logically) different FileObjects. You are only ocassionally attaching
    stream handle contexts and so you are only getting those contexts back.

    > Some old OSR threads say that a CLOSE IRP may not come for a long time.

    Yes, but the close IRP may also (and usually does) come immediately,
    particularly for directories.

    > Should I use a CLOSE callback to clear the context?
    It depends whether you care about any operations which come after a cleanup,
    but for directory rename I'd say you are safe with CLEANUP.

    "Shangwu" wrote in message news:[email protected]
    > My minifilter traces a directory rename operation by setting stream-handle
    > context. It sets the context under the POST-CREATE, changes some data
    > under PRE-SETINFORMATION, and clear the context under PRE-CLEANUP.
    > But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
    > same fileobject as the following sequence shows:
    >
    > PostCreate Called, fileObj: 86a65720
    > PreCleanup Called, fileObj: 86a65720
    > PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
    > PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
    > PostCreate Called, fileObj: 86a65720
    > PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
    > PreCleanup Called, fileObj: 86a65720
    >
    > So before the SETINFORMATION IRP uses the stream handle context, the
    > context is already cleared by another CLEANUP IRP.
    > Why is the same file object reused by multiple CREATE IRPs?
    > Should I use a CLOSE callback to clear the context?
    > Some old OSR threads say that a CLOSE IRP may not come for a long time.
    >
    > Thanks for any comment.
    >
    > Shangwu
    >
    >
    >
    >
  • ShangwuShangwu Member Posts: 185
    Thanks Rod for your help.
    I am tracing RENAME operations. I don't understand that during a RENAME
    transaction (from open, rename, cleanup, to close) the file object is reused
    by another operation with open and cleanup.

    Another question is that if I want to set a stream handle context for a file
    object, how do I identify different handles for the referred file object?

    Thanks,

    Shangwu


    "Rod Widdowson" wrote in message
    news:[email protected]
    > Are you tracing CLOSE operations? If not I don't see any problems with
    > the trace below - The IoManager is reusing the same address for three
    > (logically) different FileObjects. You are only ocassionally attaching
    > stream handle contexts and so you are only getting those contexts back.
    >
    >> Some old OSR threads say that a CLOSE IRP may not come for a long time.
    >
    > Yes, but the close IRP may also (and usually does) come immediately,
    > particularly for directories.
    >
    >> Should I use a CLOSE callback to clear the context?
    > It depends whether you care about any operations which come after a
    > cleanup, but for directory rename I'd say you are safe with CLEANUP.
    >
    > "Shangwu" wrote in message news:[email protected]
    >> My minifilter traces a directory rename operation by setting
    >> stream-handle context. It sets the context under the POST-CREATE, changes
    >> some data under PRE-SETINFORMATION, and clear the context under
    >> PRE-CLEANUP.
    >> But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
    >> same fileobject as the following sequence shows:
    >>
    >> PostCreate Called, fileObj: 86a65720
    >> PreCleanup Called, fileObj: 86a65720
    >> PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
    >> PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
    >> PostCreate Called, fileObj: 86a65720
    >> PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
    >> PreCleanup Called, fileObj: 86a65720
    >>
    >> So before the SETINFORMATION IRP uses the stream handle context, the
    >> context is already cleared by another CLEANUP IRP.
    >> Why is the same file object reused by multiple CREATE IRPs?
    >> Should I use a CLOSE callback to clear the context?
    >> Some old OSR threads say that a CLOSE IRP may not come for a long time.
    >>
    >> Thanks for any comment.
    >>
    >> Shangwu
    >>
    >>
    >>
    >>
    >
    >
    >
  • ShangwuShangwu Member Posts: 185
    I forget to mention that this is only happened for requests coming from SRV
    process.

    "Shangwu" wrote in message news:[email protected]
    > Thanks Rod for your help.
    > I am tracing RENAME operations. I don't understand that during a RENAME
    > transaction (from open, rename, cleanup, to close) the file object is
    > reused by another operation with open and cleanup.
    >
    > Another question is that if I want to set a stream handle context for a
    > file object, how do I identify different handles for the referred file
    > object?
    >
    > Thanks,
    >
    > Shangwu
    >
    >
    > "Rod Widdowson" wrote in message
    > news:[email protected]
    >> Are you tracing CLOSE operations? If not I don't see any problems with
    >> the trace below - The IoManager is reusing the same address for three
    >> (logically) different FileObjects. You are only ocassionally attaching
    >> stream handle contexts and so you are only getting those contexts back.
    >>
    >>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
    >>
    >> Yes, but the close IRP may also (and usually does) come immediately,
    >> particularly for directories.
    >>
    >>> Should I use a CLOSE callback to clear the context?
    >> It depends whether you care about any operations which come after a
    >> cleanup, but for directory rename I'd say you are safe with CLEANUP.
    >>
    >> "Shangwu" wrote in message news:[email protected]
    >>> My minifilter traces a directory rename operation by setting
    >>> stream-handle context. It sets the context under the POST-CREATE,
    >>> changes some data under PRE-SETINFORMATION, and clear the context under
    >>> PRE-CLEANUP.
    >>> But the thing is not so simple. Several CREATE and CLEANUP IRPs using
    >>> the same fileobject as the following sequence shows:
    >>>
    >>> PostCreate Called, fileObj: 86a65720
    >>> PreCleanup Called, fileObj: 86a65720
    >>> PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
    >>> PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
    >>> PostCreate Called, fileObj: 86a65720
    >>> PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
    >>> PreCleanup Called, fileObj: 86a65720
    >>>
    >>> So before the SETINFORMATION IRP uses the stream handle context, the
    >>> context is already cleared by another CLEANUP IRP.
    >>> Why is the same file object reused by multiple CREATE IRPs?
    >>> Should I use a CLOSE callback to clear the context?
    >>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
    >>>
    >>> Thanks for any comment.
    >>>
    >>> Shangwu
    >>>
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >
    >
    >
  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,158
    > I don't understand that during a RENAME transaction (from open, rename,
    > cleanup, to close) the file object is reused by another operation with
    > open and cleanup.

    Which is why I asked originally whether you are tracing close? If not all I
    am seeing in your original; post is

    CREATE, CLEANUP, [CLOSE not traced]
    CREATE, [sethandle], CLEANUP, [CLOSE not traced]
    CREATE, SET_INFORMATION, CLEANUP, [CLOSE not traced]

    So you are getting three *different* file objects at the same address.
  • ShangwuShangwu Member Posts: 185
    Yes. The same file object is reused for many times during a RENAME
    operation.

    "Rod Widdowson" wrote in message
    news:[email protected]
    >> I don't understand that during a RENAME transaction (from open, rename,
    >> cleanup, to close) the file object is reused by another operation with
    >> open and cleanup.
    >
    > Which is why I asked originally whether you are tracing close? If not all
    > I am seeing in your original; post is
    >
    > CREATE, CLEANUP, [CLOSE not traced]
    > CREATE, [sethandle], CLEANUP, [CLOSE not traced]
    > CREATE, SET_INFORMATION, CLEANUP, [CLOSE not traced]
    >
    > So you are getting three *different* file objects at the same address.
    >
    >
    >
    >
    >
    >
  • yuval0x92yuval0x92 Member Posts: 2

    Because the Memory Manager can cache the file object and use it for other applications performing mapped I/O, whenever a Cleanup operation is seen on a file object, that file object stream should no longer be considered unique.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,352

    The last post to this thread was 13 years ago...If you have a question post to a new thread.

    -scott
    OSR

This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE