Communication between two drivers

NTDEV
1

Hello All,

For my USB device I have a upper filter and lower filter drivers (two different sys files). I need to send some information from upper filter to lower filter. To achieve this, I had used ExCreateCallback(…), ExRegisterCallback(…), ExNotifyCallback(…) callback objects. The communication is working great.

However, When I plug in two USB devices and install the filter drivers, will the information be passed as expected.

I have hard coded the callback object name. So, I guess both the devices use same object name.

For device1 if I have upper filter1 and lower filter1 instanace and similarly for device2 if I have upper filter2 and lower filter2 instance. If upper filter1 wants to send some information to lower filter1, Is there any chance that lower filter2 receive that information instead of lower filter1?

Is there any way to avoid this problem?

Thank You.

Regards,
Madhu

2

Just have the upper filter send a unique IOCTL to the lower filter. The
lower filter can recognize and complete the IOCTL. There are uses for
the Callback functions but two filters in the same stack is not a good
use of these.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Thursday, April 22, 2010 7:31 AM
Posted To: ntdev
Conversation: Communication between two drivers
Subject: Communication between two drivers

Hello All,

For my USB device I have a upper filter and lower filter drivers (two
different sys files). I need to send some information from upper
filter to
lower filter. To achieve this, I had used ExCreateCallback(…),
ExRegisterCallback(…), ExNotifyCallback(…) callback objects. The
communication is working great.

However, When I plug in two USB devices and install the filter
drivers, will
the information be passed as expected.

I have hard coded the callback object name. So, I guess both the
devices use
same object name.

For device1 if I have upper filter1 and lower filter1 instanace and
similarly
for device2 if I have upper filter2 and lower filter2 instance. If
upper
filter1 wants to send some information to lower filter1, Is there any
chance
that lower filter2 receive that information instead of lower filter1?

Is there any way to avoid this problem?

Thank You.

Regards,
Madhu

__________ Information from ESET Smart Security, version of virus
signature
database 5049 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

3

>Just have the upper filter send a unique IOCTL to the lower filter.

I cannot use a IOCTL as there is an intermediate driver which would block the request. So, is it not possible with the callback objects for effective communication between these two filter drivers when two device are used.

Thanks,
Madhukar

4

Why would the intermediate driver have been poorly written to block the
request. The driver should in most cases assume that if it does not
recognized the IOCTL it should be passed through. If you really cannot
trust the intermediate drivers, then have the upper filter send an
IRP_MN_QUERY_INTERFACE to the stack below it, and then use the returned
interface to hold the pointers to the functions you need.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Thursday, April 22, 2010 8:32 AM
Posted To: ntdev
Conversation: Communication between two drivers
Subject: RE: Communication between two drivers

>Just have the upper filter send a unique IOCTL to the lower filter.

I cannot use a IOCTL as there is an intermediate driver which would
block the
request. So, is it not possible with the callback objects for
effective
communication between these two filter drivers when two device are
used.

Thanks,
Madhukar

__________ Information from ESET Smart Security, version of virus
signature
database 5049 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

5

Don Burn wrote:

Why would the intermediate driver have been poorly written
to block the request. The driver should in most cases assume
that if it does not recognized the IOCTL it should be passed
through.

A function driver should pass down IOCTLs that it doesn’t recognize? Sorry, I don’t think so. Why would it expect that the PDO representing the hardware would understand arbitrary IOCTL requests?

6

> Is there any way to avoid this problem?

Convert the PDO pointer to string using RtlStringCchPrintf(“%p”) and use this string with some prefix as a callback name.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> A function driver should pass down IOCTLs that it doesn’t recognize? Sorry, I don’t think so.

I second this.

Filter driver must pass everything down, not function one.

PnP interface queries must be passed down, though, by the functional driver too.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

> If you really cannot trust the intermediate drivers, then have the upper filter send an

IRP_MN_QUERY_INTERFACE to the stack below it, and then use the returned
interface to hold the pointers to the functions you need

I’m not sure how I can use IRP_MN_QUERY_INTERFACE to get the function pointers. Can you elaborate or provide a sample which does use this IRP.

9

Actually the “function driver rules all” philosophy became obsolete with
function drivers. So you pass down the IOCTL, if the PDO does not
handle it the request will be failed in a lower driver exactly what your
function driver would have done in the past.

My view is that with proliferation of bus drivers and advanced stacks
where making the Windows NT assumption of failing an IOCTL you don’t
recognize is just creating problems.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Posted At: Thursday, April 22, 2010 9:54 AM
Posted To: ntdev
Conversation: Communication between two drivers
Subject: RE: Communication between two drivers

Don Burn wrote:

> Why would the intermediate driver have been poorly written to block
> the request. The driver should in most cases assume that if it does
> not recognized the IOCTL it should be passed through.

A function driver should pass down IOCTLs that it doesn’t recognize?
Sorry, I
don’t think so. Why would it expect that the PDO representing the
hardware
would understand arbitrary IOCTL requests?

__________ Information from ESET Smart Security, version of virus
signature
database 5050 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

10

The INTERFACE structure is of variable size. Have the lower filter
return an INTERFACE with pointers to the functions you wish to provide.
Have the “context” field of the structure point to something (for
instance the device extension of the lower filter) that will ensure the
right device is accessed.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Posted At: Thursday, April 22, 2010 10:18 AM
Posted To: ntdev
Conversation: Communication between two drivers
Subject: RE: Communication between two drivers

> If you really cannot trust the intermediate drivers, then have the
> upper filter send an IRP_MN_QUERY_INTERFACE to the stack below it,
and
> then use the returned interface to hold the pointers to the
functions
> you need

I’m not sure how I can use IRP_MN_QUERY_INTERFACE to get the function
pointers. Can you elaborate or provide a sample which does use this
IRP.

__________ Information from ESET Smart Security, version of virus
signature
database 5050 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

11

> Convert the PDO pointer to string using RtlStringCchPrintf(“%p”) and use this string with some >prefix as a callback name.

I cannot use PDO pointer and prefix to callback name as the filter drivers are sitting in a USB mass storage stack.

I have disk upper filter and USBSTOR lower filter. So this may not be really possible.

12

xxxxx@hotmail.com wrote:

> If you really cannot trust the intermediate drivers, then have the upper filter send an
> IRP_MN_QUERY_INTERFACE to the stack below it, and then use the returned
> interface to hold the pointers to the functions you need
>

I’m not sure how I can use IRP_MN_QUERY_INTERFACE to get the function pointers. Can you elaborate or provide a sample which does use this IRP.

http://www.lmgtfy.com?q=IRP_MN_QUERY_INTERFACE

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

If his drivers are in 2 different pnp stacks, even though those stacks are in the same direct tree, I don’t think QI will work. There is no rule that the PDO must fwd unhandled QIs down the FDO stack, they typically fail at the PDO if unhandled.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 22, 2010 10:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Communication between two drivers

xxxxx@hotmail.com wrote:

> If you really cannot trust the intermediate drivers, then have the
> upper filter send an IRP_MN_QUERY_INTERFACE to the stack below it,
> and then use the returned interface to hold the pointers to the
> functions you need
>

I’m not sure how I can use IRP_MN_QUERY_INTERFACE to get the function pointers. Can you elaborate or provide a sample which does use this IRP.

http://www.lmgtfy.com?q=IRP_MN_QUERY_INTERFACE

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

14

> “function driver rules all” philosophy became obsolete with function drivers

That might be your philosophy, but that is not what we are telling driver developers and how msft develops its drivers.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, April 22, 2010 7:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Communication between two drivers

Actually the “function driver rules all” philosophy became obsolete with function drivers. So you pass down the IOCTL, if the PDO does not handle it the request will be failed in a lower driver exactly what your
function driver would have done in the past.

My view is that with proliferation of bus drivers and advanced stacks where making the Windows NT assumption of failing an IOCTL you don’t recognize is just creating problems.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Posted At: Thursday, April 22, 2010 9:54 AM Posted To: ntdev
Conversation: Communication between two drivers
Subject: RE: Communication between two drivers

Don Burn wrote:

> Why would the intermediate driver have been poorly written to block
> the request. The driver should in most cases assume that if it does
> not recognized the IOCTL it should be passed through.

A function driver should pass down IOCTLs that it doesn’t recognize?
Sorry, I
don’t think so. Why would it expect that the PDO representing the
hardware
would understand arbitrary IOCTL requests?

__________ Information from ESET Smart Security, version of virus
signature
database 5050 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

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

15

The OP stated they were upper and lower filters of the same function
driver.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: Doron Holan [mailto:xxxxx@microsoft.com]
Posted At: Thursday, April 22, 2010 1:35 PM
Posted To: ntdev
Conversation: Communication between two drivers
Subject: RE: Communication between two drivers

If his drivers are in 2 different pnp stacks, even though those stacks
are in
the same direct tree, I don’t think QI will work. There is no rule
that the
PDO must fwd unhandled QIs down the FDO stack, they typically fail at
the PDO
if unhandled.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-409030-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 22, 2010 10:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Communication between two drivers

xxxxx@hotmail.com wrote:
>> If you really cannot trust the intermediate drivers, then have the
>> upper filter send an IRP_MN_QUERY_INTERFACE to the stack below it,
>> and then use the returned interface to hold the pointers to the
>> functions you need
>>
>
> I’m not sure how I can use IRP_MN_QUERY_INTERFACE to get the
function
pointers. Can you elaborate or provide a sample which does use this
IRP.
>

http://www.lmgtfy.com?q=IRP_MN_QUERY_INTERFACE

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

__________ Information from ESET Smart Security, version of virus
signature
database 5051 (20100422) __________

The message was checked by ESET Smart Security.

http://www.eset.com

16

Doron Holan wrote:

If his drivers are in 2 different pnp stacks, even though those stacks are in the same direct tree, I don’t think QI will work. There is no rule that the PDO must fwd unhandled QIs down the FDO stack, they typically fail at the PDO if unhandled.

The key point, I think, is that he wants the upper filter in stack A to
talk to the lower filter in stack A, and specifically does NOT want the
upper filter in stack A to talk to the lower filter in stack B. As far
as I can tell, QI is the right solution.

I thought the rule was that ALL unhandled PnP IRPs have to be passed
down the stack. Driver Verifier enforces this, does it not?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

17

Don Burn wrote: > Why would the intermediate driver have been poorly written > to block the request. The driver should in most cases assume > that if it does not recognized the IOCTL it should be passed > through. A function driver should pass down IOCTLs that it doesn’t recognize? Sorry, I don’t think so.

To which Chris Aseltine wrote: Why would it expect that the PDO representing the hardware would understand arbitrary IOCTL requests?

I disagree with Chris, agree with Don; a filter driver should do just that: filter, peek, view but not interpret or process. A filter driver has no idea what might be below or above it, or what rev of driver(s) are above or below it. By interpreting or processing the IRP’s it takes away the ability of the lower level driver(s) to act on those IRPs, to say nothing of simply blocking things it doesn’t understand. There might be a custom IOCTL defined by the lower driver, the OS might have a new PnP message down the road or a new sequence to communicate things (such as PCI rebalancing) and by the filter taking on the role of either blocking or processing *any* IRP that it is not specifically designed to handle it’s just causing trouble down the road …

18

Sure, but (unless I misunderstand) the problem here is that the OP wants two filters to communicate – One ABOVE the FDO and one BELOW the FDO. So the OPs concern needn’t be the FILTERS blocking undefined IOCTLs but rather the driver for the FDO blocking them.

And the point is that you can’t really rely on the Function Driver passing arbitrary IOCTLs through. It could, a very tolerant Function Driver probably would, but I don’t think most Function Drivers can be expected to pass along IOCTLs they don’t understand.

Filters, of course, yes. But Function Drivers… not really.

Peter
OSR

19

Yes, filter drivers pass through stuff they don’t understand, esp IOCTLs, reads, writes. FDOs typically fail I/O they don’t understand unless there are existing rules that tell them to pass it down (like pnp, power, wmi). What don is saying is that FDOs should not fail I/Os they do not understand who do not have rules that say they must go down the stack.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of choward@ix.netcom.com
Sent: Thursday, April 22, 2010 11:25 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Communication between two drivers

Don Burn wrote: > Why would the intermediate driver have been poorly written > to block the request. The driver should in most cases assume > that if it does not recognized the IOCTL it should be passed > through. A function driver should pass down IOCTLs that it doesn’t recognize? Sorry, I don’t think so.

To which Chris Aseltine wrote: Why would it expect that the PDO representing the hardware would understand arbitrary IOCTL requests?

I disagree with Chris, agree with Don; a filter driver should do just that: filter, peek, view but not interpret or process. A filter driver has no idea what might be below or above it, or what rev of driver(s) are above or below it. By interpreting or processing the IRP’s it takes away the ability of the lower level driver(s) to act on those IRPs, to say nothing of simply blocking things it doesn’t understand. There might be a custom IOCTL defined by the lower driver, the OS might have a new PnP message down the road or a new sequence to communicate things (such as PCI rebalancing) and by the filter taking on the role of either blocking or processing *any* IRP that it is not specifically designed to handle it’s just causing trouble down the road …

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

20

Yes, for 2 filters in the same devnode, QI works. For 2 filters in the same device *tree* but at different levels in the tree, it does not.

I thought the rule was that ALL unhandled PnP IRPs have to be passed down the stack. Driver Verifier enforces this, does it not?
Yes, that is true, and passed down the stack typically ends at the PDO. When the PDO gets an irp it doesn’t understand, it completes it.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 22, 2010 11:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Communication between two drivers

Doron Holan wrote:

If his drivers are in 2 different pnp stacks, even though those stacks are in the same direct tree, I don’t think QI will work. There is no rule that the PDO must fwd unhandled QIs down the FDO stack, they typically fail at the PDO if unhandled.

The key point, I think, is that he wants the upper filter in stack A to talk to the lower filter in stack A, and specifically does NOT want the upper filter in stack A to talk to the lower filter in stack B. As far as I can tell, QI is the right solution.

I thought the rule was that ALL unhandled PnP IRPs have to be passed down the stack. Driver Verifier enforces this, does it not?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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