Communication Between Filter Drivers and User-Mode Applications

In most real-world applications, filter drivers don't work in isolation. While the filter driver intercepts or modifies I/O at the kernel level, it often needs to communicate with user-mode application to:

• Report events (e.g., file access logs)
• Retrieve dynamic configuration (e.g., allow/block lists)
• Sends alerts or ask for user confirmation (e.g., DLP enforcement)
• Receive control commands (e.g., start/stop filtering)

For example, an antivirus filter driver might block an exe write but also notify the user-mode GUI to display an alert or log the incident to a database.

To enable this interaction, Windows provides robust communication APIs in the Minifilter (FltMgr) framework: specifically, FltPort messaging.

Communication Methods Overview

Here are common methods for user-kernel communication in filter drivers:

In Minifilters, FltPorts is the only official and safe way to implement runtime communication with user-mode apps.

Core Components of FltPort Communication

1 Server-Side (Minifilter)

• Creates a named port with FltCreateCommunicationPort
• Registers callbacks for message handling
• Sends responses to the client app

2 Client-Side (User-Mode App)

• Connects to the port using FilterConnectCommunicationPort
• Sends data via FilterSendMessage or asynchronously using FilterGetMessage

3 Communication Port Structure

+------------------+               +------------------------+
| User-Mode App    |<-- connect -->| Filter Driver (Kernel) |
| (Logger / GUI)   |               | - Handles connect      |
| - Sends messages |---send msg--->| - Replies with data    |
+------------------+               +------------------------+