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/


Sending oversized data via FltSendMessage

Rade_TodorovicRade_Todorovic Member Posts: 8
edited September 16 in NTFSD

Would anyone know what is the expected behaviour of FltSendMessage / FilterGetMessage pair when the size of data sent (in FltSendMessage) is larger than the size of the buffer(s) provided by any I/O requests already pending (or initiated afterwards within the timeout) via FilterGetMessage? Is it documented at all, in the first place, or can it be inferred from general considerations about how I/O works? Or is it just one of those cases where it is not safe to try this, and one should always ensure that the buffer(s) provided by FilterGetMessage are large enough?

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 350
    via Email
    Did you even try this?
    I would imagine a buffer_overflow error would be returned by FilterGetMessage.
    Anything else is a recipe for disaster, and if MS did no consider
    it... we are ....ed :)

    On 9/16/20, Rade_Todorovic wrote:
    > OSR https://community.osr.com/
    >
    > Rade_Todorovic started a new discussion: Sending oversized data via
    > FltSendMessage
    >
    > Would anyone know what is the expected behaviour of FltSendMessage /
    > FilterGetMessage pair when the size of data sent (in FltSendMessage) is
    > larger than the size of the buffer(s) provided by any I/O requests pending
    > or received afterwards within the timeout (via FilterGetMessage)? Is it
    > documented at all, in the first place, or can it be inferred from general
    > considerations about how I/O works? Or is it just one of those cases where
    > it is not safe to try this, and one should always ensure that the buffer(s)
    > provided by FilterGetMessage are large enough?
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/292387/sending-oversized-data-via-fltsendmessage
    >
    > Check it out:
    > https://community.osr.com/discussion/292387/sending-oversized-data-via-fltsendmessage
    >
  • Rade_TodorovicRade_Todorovic Member Posts: 8

    @Dejan_Maksimovic I did try it out, and I am trying to make sense of what I've seen. However, I am also interested in what is supposed to happen, i.e. what (undocumented?) behaviour won't suddenly change with a new release of Windows.

    From my experiments, one waiter does complete with ERROR_INSUFFICIENT_BUFFER and I can see the desired size in OVERLAPPED - and I can retry. However, it gets very messy if other threads are also waiting, it seems that all of them complete with ERROR_SUCCESS ... with 0 bytes transferred and STATUS_PENDING in OVERLAPPED ... and then if everyone just retries, often everything gets stuck.

  • Rade_TodorovicRade_Todorovic Member Posts: 8

    I think I got it working - I had some bugs in the user mode code. Basically, it seems that FilterGetMessage will complete, with ERROR_INSUFFICIENT_BUFFER, for at least one waiter, and upon completion the required size of the buffer is known, so the user mode can retry and fetch the message with a bigger buffer. At least on this Windows 10 19H1 build I am testing with.

Sign In or Register to comment.

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