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/


Proper usage of FltReissueSynchronousIo

zigfridzigfrid Member Posts: 3
edited June 2023 in NTFSD

Hello folks!

Is it safe and legal to reissue opeartion that did not in fact failed? Documentation says "It typically calls FltReissueSynchronousIo from a postoperation callback routine to reissue a failed operation with different parameters" so I suppose it is not only about failed operations right?
Suppose I am at post create callback level and I see CreateFile operation that did not failed and I would like to reissue this operation with slightly changed parameters. Is that fine to call it (referring to non failed op)?

If so then is this API someone cancellng current IO or this is on me to cancel current IO once I reissued this operation? I am wondering how to say drivers below me (that already served post callback before) that this IO was not valid anymore.

Thank you for help

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,266
    edited June 2023

    No you cannot.

    You can do a FltCancelOpen, but that documentation states explicitly

    Once the create operation has been canceled, it cannot be reissued. For more information, see FltReissueSynchronousIo.

    In order to do what you want you need to look at shadow opens and that is a huge amount of work

  • zigfridzigfrid Member Posts: 3

    Hi Rod,

    Thank you for answer. Let me dig a bit:
    1. I saw in doc section you quoted, but I was wondering about calling FltReissueSynchronousIo first and once it return to my code then call FtlCancelIo (everything from post create callback). Would it work?
    2. Can you please emphasize your comment about "shadow opens"? I am not sure I follow your comment here.

    Thank you again.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,266

    I saw in doc section you quoted, but I was wondering about calling FltReissueSynchronousIo first and once it return to my code then call FtlCancelIo (everything from post create callback). Would it work?

    Nope. By the time you get to post call the files object is all set up so you cannot set it up again
     
    As far as shadowing goes - think of it as not sending the create down in the pre-call, but rather sending your own create down (FltCreateFileEx). You then have a handle and you can do whatever you want with it. In full shadowing you then pretend to the filters above you that the the create they saw has been completed (and expect to aspend about 9-12 month elapsed to make this start to work. In your case you can just decide to mess around before you send down the create as before. But

    • You need to worry about what you are going to do about relative opens
    • You need to worry about constructive (FILE_CREATE) and destructive (FILE_OVERWRITE ...) creates
    • You need to worry about defender getting in on the act
    • You need to worry about strange ACLs on the directory (so a create might work once, but not twice)

    It is a huge amount of effort. It is even more if you expect to make it work on the network.

  • zigfridzigfrid Member Posts: 3

    Rod, again thank you for your valuable input.

    Actually I wanted to avoid doing FltCreateFileEx at pre-callback for two main reasons:

    • at pre create I dont know if process that is attempting to open file would ever succeed (due to ACLs for instance etc) and once I am at post I am sure OS allowed/failed this op. So it is kind of performance thing, because I would double opens that typically would fail and it was something I wanted to avoid and it was reason I was focusing on post callback.
    • I have feeling making FileOpen on pre-create callback level (actually at post callback it looks same to me) will significantly increase chance of making sharing violations in the system won't it? This is becuase I will kind of double opens ;(. My goal is to make is as much transparent to the system as I can.

    My original problem is one you mentioned: destructive create. In this case at post callback file is already destructed, meaning I cannot do anything with it's content (as it is wiped). I thought I could remove destructive flag in pre-callback, let it go (so it will succeed, but not wipe file) then at post reissue io with proper parameters, but from your previous comments it looks like it will not work.

    Do you happen to have any other idea maybe?

    Thank you once more.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,266

    I sort of mentioned it above, but you need to research IO_FORCE_ACCESS_CHECK (for your second point) and IO_IGNORE_SHARE_ACCESS_CHECK (for the first).

    Local disk only but if you are doing this on the network you are doing this at the wrong place

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online