locked
Metro style device app that talk to little firmware driver, which handle the call to WMI service that BIOS/ACPI provided ?

    Question

  • Hi :

    We got a little device on our mother board, attached to EC. We could control it through BIOS/WMI, and it working fine at Windows 7 or Windows 8 desktop mode. Now we need to access it at Metro Style Application.

    Did some research those days, I realize that "Metro Style Device App for specified device" seems to be the correct answer.

    However, even by read all those discussion from this forum, it still not clear :

    1. It does not support a software only driver - so if we go through the WMI service that we had before ( no device node at device manager ), it wont work ?

    2. Since the device we have is attached at motherboard, we need to grant permission to this driver in the PC metadata, how to do that ?

    3. Saw only two cases that device app could call into driver by device_io_control, they were all filter driver, it may not fit our requirement.

    4. If we has a WMI driver that attached to PNP0C14, then it should be able to show up at device manager, is this hardware id could accept by Metro Style Device App ?

    regards

    Neo Wong


    • Edited by Neo Wong Monday, March 26, 2012 4:50 PM
    Monday, March 26, 2012 4:49 PM

Answers

  • Neo,

    Your desktop app will work fine.  WMI is not supported in Metro style apps.  There will be more information about devices attached to motherboards soon.  I will post here when it is available.

    Best Wishes - Eric

    Monday, March 26, 2012 6:11 PM
    Moderator

All replies

  • Neo,

    Your desktop app will work fine.  WMI is not supported in Metro style apps.  There will be more information about devices attached to motherboards soon.  I will post here when it is available.

    Best Wishes - Eric

    Monday, March 26, 2012 6:11 PM
    Moderator
  • I'm fighting with this now as well. 

    Specifically, exactly how to properly configure the INF & Metadata to identify the driver as "Software-Only"

    While this will be part of the OEM, I will also need to understand exactly how to "re-install" should the user fresh install where the OEM image isn't available.  i.e. the driver won't be downloaded from MS, but provided via provider.

    The other question I would add it with respect to the "Privileged Properties".  I've seen conflicting examples stating we need to add:

    {14c83c99-0b3f-44b7-be4c-a178d3990564}, 3, 17, , 1

    and in OTHER samples from MS:

    {026e5163-b814-414b-83cd-856d6fef4822}, 6, 17, , 1

    Which is the right on?

    Irrespective, I've tried to add both and when I dump the properties for all items (via PnP Properties enumeration) I am showing in some cases the {14c83....<etc>} property is returning a string value and in other cases it is returning the expected Boolean value.  Something seems amiss.  Perhaps the {14c83....<etc>} is completely invalid now?  Am I missing something?

    If you couple provide a reference to a sample .INF and Driver Metadata (i.e. *devicemetadata-ms) that would be of GREAT help.

    Any idea of how long until this is supported / information is available? 

    Wednesday, March 28, 2012 2:47 AM
  • fsleeper,

    For the details on metadata please see this document: 

    http://msdn.microsoft.com/en-us/library/windows/hardware/br259108.aspx

    link to sample:

    http://code.msdn.microsoft.com/windowsapps/Custom-device-access-sample-43bde679

    For the internal device:

    We are working on documentation to address that scenario, that we aim to post soon.

    Best Wishes - Eric


    Wednesday, March 28, 2012 7:30 AM
    Moderator
  • Thanks for the response Eric!

    Also, thanks for the links.  I've reviewed a wealth of material and many of your related posts.  On one of your posts in January you stated that IOCTL calls to Kernel Mode Software-Only drivers in Metro is not supported.  Given the above, can you confirm whether Software-Only driver calls are now supported in Metro? (i.e. there is not event that a device was added / possibly no Hardware ID)

    Specifically, our scenario is we need to access items, such as Asset Tag / Motherboard Serial Number, etc. within the Metro app.  Per  recent conversation with MS, we need a Kernel Mode Software-Only driver to meet this need.

    The points of confusion are:

    > The *devicemetadata-ms requires a Hardware ID. As it's Software-Only, there isn't a Hardware ID. 

    > As noted above, since this is a specialized driver, an entry is required in the INF ("Privileged Properties"). I'm finding conflicts between documentation regarding exactly what GUID to use. {14c83c99-0b3f-44b7-be4c-a178d3990564}, 3, 17, , 1 or {026e5163-b814-414b-83cd-856d6fef4822}, 6, 17, , 1.  I assume the later, but interestingly there "appears" to be a conflict in that when I run a PnpObject.FindAllAsync(), adding this property GUID/PID to the requested properties collection the value is being returned as Boolean (good) for my INF, but other MS provided objects return this property as a string (actually, they are returning the System.ItemNameDisplay which has a property GUID/PID of {B725F130-47EF-101A-A5F1-02608C9EEBAC}, 10 

    Any thoughts on the above?  I am able to call my driver in Desktop just fine, but Metro continually fails on the DeviceIOControlSync call. (Using VS Debugger to push the driver to the remote box).  The Driver / App is configured with a *devicemetadata-ms that identifies the Metro app as Privileged, the INF contains the Privileged property, the driver is signed and the Metro app Capabilities has an entry for the driver class GUID.  Been fighting this for a week and would KILL for a simple End-to-End sample (i.e. KMDF Software-Only Driver that is called by a Metro App)

    Wednesday, March 28, 2012 6:10 PM
  • fsleeper,

    We are working on documentation to address that scenario, that we aim to post soon. 

    Best Wishes - Eric

    Thursday, March 29, 2012 1:51 AM
    Moderator
  • Eric,

    Is there any update on documentation for Metro Apps communicating with KMDF software-only drivers?

    Thanks

    Friday, October 12, 2012 4:32 PM
  • Do you have a device or no device?  I ask because some drivers seem software only but have a device. 

    Best Wises - Eric

    Friday, October 12, 2012 5:40 PM
    Moderator
  • Hi Eric, 

    Yes, I do have a device/hardware ID.  I assume that's all that matters?

    Thanks

    Tuesday, October 16, 2012 12:01 AM
  • Once the driver loads what device does it control and communicate with?

    Tuesday, October 16, 2012 12:21 AM
    Moderator
  • Hi Eric,

    The driver is for an ACPI device that we added in the BIOS.  Is there any update on documentation regarding communicating between Windows Store Apps and internal, non-removable devices?

    Thanks

    Friday, November 2, 2012 3:44 PM
  • What does the ACPI device added in the BIOS do?

    Monday, November 5, 2012 9:59 PM
    Moderator
  • Hi Eric,

    It's part of a power and thermal management framework.  It communicates with other drivers that we write to do so.  The idea is to report telemetry such as temperature, etc in a Windows Store App and/or send commands to the driver to do some controlling.  

    I'm not sure why what the driver does matters though in this context?  Either a Windows Store app can communicate with a non removable device driver or it can't right?

    Thanks.

    Monday, November 5, 2012 10:19 PM
  • The reason for the questions is that the ACPI BIOS entry needs to do something more than cause the load of a software only driver.
    Monday, November 5, 2012 10:25 PM
    Moderator
  • Hi Eric,

    Okay, makes sense; the driver does do something.

    So, back to the question at hand: how do I communicate between a Windows Store App and a non-removable device driver if device metadata is only for removable devices? 

    Thanks

    Monday, November 5, 2012 10:34 PM
  • Just realized I was accidently signed in with another account.  This post is to confirm that I am also pumaDevastation and would appreciate an answer to my question.  Thanks!
    Tuesday, November 6, 2012 12:28 AM