Driver-driver communication across different device stacks

OSR_Community_User · February 24, 2015, 9:23pm

Hi, newbie here on windows driver development. I’m trying to make two kernel mode drivers talk to each other, one is a root-enumerated virtual HID device (VMulti project (which I can modify), https://code.google.com/p/vmulti/), and another is a filter to an HID-enumerated PDO. Since both are using KMDF, I’m trying to use driver-defined interfaces (https://msdn.microsoft.com/en-us/library/windows/hardware/ff545436(v=vs.85).aspx) so that the filter can call a routine from VMulti. I have several questions, but please let me start with these few:

From what I’ve read and seen in the MSDN doc and the Toaster sample, I plan to set up the interface inside VMulti (the root-enumerated device), so that the filter can query for the interface, get a function pointer to a routine internal to VMulti, and so pass some data to VMulti through calling that function. First, how good is this idea? Second, where exactly should I set up the interface? Inside EvtDeviceAdd or someplace else?

Thanks, this forum has been a lot of help on my journey of learning about Windows drivers so far.

anand_sunku · February 24, 2015, 10:03pm

Yeah you are right you should place it in add device
On Feb 25, 2015 7:53 AM, wrote:

> Hi, newbie here on windows driver development. I’m trying to make two
> kernel mode drivers talk to each other, one is a root-enumerated virtual
> HID device (VMulti project (which I can modify),
> https://code.google.com/p/vmulti/), and another is a filter to an
> HID-enumerated PDO. Since both are using KMDF, I’m trying to use
> driver-defined interfaces (
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff545436(v=vs.85).aspx)
> so that the filter can call a routine from VMulti. I have several
> questions, but please let me start with these few:
>
> From what I’ve read and seen in the MSDN doc and the Toaster sample, I
> plan to set up the interface inside VMulti (the root-enumerated device), so
> that the filter can query for the interface, get a function pointer to a
> routine internal to VMulti, and so pass some data to VMulti through calling
> that function. First, how good is this idea? Second, where exactly should I
> set up the interface? Inside EvtDeviceAdd or someplace else?
>
> Thanks, this forum has been a lot of help on my journey of learning about
> Windows drivers so far.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

Doron_Holan · February 24, 2015, 10:08pm

You can’t open a handle to the hid miniport without further changes to the miniport. Hidclass blocks the creation of the handle. To get around this you either create a control device or report an additional tlc which you can open. Since you can change both drivers, why not have one driver fulfill both roles? This way you don’t need to go through a file handle to find the other.

d

Bent from my phone

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?2/?24/?2015 6:22 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Driver-driver communication across different device stacks

Hi, newbie here on windows driver development. I’m trying to make two kernel mode drivers talk to each other, one is a root-enumerated virtual HID device (VMulti project (which I can modify), https://code.google.com/p/vmulti/), and another is a filter to an HID-enumerated PDO. Since both are using KMDF, I’m trying to use driver-defined interfaces (https://msdn.microsoft.com/en-us/library/windows/hardware/ff545436(v=vs.85).aspx) so that the filter can call a routine from VMulti. I have several questions, but please let me start with these few:

From what I’ve read and seen in the MSDN doc and the Toaster sample, I plan to set up the interface inside VMulti (the root-enumerated device), so that the filter can query for the interface, get a function pointer to a routine internal to VMulti, and so pass some data to VMulti through calling that function. First, how good is this idea? Second, where exactly should I set up the interface? Inside EvtDeviceAdd or someplace else?

Thanks, this forum has been a lot of help on my journey of learning about Windows drivers so far.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · February 25, 2015, 5:58pm

Hmm, since I’m still in the planning stages of this next step anyway, please let me try to explore your suggestion of having one driver fulfill both roles.

If I understand you correctly, am I right in saying that I can take my filter driver and then have it either create a control device or report an additional TLC?
I’m leaning more towards the option of reporting an additional TLC. In the end, will this accomplish the same thing as communicating with VMulti to generate input from different virtual pointers (mouse, touch, joystick, etc?)

Doron_Holan · February 25, 2015, 9:25pm

The hid miniport needs to expose the cdo or additional tlc. The hid filter just needs to open it, no additional devices need to be created in the filter

d

Bent from my phone

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?2/?25/?2015 2:58 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Driver-driver communication across different device stacks

Hmm, since I’m still in the planning stages of this next step anyway, please let me try to explore your suggestion of having one driver fulfill both roles.

1) If I understand you correctly, am I right in saying that I can take my filter driver and then have it either create a control device or report an additional TLC?
2) I’m leaning more towards the option of reporting an additional TLC. In the end, will this accomplish the same thing as communicating with VMulti to generate input from different virtual pointers (mouse, touch, joystick, etc?)

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · February 28, 2015, 11:40pm

Would this method work even though my device tree looks like this?

VMulti branch:
Root > VMulti > HID-compliant pen, digitizer, etc
*Note: the VMulti project includes

HID Filter branch:
Root > ACPI > … > USB Root Hub > … > Wacom Tablet > HID-compliant pen (whose device stack looks like this from top to bottom: MyHidFilter, hidkmdf).

Basically I’m trying to make MyFilter and VMulti communicate.

OSR_Community_User · March 4, 2015, 12:38pm

So I’ve been looking around the MSDN docs and found code within the Toaster Example that uses WdfFdoQueryForInterface. I have a few questions:

WdfFdoQueryForInterface is for two drivers that are in the same driver stack. However, there is another method, WdfIoTargetQueryForInterface, which is supposed to work across different driver stacks. This seems to be a good way to go for the scenario that I illustrated in my previous post (where I’m trying to make MyHidFilter call methods from VMulti), but I’m confused on how to provide the IoTarget parameter of WdfIoTargetQueryForInterface. As far as I’ve read and experienced, WdfIoTargetCreate’s Device parameter is the WDFDEVICE of the calling driver, not the remote driver. How then can I provide the remote IoTarget for WdfIoTargetQueryForInterface?
Doron’s suggestions seem like an alternative way of doing this without using query interfaces, but I’m still confused if that will work for the scenario I have in my previous post? It seems to me that that could only work if the HID filter is on the same driver stack as the driver that the filter wants to communicate to.

Again, by “communication”, I mean here that the HID filter could call methods from the other driver. The reason I’m doing this is to avoid redoing the functionality that VMulti already provides (generating virtual HID input).

Thanks in advance for any comments on this!

Doron_Holan · March 4, 2015, 1:05pm

The wdfdevice you pass to WdfIoTargetCreate is your own. The remote part of the Io target is the device name you pass to WdfIoTargetOpen. This is the name of the remote device you want to communicate with. This is usually a device interface. Once you have the name and open a handle/target to it, whether you use QI or Io requests is up you.

d

Bent from my phone

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?3/?4/?2015 9:38 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Driver-driver communication across different device stacks

So I’ve been looking around the MSDN docs and found code within the Toaster Example that uses WdfFdoQueryForInterface. I have a few questions:

1. WdfFdoQueryForInterface is for two drivers that are in the same driver stack. However, there is another method, WdfIoTargetQueryForInterface, which is supposed to work across different driver stacks. This seems to be a good way to go for the scenario that I illustrated in my previous post (where I’m trying to make MyHidFilter call methods from VMulti), but I’m confused on how to provide the IoTarget parameter of WdfIoTargetQueryForInterface. As far as I’ve read and experienced, WdfIoTargetCreate’s Device parameter is the WDFDEVICE of the calling driver, not the remote driver. How then can I provide the remote IoTarget for WdfIoTargetQueryForInterface?

2. Doron’s suggestions seem like an alternative way of doing this without using query interfaces, but I’m still confused if that will work for the scenario I have in my previous post? It seems to me that that could only work if the HID filter is on the same driver stack as the driver that the filter wants to communicate to.

Again, by “communication”, I mean here that the HID filter could call methods from the other driver. The reason I’m doing this is to avoid redoing the functionality that VMulti already provides (generating virtual HID input).

Thanks in advance for any comments on this!

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

Scott_Noone_OSR · March 4, 2015, 2:42pm

In case it helps, we covered using Bus Interfaces for driver to driver
communication in a previous article from The NT Insider:

“Using Bus Interfaces for Driver to Driver Communication”

https://www.osr.com/nt-insider/2014-issue2/using-bus-interfaces-driver-driver-communication/

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

So I’ve been looking around the MSDN docs and found code within the Toaster
Example that uses WdfFdoQueryForInterface. I have a few questions:

WdfFdoQueryForInterface is for two drivers that are in the same driver
stack. However, there is another method, WdfIoTargetQueryForInterface, which
is supposed to work across different driver stacks. This seems to be a good
way to go for the scenario that I illustrated in my previous post (where I’m
trying to make MyHidFilter call methods from VMulti), but I’m confused on
how to provide the IoTarget parameter of WdfIoTargetQueryForInterface. As
far as I’ve read and experienced, WdfIoTargetCreate’s Device parameter is
the WDFDEVICE of the calling driver, not the remote driver. How then can I
provide the remote IoTarget for WdfIoTargetQueryForInterface?
Doron’s suggestions seem like an alternative way of doing this without
using query interfaces, but I’m still confused if that will work for the
scenario I have in my previous post? It seems to me that that could only
work if the HID filter is on the same driver stack as the driver that the
filter wants to communicate to.

Again, by “communication”, I mean here that the HID filter could call
methods from the other driver. The reason I’m doing this is to avoid redoing
the functionality that VMulti already provides (generating virtual HID
input).

Thanks in advance for any comments on this!

OSR_Community_User · March 5, 2015, 7:55pm

Thank you very much to both of you! Those responses are very helpful.

By the way, what’s the best way to get another driver’s device interface from another KMDF driver? I’ve come across IoGetDeviceInterfaces() in several MSDN docs, but I realize that this is a WDM call and thought maybe there’s a better way?

Doron_Holan · March 5, 2015, 8:23pm

IoGetDeviceInterfaces and IoRegisterPlugPlayNotification

d

Bent from my phone

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?3/?5/?2015 4:54 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Driver-driver communication across different device stacks

Thank you very much to both of you! Those responses are very helpful.

By the way, what’s the best way to get another driver’s device interface from another KMDF driver? I’ve come across IoGetDeviceInterfaces() in several MSDN docs, but I realize that this is a WDM call and thought maybe there’s a better way?

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · March 5, 2015, 9:00pm

Ah, so the WDM calls are my best bet for this situation huh… I’ll go ahead and use that then. Thank you very much!

OSR_Community_User · March 9, 2015, 2:02pm

By the way, what’s the difference between IoGetDeviceInterfaces() and WdfDeviceRetrieveDeviceInterfaceString()?

Thanks!

Doron_Holan · March 9, 2015, 2:12pm

The first returns all instances (which are strings) of the device interface in question. The second returns the string for the instance of the device interface your driver created (and only that instance)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, March 9, 2015 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver-driver communication across different device stacks

By the way, what’s the difference between IoGetDeviceInterfaces() and WdfDeviceRetrieveDeviceInterfaceString()?

Thanks!

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

OSR_Community_User · March 13, 2015, 5:35pm

Thanks so much! I’m able to get the symbolic link string of VMulti now. However, I have a new problem.

WdfIoTargetOpen() fails and returns 0xc0000034, STATUS_OBJECT_NAME_NOT_FOUND.

Moreover, when I try to do IoSetDeviceInterfaceState() on the symbolic link string that I get (which I can only get with the DEVICE_INTERFACE_INCLUDE_NONACTIVE flag on, by the way), it also fails and returns 0xc0000010, STATUS_INVALID_DEVICE_REQUEST.

Any ideas on this issue?

Tim_Roberts · March 13, 2015, 5:42pm

xxxxx@gmail.com wrote:

Thanks so much! I’m able to get the symbolic link string of VMulti now. However, I have a new problem.

WdfIoTargetOpen() fails and returns 0xc0000034, STATUS_OBJECT_NAME_NOT_FOUND.

How did you get the symbolic link string of VMulti?

Moreover, when I try to do IoSetDeviceInterfaceState() on the symbolic link string that I get (which I can only get with the DEVICE_INTERFACE_INCLUDE_NONACTIVE flag on, by the way), it also fails and returns 0xc0000010, STATUS_INVALID_DEVICE_REQUEST.

Any ideas on this issue?

IoSetDeviceInterfaceState can only be called by the OWNER of the device
interface – by the driver that created it. You cannot force someone
else’s interface to be enabled.

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

Maxim_S_Shatskih · March 14, 2015, 4:39am

> IoSetDeviceInterfaceState can only be called by the OWNER of the device

And yes, this path is already implemented by KMDF.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · March 14, 2015, 5:19pm

Thanks Tim and Maxim for clarifying things about IoSetDeviceInterfaceState().

Tim, here’s the relevant code that I think will be useful to be brief. Please let me know if you think you need to see more (I removed the status checks here for brevity):

PWSTR symbolicLinkList;
status = IoGetDeviceInterfaces(
&GUID_DEVINTERFACE_HID,
NULL,
DEVICE_INTERFACE_INCLUDE_NONACTIVE,
&symbolicLinkList
);

UNICODE_STRING vmultiDeviceName;
RtlInitUnicodeString(&vmultiDeviceName, (PCWSTR)symbolicLinkList); // the symbolic link list has 2 entries at this point, which are identical. I might as well use the first entry

WDFIOTARGET vmultiTarget;
vmultiTarget = NULL;
status = WdfIoTargetCreate(device,
WDF_NO_OBJECT_ATTRIBUTES,
&vmultiTarget
);

WDF_IO_TARGET_OPEN_PARAMS openParams;
WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(
&openParams,
&vmultiDeviceName,
STANDARD_RIGHTS_ALL);

status = WdfIoTargetOpen(vmultiTarget, &openParams); // fails, returns 0xc0000034, STATUS_OBJECT_NAME_NOT_FOUND

Doron_Holan · March 14, 2015, 5:59pm

You only want active interface instances, you can’t open an inactive onr

d

Bent from my phone

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?3/?14/?2015 2:18 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Driver-driver communication across different device stacks

Thanks Tim and Maxim for clarifying things about IoSetDeviceInterfaceState().

Tim, here’s the relevant code that I think will be useful to be brief. Please let me know if you think you need to see more (I removed the status checks here for brevity):

PWSTR symbolicLinkList;
status = IoGetDeviceInterfaces(
&GUID_DEVINTERFACE_HID,
NULL,
DEVICE_INTERFACE_INCLUDE_NONACTIVE,
&symbolicLinkList
);

UNICODE_STRING vmultiDeviceName;
RtlInitUnicodeString(&vmultiDeviceName, (PCWSTR)symbolicLinkList); // the symbolic link list has 2 entries at this point, which are identical. I might as well use the first entry

WDFIOTARGET vmultiTarget;
vmultiTarget = NULL;
status = WdfIoTargetCreate(device,
WDF_NO_OBJECT_ATTRIBUTES,
&vmultiTarget
);

WDF_IO_TARGET_OPEN_PARAMS openParams;
WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(
&openParams,
&vmultiDeviceName,
STANDARD_RIGHTS_ALL);

status = WdfIoTargetOpen(vmultiTarget, &openParams); // fails, returns 0xc0000034, STATUS_OBJECT_NAME_NOT_FOUND

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

OSR_Community_User · March 23, 2015, 11:42am

Thanks all! Those were very helpful. Now then, if I understand Maxim correctly, KMDF enables the device interface by default. However, VMulti only shows up when the DEVICE_INTERFACE_INCLUDE_NONACTIVE flag is set. I’m guessing that somewhere in VMulti, there is some code that makes the device interface inactive? Looking over it, I don’t see any calls to IoSetDeviceInterfaceState anywhere in the code. Or are there any other possible reasons why it is inactive?

Thanks