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

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

FilterSendMessage in buffer cannot be empty

OSR_Community_UserOSR_Community_User Member Posts: 110,217
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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    [email protected] 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: [email protected]
    > To unsubscribe send a blank email to [email protected]
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    [email protected] 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: [email protected]
    > To unsubscribe send a blank email to [email protected]
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    [email protected] 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: [email protected]
    > To unsubscribe send a blank email to [email protected]
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
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
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE