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

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

FilterGetMessage

DWDriverDWDriver Member Posts: 5

Hi,
I know that this function was discussed in the past many times, however I have a strange Probleme with it and cannot find a solution.

Code:
FilterGetMessage - with lpOverlapped = NULL is regular called in a (win32) worker thread.
If the mini Filter calls FltSendMessage (no reply) FilterGetMessage returns S_OK and the received message - only 1 DWORD32 - is correct.

So far, kernel to user communication is established and correct. However, with every FilterGetMessage call the memory usage increases?

  1. I do not allocate memory in the kernel nor in the User worker thread.
  2. To find the memory leak I comment out FltSendMessage in the kernel. Memory usage still increasing, so the kernel cannot be the source of fault.
  3. I comment out FilterGetMessage in the user thread, now the memory usage does no long increase and remains stable!

Strange too is that FilterGetMessage - (wth lpOverlapped = NULL) - returns immediately. The MS DOC however says "... the caller is put into a wait state until a message is received."
That's not the case.

Summary:
FilterGetMessage returns immediately even no FltSendMessage has been executed in the kernel. The function returns S_OK evn in that case. Every call of FilterGetMessage increases the memory usage until it is exhausted and the test computer hangs up.

Here's a cutout of my code:

typedef struct _DLLFILTER_MESSAGE
{
// Required structure header.
FILTER_MESSAGE_HEADER MessageHeader;
// payload
DWORD32 dwKernelCommand;
}FILTER_MESSAGE;

FILTER_MESSAGE strcMessageFromFilter;
DWORD32 dwMessageSendBufferSize = sizeof(FILTER_MESSAGE_HEADER) + sizeof(DWORD32);
HRESULT hResult = FilterGetMessage(hConnectionClientPort, &strcMessageFromFilter.MessageHeader, dwMessageSendBufferSize, NULL);
if (FAILED(hResult))
{ … }

This code is so simple, but I'm obviously doing doing something wrong, but what?

Please help.
Dietmar

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,151

    When you say, "the memory usage" what memory do you mean? If you step through FilterGetMessage you'll see that it does not directly allocate any memory, so trying to figure out what you're seeing and what's going on.

    -scott
    OSR

  • DWDriverDWDriver Member Posts: 5

    Scott,

    Thank you! "Memory", I just see in the TaskManager that the memory usage increases rather fast, ~100MB/s. In the thread, only FilterGetMessage is active as shown above. I definitely do not (explicit) allocate memory on heap, or stack, not in user not in kernel mode.

    If I comment out that function, it is OK:
    FILTER_MESSAGE strcMessageFromFilter;
    DWORD32 dwMessageSendBufferSize = sizeof(FILTER_MESSAGE_HEADER) + sizeof(DWORD32);
    // HRESULT hResult = FilterGetMessage(hConnectionClientPort, &strcMessageFromFilter.MessageHeader, dwMessageSendBufferSize, NULL);

    Regarding my other question, why returns FilterGetMessage with S_OK immediately after calling it, even no message was sent from the kernel?
    Thanks
    Dietmar

  • rstruempfrstruempf Member Posts: 103

    When overlapped IO is not used, in my experience, FilterGetMessage() does wait until FltSendMessage() is called by the driver. Is your driver calling FltSendMessage()? I think it must be, or your call to FilterGetMessage() would wait.

    Assuming it is, then your memory leak may be the driver waiting for a response. If the header has a non-zero MessageId, then the driver is waiting for a response, which you should send using FilterReplyMessage(). If you used null or a large value for timeout on the driver's call to FltSendMessage(), then that kernel thread will block waiting for that reply.

    If your ReplyBuffer and ReplyLength parameters are null and 0 in the call to FltSendMessage(), then MessageId should be 0.

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
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA