none
how to send custom ioctl to my lower filter driver directly from my metro app?

    Question

  •  hi,

    i have created a lower filter driver for my external usb keyboard. and i can send custom ioctl call from my desktop app directly to my filter driver by creating a controldevice for my filter driver using a symbolc i.e. a virtual device . use DeviceIoControl to send an ioctl to my filter driver which is a lower driver of usb/keyboard.

    in our desktop app, we are creating virtual device for the lower filter driver and then the desktop app talk to the lower filter driver directly

    but how the similar thing can be done in metro device app?i understand the createfile won't work in metro app. now if i do it through a metro device app,

    when i use device meta data to associate my keyboard device with my metro app using the hardware ID, how does my metro app knows it is talking to my lower filter driver or the class driver of the keyboard? will the ioctl being sent to my filter driver  be rejected before it reaches the filter driver?

    Now i want to do the same thing from my metro app. is that feasible at all? if yes, how?

    Monday, June 30, 2014 9:13 PM

Answers

  • Hello,

    As long as you are the HW manufacturer of the device being filtered then you can use the customer device access sample.  You may find that a sleek desktop app is the simpler and possible correct choice in this instance...

    Best Regards - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, July 02, 2014 5:35 PM
    Moderator
  • So in conclusion, this can't be done with the metro device app framework?it is not supported and not feasible,right?


    Hello,

    Windows Store Device Apps (WSDAs) have a 1:1 mapping with the hardware device.  Only the device manufacturer can write a WSDA. 

    Best Wishes - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.



    Correct.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 7:06 PM
    Moderator
  • I have re-read the entire thread and even though there are many correct statements and I do value all of the help you must be the manufacturer of the device to write a WSDA for the device.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 9:29 PM
    Moderator
  • Hi Eric,

    unfortunately we are not he manufacture of the USB device. We don't own the device, we only wrote the lower filter driver for the device to add one feature . The lower filter driver sit below the class driver. As I need to have a switch in my app to turn the feature on and off, my app needs to send that Ioctl call directly to the lower filter driver. We know that can be done for desktop app by creating a control device and a symbolic link in my filter driver , and desktop app use creat file API to  directly communicate with my lower filter driver. 

    So my question is: can this direct communication channel be set up between my metro app and the lower filter driver also to achieve the same thing? Is this feasible or  supported?

    Hello,

    As long as you are the HW manufacturer of the device being filtered then you can use the customer device access sample.  You may find that a sleek desktop app is the simpler and possible correct choice in this instance...

    Best Regards - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Hello,

    Windows Store Device Apps (WSDAs) have a 1:1 mapping with the hardware device.  Only the device manufacturer can write a WSDA. 

    Best Wishes - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 4:41 PM
    Moderator

All replies

  • The Custom device access sample supports IOCTLs however standard Metro style apps do not

    Please look into the following thread for more information:

    http://social.msdn.microsoft.com/Forums/en-US/a76a8860-fe68-4972-adf8-a2fe15a974c9/supported-ioctl-commands-in-metro-apps

    Monday, June 30, 2014 11:06 PM
    Moderator
  • thanks for your reply,RashmiA.

    i understand standard metro style app doesn't and we need to write metro device app.

    yes i have looked into that Custom device access sample and the thread as well. however, my keyboard is not a custom/specialized devices. the filter driver my metro device app wanted to talk to directly is a lower filter driver below my keyboard device driver. you can say it is a custom driver, but it is part of the keyboard driver stack, but it is not for custom device.

    i want to confirm whether this kind of access (i.e. from my metro device app to send custom ioctl to my keyboard lower filter driver directly) is supported or can be achieved in the current metro device app model/framework...if yes, how? if not ,why? please help

    Tuesday, July 01, 2014 5:15 PM
  • Hello,

    As long as you are the HW manufacturer of the device being filtered then you can use the customer device access sample.  You may find that a sleek desktop app is the simpler and possible correct choice in this instance...

    Best Regards - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, July 02, 2014 5:35 PM
    Moderator
  • Hi Eric,

    unfortunately we are not he manufacture of the USB device. We don't own the device, we only wrote the lower filter driver for the device to add one feature . The lower filter driver sit below the class driver. As I need to have a switch in my app to turn the feature on and off, my app needs to send that Ioctl call directly to the lower filter driver. We know that can be done for desktop app by creating a control device and a symbolic link in my filter driver , and desktop app use creat file API to  directly communicate with my lower filter driver. 

    So my question is: can this direct communication channel be set up between my metro app and the lower filter driver also to achieve the same thing? Is this feasible or  supported?

    Hello,

    As long as you are the HW manufacturer of the device being filtered then you can use the customer device access sample.  You may find that a sleek desktop app is the simpler and possible correct choice in this instance...

    Best Regards - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Thursday, July 03, 2014 4:45 AM
  • If you're writing a driver anyway, can't you write a satellite driver interface that can accept communication with metro apps, which internally communicates with the original keyboard filter driver?  I'd suspect the framework would be relatively easy to add to the existing driver and INF.  The toaster driver sample in the (old?) DDKs does this (sort of.)

    and/or

    Add a secondary way to receive IOCTLs from the driver, such as by a file using the Zw... file ops functions to read the control structure from a known file.

    and/or

    If you're already filtering keyboard, why not just use some form of keypress as a toggle.  For example, holding down a certain set of keys for an extended period.  This would skip the need for the other apps to control the features altogether.


    Darin R.

    Thursday, July 03, 2014 3:15 PM
  • Hi Eric,

    unfortunately we are not he manufacture of the USB device. We don't own the device, we only wrote the lower filter driver for the device to add one feature . The lower filter driver sit below the class driver. As I need to have a switch in my app to turn the feature on and off, my app needs to send that Ioctl call directly to the lower filter driver. We know that can be done for desktop app by creating a control device and a symbolic link in my filter driver , and desktop app use creat file API to  directly communicate with my lower filter driver. 

    So my question is: can this direct communication channel be set up between my metro app and the lower filter driver also to achieve the same thing? Is this feasible or  supported?

    Hello,

    As long as you are the HW manufacturer of the device being filtered then you can use the customer device access sample.  You may find that a sleek desktop app is the simpler and possible correct choice in this instance...

    Best Regards - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Hello,

    Windows Store Device Apps (WSDAs) have a 1:1 mapping with the hardware device.  Only the device manufacturer can write a WSDA. 

    Best Wishes - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 4:41 PM
    Moderator
  • So in conclusion, this can't be done with the metro device app framework?it is not supported and not feasible,right?


    Hello,

    Windows Store Device Apps (WSDAs) have a 1:1 mapping with the hardware device.  Only the device manufacturer can write a WSDA. 

    Best Wishes - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Thursday, July 03, 2014 5:27 PM
  • So in conclusion, this can't be done with the metro device app framework?it is not supported and not feasible,right?


    Hello,

    Windows Store Device Apps (WSDAs) have a 1:1 mapping with the hardware device.  Only the device manufacturer can write a WSDA. 

    Best Wishes - Eric


    This posting is provided "AS IS" with no warranties, and confers no rights.



    Correct.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 7:06 PM
    Moderator
  • By using filtering, you can change the identity of the USB device and then slap your app onto it.

    -- pa

    Thursday, July 03, 2014 8:37 PM
  • hi Darin,

    I really appreciate your suggestions.for your 3rd suggestion, in my scenario, i need to have the feature control from my app, don't want to use key combination to control it. for your 1st suggestion, are you talking about writing an upper filter driver that talks to my keyboard lower filter driver? how that can be done as i am not driver expert . if you can point me to an example, it will be very helpful.for 2nd point i don't quite understand what you mean "Add a secondary way to receive IOCTLs from the driver, such as by a file using the Zw... file ops functions to read the control structure from a known file." thanks

    ----------------------------------------------

    If you're writing a driver anyway, can't you write a satellite driver interface that can accept communication with metro apps, which internally communicates with the original keyboard filter driver?  I'd suspect the framework would be relatively easy to add to the existing driver and INF.  The toaster driver sample in the (old?) DDKs does this (sort of.)

    and/or

    Add a secondary way to receive IOCTLs from the driver, such as by a file using the Zw... file ops functions to read the control structure from a known file.

    and/or

    If you're already filtering keyboard, why not just use some form of keypress as a toggle.  For example, holding down a certain set of keys for an extended period.  This would skip the need for the other apps to control the features altogether.


    Darin R.


    Thursday, July 03, 2014 9:10 PM
  • I have re-read the entire thread and even though there are many correct statements and I do value all of the help you must be the manufacturer of the device to write a WSDA for the device.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 03, 2014 9:29 PM
    Moderator
  • Skip #1 - based on Eric's input. 

    #2 is basically communicating from the driver to a file.  You write the file, and the driver picks up the data, does the action.  And yes, a driver with a zwCreateFile is a not the best way to do this.

    Since you're already having to make a desktop installer to install the filter driver, why not start some service that does the IOCTL for you, then communicate with that service from the modern app using the file system as a transport?  Ie, write "DISABLE" to "KEYCTRL.BIN" in %temp% and the service will read the file change, read the file, setup the IOCTL, and away you go...

    Can you outline more about the filter and what it's for?


    Darin R.

    Thursday, July 03, 2014 9:40 PM
  • hi Darin,

    the filter is a lower filter driver for the keyboard that did some processing on the input from the keyboard. my objective is from any of my metro app i can turn on/off the feature to do that. i am aware device metro app is designed for device manufacture to control their device. although the keyboard is not mine, i have control on the lower filter driver which is part of the keyboard driver stack.

    besides the zwCreateFile method you suggested. is it feasible to let the custom device access  sample driver accept the ioctls and then invoke api in the filter driver?

    Skip #1 - based on Eric's input. 

    #2 is basically communicating from the driver to a file.  You write the file, and the driver picks up the data, does the action.  And yes, a driver with a zwCreateFile is a not the best way to do this.

    Since you're already having to make a desktop installer to install the filter driver, why not start some service that does the IOCTL for you, then communicate with that service from the modern app using the file system as a transport?  Ie, write "DISABLE" to "KEYCTRL.BIN" in %temp% and the service will read the file change, read the file, setup the IOCTL, and away you go...

    Can you outline more about the filter and what it's for?


    Darin R.


    Saturday, July 05, 2014 9:38 PM
  • I have re-read the entire thread and even though there are many correct statements and I do value all of the help you must be the manufacturer of the device to write a WSDA for the device.

    This posting is provided "AS IS" with no warranties, and confers no rights.


    Will it work if i create a device interface for the control device  in my lower filter driver, and allow metro app to connect to the device interface and send ioctl to it?
    Monday, July 07, 2014 10:37 PM
  • I have re-read the entire thread and even though there are many correct statements and I do value all of the help you must be the manufacturer of the device to write a WSDA for the device.


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Will it work if i create a device interface for the control device  in my lower filter driver, and allow metro app to connect to the device interface and send ioctl to it?
    A desktop application is the correct solution for your case.  For filter drivers you must be filtering a driver for which you are the manufacturer of the device to write a WSDA for the device.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, July 07, 2014 10:49 PM
    Moderator
  • I have re-read the entire thread and even though there are many correct statements and I do value all of the help you must be the manufacturer of the device to write a WSDA for the device.


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Will it work if i create a device interface for the control device  in my lower filter driver, and allow metro app to connect to the device interface and send ioctl to it?

    A desktop application is the correct solution for your case.  For filter drivers you must be filtering a driver for which you are the manufacturer of the device to write a WSDA for the device.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    having said this and i got it. one last quesiton, does microsoft have plan to extend the framework to support sending ioctl from WSDA to lower filter driver for a device we don't own because in some case we want this support for our product. i.e. achieve similar thing as what desktop app can do as noted in the following link: http://support.microsoft.com/kb/262305

    Monday, July 07, 2014 11:15 PM
  • I can take this as a feedback item.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 08, 2014 8:14 PM
    Moderator
  • I can take this as a feedback item.

    This posting is provided "AS IS" with no warranties, and confers no rightts

    can  metro application talk to driver for virtual device (or software device without real hardware behind it)? what i found with experiment is that the metro app even can't discover/enumerate the virtual device. i am very curious how the WinRT knows it is not a real hardware but a virtual one? what if i create a vid and pid for my virtual device. is the winRT API for metro app designed to refuse to connect/talk to virtual device?

    Tuesday, July 08, 2014 8:55 PM
  • Skip #1 - based on Eric's input. 

    #2 is basically communicating from the driver to a file.  You write the file, and the driver picks up the data, does the action.  And yes, a driver with a zwCreateFile is a not the best way to do this.

    Since you're already having to make a desktop installer to install the filter driver, why not start some service that does the IOCTL for you, then communicate with that service from the modern app using the file system as a transport?  Ie, write "DISABLE" to "KEYCTRL.BIN" in %temp% and the service will read the file change, read the file, setup the IOCTL, and away you go...

    Can you outline more about the filter and what it's for?


    Darin R.

    hi Darin, back to discussion on your option 2, i saw in this thread eric saying communication between Metro style apps and desktop apps is not allowed. if it is true, then option 2 doesn't work either?

    http://social.msdn.microsoft.com/Forums/windowsapps/en-US/6bdaa46f-fa49-4854-a97b-81b003ef3495/serial-port-access-for-metro-app

    Tuesday, July 08, 2014 9:23 PM
  • What would the IOCTL do?  Does it re-map a key or what is the end goal. 

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 08, 2014 9:35 PM
    Moderator
  • What would the IOCTL do?  Does it re-map a key or what is the end goal. 

    This posting is provided "AS IS" with no warranties, and confers no rights.


    a few ioctl defined in the filter driver, turn a mode on/off and also directly retrieve the keystrokes passed from driver stack sit below my filter driver
    Tuesday, July 08, 2014 9:47 PM
  • What would the IOCTL do?  Does it re-map a key or what is the end goal. 

    This posting is provided "AS IS" with no warranties, and confers no rights.

    how the WinRT knows it is not a real hardware but a virtual one? what if i create a fake vid and pid for my virtual device to make it pretend to be a real hardware as much as we can. is the winRT API for metro app designed to refuse to connect/talk to virtual device?
    Tuesday, July 08, 2014 9:53 PM
  • i saw in this thread eric saying communication between Metro style apps and desktop apps is not allowed. if it is true, then option 2 doesn't work either?

    Intel daydreamer meets MS daydreamers... Nice happening;)

    "Not allowed" here means that by design Metro apps live in security context that is not known to "desktop" app model, so the OS puts a lot of humps to prevent such communication.

    However, kernel drivers are not desktop applications. Being in kernel gives you unlimited power, so you even can circumvent isolation of Metro apps. Exactly for this reason, you cannot install custom drivers or any kernel stuff on WinRT OS without special clearance.

    --pa


    • Edited by Pavel A Tuesday, July 08, 2014 10:32 PM
    Tuesday, July 08, 2014 10:28 PM