FilterSendMessage in buffer cannot be empty

The doc for FilterSendMessage() says:

lpInBuffer
Pointer to a caller-allocated buffer containing the message to be sent to the minifilter. The message format is caller-defined. This parameter is optional and can be NULL.
dwInBufferSize
Size, in bytes, of the buffer pointed to by lpInBuffer. This value is ignored if lpInBuffer is NULL.

However, I repeatedly get E_INVALIDARG when I pass NULL, 0 for these two parameters.

My code works if I pass &dwDummy, sizeof(dwDummy).

Is this a documentation bug? a bug in FltLib? or a confusion on my part?

Brian

xxxxx@iOra.com wrote:

Just guessing, but what about the messagecallback in
FltCreateCommunicationPort?

That parameter states:

/MessageNotifyCallback/
Pointer to a caller-supplied callback routine. The Filter Manager
calls this routine, at IRQL = PASSIVE_LEVEL, whenever a user-mode
application calls *FilterSendMessage* to send a message to the
minifilter driver through the client port. This parameter is
optional and can be NULL. If it is NULL, any request made from user
mode to send data to the port will receive an error.

Matt

The doc for FilterSendMessage() says:

lpInBuffer
Pointer to a caller-allocated buffer containing the message to be sent to the minifilter. The message format is caller-defined. This parameter is optional and can be NULL.
dwInBufferSize
Size, in bytes, of the buffer pointed to by lpInBuffer. This value is ignored if lpInBuffer is NULL.

However, I repeatedly get E_INVALIDARG when I pass NULL, 0 for these two parameters.

My code works if I pass &dwDummy, sizeof(dwDummy).

Is this a documentation bug? a bug in FltLib? or a confusion on my part?

Brian


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

xxxxx@iOra.com wrote:

Well never mind, after hitting ‘Send’, then I saw that one line about
&dwDummy… Oh well, I’ll take that title.

Guess looking at your return code from that callback is all I can think
of…

Sorry/Good Luck

Matt

The doc for FilterSendMessage() says:

lpInBuffer
Pointer to a caller-allocated buffer containing the message to be sent to the minifilter. The message format is caller-defined. This parameter is optional and can be NULL.
dwInBufferSize
Size, in bytes, of the buffer pointed to by lpInBuffer. This value is ignored if lpInBuffer is NULL.

However, I repeatedly get E_INVALIDARG when I pass NULL, 0 for these two parameters.

My code works if I pass &dwDummy, sizeof(dwDummy).

Is this a documentation bug? a bug in FltLib? or a confusion on my part?

Brian


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

With a lpInBuffer of NULL, my MessageNotifyCallback doesn’t even get called. I am guessing that there is some undocumented parameter validation in the user-mode code that does not agree with the documentation which explicitly says it should be allowed.

It’s no big deal now for me, as I got it to work with a dummy parameter. But it would be nice to get get the documentation and/or library corrected for the future. That might prevent someone else wasting the half a day it took me!

Brian

xxxxx@iOra.com wrote:+

Yes, the docs could be a little more clear here. After reading this
post, I had to conduct my own test. I modified the scanner sample
to do just this; let the scanuser.exe send a message via
FilterSendMessage with nulls and I set up a callback in the filter with a
__debugbreak statement. (it never broke)

It certainly does appear that the null’s prevent the
MessageNotifyCallback from firing. This did surprise me. By putting
null’s in that
parameter, it does appears that it is as if NO callback is defined which
would generate the error you described. This would kinda
make sense half way; why process a message in a callback if it isn’t
there…

From what you’ve described, and what I’ve
witnessed this morning, I’d assume this is a flaw in Filter Manager’s
logic. I don’t think this particular area was even ever tested given
I recall a thread that was somehow related to async vs sync and a MS
developer stated they never tested the particular path (while unrelated,
it demonstrated to me some paths that were rarely used were ignored);
then again
my memory is ‘hazy’ and I’m sure my recollection must be wrong.

Calling FilterSendMessage without a reply or input data does seem
strange to me even though documented as possible (on input). I doubt much
testing time was put into this and it hasn’t surfaced until now because
this is in my opinion a ‘weird design’ and your the Lone Ranger.

Just my 1/2 cent. Good Luck and best wishes,

Matt

With a lpInBuffer of NULL, my MessageNotifyCallback doesn’t even get called. I am guessing that there is some undocumented parameter validation in the user-mode code that does not agree with the documentation which explicitly says it should be allowed.

It’s no big deal now for me, as I got it to work with a dummy parameter. But it would be nice to get get the documentation and/or library corrected for the future. That might prevent someone else wasting the half a day it took me!

Brian


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Matt,

Calling FilterSendMessage without a reply or input data does seem
strange to me even though documented as possible (on input). I doubt much
testing time was put into this and it hasn’t surfaced until now because
this is in my opinion a ‘weird design’ and your the Lone Ranger.

It *does* have a reply (outBuffer) - just no request (inBuffer). FYI, the port is used to read buffered (multiplexed) logging that just happens to be mediated by the filter driver. So I don’t need an inBuffer. But passing a dummy value is no problem.

Also, I can well believe this code path is untested, as it must be pretty rare. It is just strange that the documentation is so precise - given that it appears to be wrong!

Thanks for the input

Brian