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?
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
>
@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.
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.