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

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:

Minifilter communication performance based on scanner sample

gtordaigtordai Member Posts: 9
First of all thank you for the invaluable information on this site. I have a very basic question. We have a very simple minifilter for inner use, that sometimes sends a great number of messages to userland. The communication is based on the scanner sample, through a completion port.
In the sample, there is a requestCount parameter, and the user component reserves that many messages in the memory per working thread, and sends that many filterGetMessage s to the filter.
I thought that the reason behind this was that when the filter sends up say a thousand messages, if there are enough pending filterGetMessages, the messages are delivered quasi instant, and then we can use the completion port to process them one by one, without blocking the filter.
However, what I see is that changing this parameter to match the expected message count does not influence at all the speed of operation, as if the message from the minifilter was not delivered until popped from the completion port. Am I missing something?
Thank you,


  • rstruempfrstruempf Member Posts: 103

    When you call FltSendMessage() from the driver, it blocks until the message has been read, and if a response is requested, until a response is received (with timeouts). You can get good performance by having multiple foreground threads waiting on the completion port so that a given kernel thread generally only has to wait as long as it takes that message to be processed, as opposed to waiting for the entire queue to be processed.

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