Kernel Mode to User Mode Communication WFP Driver

Hi,

I am trying to implement a Windows Filtering Platform callout driver to document information on a network. I am gathering the information with a callout in kernel mode. I want to be able to send this information to the user mode to process the information retrieved. I have looked into a few ways to so this. I have looked into inverted calls, shared events, named pipes, and shared memory. I will need to be able to send a lot of information a lot of times from the kernel mode to the user mode. Does anyone have any suggestions of a technique to use in this situation or any helpful hints or more information on a particular way to do this?

Please correct me if I have interpreted something wrong, but what I have gotten so far is that shared events are basically like inverted calls, but contain separate calls for the signaling of an event to process and then a call to retrieve the information. Shared memory does not seem ideal in this situation. Named pipes are an undocumented feature that could cause problems in my driver along the line and shouldnt be used. Inverted calls seem to be most widely used.

Thank you for your help.

Been there done that.

You will find that an inverted callback will work just fine. Using WFP in KMDF makes the queuing even easier and you won’t have to worry about setting up a cancel safe queue.

Gary G. Little

----- Original Message -----
From: xxxxx@yahoo.com
To: “Windows System Software Devs Interest List”
Sent: Monday, May 23, 2011 11:17:57 AM
Subject: [ntdev] Kernel Mode to User Mode Communication WFP Driver

Hi,

I am trying to implement a Windows Filtering Platform callout driver to document information on a network. I am gathering the information with a callout in kernel mode. I want to be able to send this information to the user mode to process the information retrieved. I have looked into a few ways to so this. I have looked into inverted calls, shared events, named pipes, and shared memory. I will need to be able to send a lot of information a lot of times from the kernel mode to the user mode. Does anyone have any suggestions of a technique to use in this situation or any helpful hints or more information on a particular way to do this?

Please correct me if I have interpreted something wrong, but what I have gotten so far is that shared events are basically like inverted calls, but contain separate calls for the signaling of an event to process and then a call to retrieve the information. Shared memory does not seem ideal in this situation. Named pipes are an undocumented feature that could cause problems in my driver along the line and shouldnt be used. Inverted calls seem to be most widely used.

Thank you for your help.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

So using the example found here:
http://www.osronline.com/article.cfm?id=94

I have a few questions.

Would I register WFP callouts on the control device or the data device or would I make a new device for the callouts? I am not too sure I understand what the Control Device and what the Data Device represents.

Also, if I want to pass a structure of information containing remote port and local port info to the user, which queue do I add it to so that it gets processed and sent to the user when the user calls to request the info?

Here are the data and control structures:
typedef struct _COMM_CONTROL_DEVICE_EXTENSION
{
// Data structure magic #
ULONG MagicNumber;

// Symbolic Link Name
UNICODE_STRING SymbolicLinkName;

// Control Thread Service queue
LIST_ENTRY ServiceQueue;

// Control Thread Service Queue Lock
FAST_MUTEX ServiceQueueLock;

// Control Request Queue - awaiting dispatch to control threads
LIST_ENTRY RequestQueue;

// Control Request Queue Lock
FAST_MUTEX RequestQueueLock;

} COMM_CONTROL_DEVICE_EXTENSION, *PCOMM_CONTROL_DEVICE_EXTENSION;

typedef struct _COMM_DATA_DEVICE_EXTENSION
{
// Data structure magic #
ULONG MagicNumber;

// This is used to indicate the state of the device
ULONG DeviceState;

// Symbolic Link Name
UNICODE_STRING SymbolicLinkName;

// Read Request Queue
LIST_ENTRY ReadRequestQueue;

// Read Request Queue Lock
FAST_MUTEX ReadRequestQueueLock;

// Write Request Queue
LIST_ENTRY WriteRequestQueue;

// Write Request Queue Lock
FAST_MUTEX WriteRequestQueueLock;

} COMM_DATA_DEVICE_EXTENSION, *PCOMM_DATA_DEVICE_EXTENSION;