A couple newbie questions

Hi all,

I’m pretty new to the whole area of driver development, and I’m trying to get my feet wet with a practical application, and I was wondering if somebody could pass along a hint or two. I’ve spent some time looking and haven’t really found anything too useful to me yet.

Basically I am trying to develop a simple content filtering system. I’d like to use a WFP callout to inspect and/or modify the TCP stream data. I would like to keep most of the inspection/modification login at the application level. i.e. I would ideally like to be able to intercept the data in the WFP callout, somehow pass it to a running user-mode application, have the user-mode application inspect it, potentially modify it, and return to the callout module the data that should be injected in it’s place.

I have found the IOCTLs which allow a user-mode application to communicate with a kernel-mode driver, but I don’t see any correlary that will go the opposite direction.

After some searching I found some suggestions to used named pipes. So I’ve got a user-mode application that opens a named pipe, and the callout module connects to the named pipe and sends/receives data. This works to certain extent. i.e. if I connect to the pipe in DriverEntry I can send/receive whatever I want, and then close the pipe in DriverUnload, and everything seems to work okay.

If I open the pipe in DriverEntry, and then write to the pipe from the classifyFn function, the communication seems to work fine, but when I later try to close the pipe, whether I close it from the user mode application, or close it from the callout module the system crashes. If I comment out the write operations in classifyFn, then there is no crash when the pipe is closed.

So after this longwinded background, there are a few questions that I have.

  1. Is it an all around bad idea to use named pipes in this manner from a kernel-mode driver?

  2. If no, what could be the problem that is causing the system to crash in this way?

  3. If yes, is there another, more elegant/appropriate way to do what I am trying to do?

Thanks a bunch,
Gerald

The most conventional approach to app-driver communication is via IOCTL. Study the WDK src\general\ioctl sample, for example. Then browse other WDK samples that may employ various implementations of app-driver communication via IOCTL.

Search the archives of this list for discussions of the “inverted-call” method. In this approach the application makes asynchronous IOCTL class to the driver which the driver pends until it needs to pass information to the application. The application, of course, then waits (and here are various techniques to do this including “asynchronous procedure callbacks”, etc.) for the IOCTL to complete. Although this seems a little “backwards”, the inverted call approach has advantages that are discussed in the archives.

The archives may bring up other alternatives as well, but a pipe would probably be one of the least used approaches.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-311482-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, January 15, 2008 12:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] A couple newbie questions

Hi all,

I’m pretty new to the whole area of driver development, and I’m trying
to get my feet wet with a practical application, and I was wondering if
somebody could pass along a hint or two. I’ve spent some time looking
and haven’t really found anything too useful to me yet.

Basically I am trying to develop a simple content filtering system. I’d
like to use a WFP callout to inspect and/or modify the TCP stream data.
I would like to keep most of the inspection/modification login at the
application level. i.e. I would ideally like to be able to intercept
the data in the WFP callout, somehow pass it to a running user-mode
application, have the user-mode application inspect it, potentially
modify it, and return to the callout module the data that should be
injected in it’s place.

I have found the IOCTLs which allow a user-mode application to
communicate with a kernel-mode driver, but I don’t see any correlary
that will go the opposite direction.

After some searching I found some suggestions to used named pipes. So
I’ve got a user-mode application that opens a named pipe, and the
callout module connects to the named pipe and sends/receives data. This
works to certain extent. i.e. if I connect to the pipe in DriverEntry I
can send/receive whatever I want, and then close the pipe in
DriverUnload, and everything seems to work okay.

If I open the pipe in DriverEntry, and then write to the pipe from the
classifyFn function, the communication seems to work fine, but when I
later try to close the pipe, whether I close it from the user mode
application, or close it from the callout module the system crashes.
If I comment out the write operations in classifyFn, then there is no
crash when the pipe is closed.

So after this longwinded background, there are a few questions that I
have.

  1. Is it an all around bad idea to use named pipes in this manner from
    a kernel-mode driver?

  2. If no, what could be the problem that is causing the system to crash
    in this way?

  3. If yes, is there another, more elegant/appropriate way to do what I
    am trying to do?

Thanks a bunch,
Gerald


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

Thanks, Thomas. The “inverted-call” method sounds like it’s probably what I need. I will investigate that further. I had a feeling that using pipes wasn’t going to be the best approach, but I was having trouble finding anything else that worked. Thanks again.

“Thomas F. Divine” wrote:
The most conventional approach to app-driver communication is via IOCTL. Study the WDK src\general\ioctl sample, for example. Then browse other WDK samples that may employ various implementations of app-driver communication via IOCTL.

Search the archives of this list for discussions of the “inverted-call” method. In this approach the application makes asynchronous IOCTL class to the driver which the driver pends until it needs to pass information to the application. The application, of course, then waits (and here are various techniques to do this including “asynchronous procedure callbacks”, etc.) for the IOCTL to complete. Although this seems a little “backwards”, the inverted call approach has advantages that are discussed in the archives.

The archives may bring up other alternatives as well, but a pipe would probably be one of the least used approaches.

Thomas F. Divine

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-311482-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
> Sent: Tuesday, January 15, 2008 12:24 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] A couple newbie questions
>
> Hi all,
>
> I’m pretty new to the whole area of driver development, and I’m trying
> to get my feet wet with a practical application, and I was wondering if
> somebody could pass along a hint or two. I’ve spent some time looking
> and haven’t really found anything too useful to me yet.
>
> Basically I am trying to develop a simple content filtering system. I’d
> like to use a WFP callout to inspect and/or modify the TCP stream data.
> I would like to keep most of the inspection/modification login at the
> application level. i.e. I would ideally like to be able to intercept
> the data in the WFP callout, somehow pass it to a running user-mode
> application, have the user-mode application inspect it, potentially
> modify it, and return to the callout module the data that should be
> injected in it’s place.
>
> I have found the IOCTLs which allow a user-mode application to
> communicate with a kernel-mode driver, but I don’t see any correlary
> that will go the opposite direction.
>
> After some searching I found some suggestions to used named pipes. So
> I’ve got a user-mode application that opens a named pipe, and the
> callout module connects to the named pipe and sends/receives data. This
> works to certain extent. i.e. if I connect to the pipe in DriverEntry I
> can send/receive whatever I want, and then close the pipe in
> DriverUnload, and everything seems to work okay.
>
> If I open the pipe in DriverEntry, and then write to the pipe from the
> classifyFn function, the communication seems to work fine, but when I
> later try to close the pipe, whether I close it from the user mode
> application, or close it from the callout module the system crashes.
> If I comment out the write operations in classifyFn, then there is no
> crash when the pipe is closed.
>
> So after this longwinded background, there are a few questions that I
> have.
>
> 1) Is it an all around bad idea to use named pipes in this manner from
> a kernel-mode driver?
>
> 2) If no, what could be the problem that is causing the system to crash
> in this way?
>
> 3) If yes, is there another, more elegant/appropriate way to do what I
> am trying to do?
>
> Thanks a bunch,
> Gerald
>
> —
> 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


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

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

> After some searching I found some suggestions to used named pipes.

Inverted call is better. Pending IOCTL, which is completed (with data) when
some event in kernel-mode occurs.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com