locked
Accessing a non-removable specialized device from a metro app

    Question

  • I am having issues accessing a non-removable specialized device from a metro app. The device is a chipset on the PCB and has a custom device driver to interact with the chipset's FW. The device is thus not removable and does not show up in the 'Devices and Printers' user interface. 
    Following information presented in the build presentation on a related topic (http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-747T) and the MoFx2App sample app I'm trying to write a winrt component that would instantiate the device via CreateDeviceAccessInstance and then make IDeviceIoControl calls to the driver.  
    Here's the process I used to enable privileged access to the custom device:
    * Had the device interface GUID listed in the metro app manifest's Capabilities section.
      <Capabilities>
        <DeviceCapability Name="<device interface GUID>"/>
      </Capabilities>
    * created a devicemetadata package for the device with hardware id specified, hardware id was read from the Device Manager entry for the device. I used the metadata wizard in wdk 8.0 dev preview for this. Entered the metro app package name and publisher name under the Privileged Applications section. Did not specify a default application since there were none.
    * Had the resulting package copied to the devicemetadata store. 
    * updated the driver inf file to register the device interface class as privileged (used the OSRUSBFX2 sample inf file as example):
      [XXXX_Interface_AddProperty]
      {026e516e-b814-414b-83cd-856d6fef4822},6,0x11,,1 ; Privileged Interface
    * reinstalled the driver with the updated inf
    * rebooted the machine
    Even with all the above steps I am still getting E_AccessDenied when trying to open the device and get the iDeviceIoControl interface. I used the diagnoseConnectionError function from the MoFx2App sample app to check if the app specified in the devicemetadata package gets listed, none did. It's almost like the metadata package is not getting associated with the device at all.
    This leads to 2 questions to begin with:
    1) Am I missing any steps above to enable the winrt component to access the device driver?
    2) Is it possible to have a devicemetadata package associated with a non removable device like the chipset I am trying to access? This device will never show up in the 'Devices and Printers' window and is listed under the 'System devices' section in the Device Manager. How is the DMRC launched for such devices for making device->metadata association?

    • Edited by rdghosh Monday, December 05, 2011 5:19 PM
    Friday, December 02, 2011 10:23 PM

Answers

All replies

  • rdghosh,

     

    I will look into this for you.

     

    Best Wishes - Eric

    Tuesday, December 06, 2011 10:05 PM
    Moderator
  • Please try hitting F5 to refresh 'Device and Printers' container


    Also when you get access denied please check the following,
      
     
    1. Ensure that the driver inf has the property key set to enable access to metro applications. Look at the OSRUSBFX2 sample INF for information on how to set this property key.
     
    2. The device metadata has been authored for the device and it has been loaded into the system.
     
    3. The device metadata has the right information notably the PrivilegedApplications section
     
    4. The application manifest as the interface guid declared as a DeviceCapability

    Tuesday, December 06, 2011 10:17 PM
    Moderator
  • Thanks for the info Eric. I had started my experiment from the MoFx2App sample application and did follow the pointers you provided.
    Driver inf was updated and it was reinstalled. Did install the devicemetadata package as well. In general I followed the steps suggested by Nar at the end of blog entry http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-747T as described in my first post.

    My concern is now more with the type of device I am trying to interact with. The device falls under the 'System Devices' catagory in device manager and is a chipset on the PCB. As such it is not removable and does not show up under 'Devices and Printers'. The container id is the default "{00000000-0000-0000-ffff-ffffffffffff}". I am wondering if this is where the issue is. From what I can see in the MoFx2App code, the containerId is being used to query the device about its metadata. Do you think this is going to be an issue with my device?
    The question then becomes, can a metro style device app talk to such a device?
    And, is it possible to have a devicemetadata package associated such a device? This device will never show up in the 'Devices and Printers' window and is listed under the 'System devices' section in the Device Manager. How is the DMRC launched for such devices for making device->metadata association?
    If there's any changes that need to be made to the driver to make it compatible with metro style device apps, can you please provide some pointers?

    Thanks,
    Rahul

    Wednesday, December 07, 2011 9:40 PM
  • Rahul,

    We will publish additional information around the Consumer Preview concerning Custom Driver Access for a hardware component that ships preinstalled as part of a new PC.

    Best Wishes - Eric




    Friday, December 09, 2011 11:51 PM
    Moderator
  • That is good news. 

    Does this mean that the current Win8 dev preview release does not support this capability and there's going to be some updates made in the beta version for this? 
    Looks like beta is going to be out in late Feb'12. Can't help but make a request, any chance we get a patch for this earlier? I am assuming there's no harm in asking :-)

    Thanks a lot for your help,
    Rahul

    Monday, December 12, 2011 7:43 PM
  • You are welcome Rahul. 

    Thanks for your request.  I will pass it along.

    Best Wishes - Eric

     

    Monday, December 12, 2011 9:17 PM
    Moderator
  • Hi Eric,

    >2. The device metadata has been authored for the device and it has been loaded into the system.

    Can you tell me how to load the metadata? Sorry for my plain question.

     

    Thanks a lot.

    Saturday, January 28, 2012 7:42 AM
  • Hi Eric,

    >2. The device metadata has been authored for the device and it has been loaded into the system.

    Can you tell me how to load the metadata? Sorry for my plain question.

     

    Thanks a lot.

    Hi Carl Bao,

    If you follow http://social.msdn.microsoft.com/Forums/en-PH/tailoringappsfordevices/thread/47bbd3cb-7dfc-4846-b909-7ea0358236f2 the metadata will be automatically loaded into your system.

    Monday, February 27, 2012 4:04 AM
  • Hi Eric,

    Since consumer preview is only a day away is the information regarding custom driver access for internal devices, that come pre-installed as part of the PC, now available?
    I am specifically looking for information related to devices that are directly associated with the PC container and typically do not have devicemetadata associated with them. Mr Max Morris had mentioned this scenario in BUILD presentation HW-275T (around time mark 56:20) with an onboard fingerprint reader as example but no specifics were provided. He did mention though that WinRT will support such devices. I am hopeful some more information on accessing such devices from a metro style app will now be available.

    Thanks for your help,
    Rahul


    Rahul Ghosh

    Tuesday, February 28, 2012 1:29 AM
  • Rahul,

    The current plan is to have the information available two weeks post Comsumer Preview.

    Best Wishes - Eric

    Tuesday, February 28, 2012 4:23 AM
    Moderator
  • Eric,
       I appreciate your quick response. This is discouraging though. After all this waiting for beta now we are being asked to wait post-beta. If the information regarding internal device support is not formally in print can we at least get some unofficial info on how Microsoft is planning to support this? An informal white paper would be better than nothing and would greatly help us finalize our metro architecture which is already way delayed at this point.
       Judging from other blog entries, I am sure there's many others who are waiting for data on this same issue and would also benefit from this information. Your help will be very much appreciated here. 

    Thanks,
    Rahul 


    Rahul Ghosh

    Tuesday, February 28, 2012 6:24 AM
  • Rahul,

    Thank you.  I understand your desire to have the information as soon as possible.  I will post to the forum should the information be available sooner.

    Best Wishes - Eric

    Tuesday, February 28, 2012 6:53 PM
    Moderator
  • Hi Eric,

    The windows 8 consumer perview had been released already.

    Is there any solution can solve this problem?

    Thanks


    • Edited by Mike_Wu Friday, March 02, 2012 12:17 PM
    Friday, March 02, 2012 11:20 AM
  • Hi Eric,

    The windows 8 consumer perview had been released already.

    Is there any solution can solve this problem?

    Thanks


    Mike,

    The current plan is to have the information available two weeks post Comsumer Preview.

    Best Wishes - Eric

    Friday, March 02, 2012 7:12 PM
    Moderator
  • Can you at least confirm that this is a supported scenario in Windows 8?
    Thursday, March 08, 2012 6:36 PM
  • Can you at least confirm that this is a supported scenario in Windows 8?

    The current plan is to have the information available two weeks post Consumer Preview.

    Thursday, March 08, 2012 6:43 PM
    Moderator
  • You didn't answer my question.  Is this a supported scenario in Windows 8?

    People have been waiting for 3 months to get some answers from you on this, and it would be extremely frustrating if you come back next week and say that this is not supported.

    Thursday, March 08, 2012 7:24 PM
  • The metadata for chipset devices are bound to the PC and thus controlled by the OEM.  Metro style Device Apps can access chipset devices only if access permission is granted by the OEM in the PC metadata. 


    Friday, March 09, 2012 2:39 AM
    Moderator
  • Eric,  What is this PC metadata? Is this a special pre-existing metadata package that we can update?
    The information we need is the location of the PC metadata in the system and how to update it to allow PC bound device access from metro style apps.

    Rahul


    Rahul Ghosh

    Friday, March 09, 2012 5:38 AM
  • Rahul,

    Take a look at: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552325(v=vs.85).aspx  I think you'll find it helpful.

    Best regards, Mateusz

    Friday, March 09, 2012 7:26 AM
  • Thanks Mateusz. This is very good info. Looks like PC devicemetadata would need to be generated with one of the HWIDs produced by the ComputerHardwareIDs.exe tool. Need to try this out with VS11's devicemetadata wizard.

    Eric, can you please confirm if we would still require the PC metadata to list specific metro app id-s for access? 
    Given that the PC metadata is likely not meant to be updated frequently having that requirement will make it diffucult, if not impossible, for new apps to be able to access the PC bound device.  



    Rahul Ghosh

    Friday, March 09, 2012 8:15 AM
  • Rahul,

    You are correct.  Metro style Device Apps can access chipset devices only if access permission is granted by the OEM in the PC metadata. 

    Best Wishes - Eric

    Friday, March 09, 2012 9:50 PM
    Moderator
  • Eric, it's still not completely clear to me. How's this permission granted? via metro app ID (which is different for each app) or is there a generic way to allow all apps to be able to talk to an internal device?

    Rahul


    Rahul Ghosh

    Friday, March 09, 2012 10:51 PM
  • Hi Eric,
                 as today marks the two week point since consumer preview was released, any news of the white paper on internal device access from a metro app?

    Rahul


    Rahul Ghosh

    Wednesday, March 14, 2012 5:53 PM
  • Rahul,

    I will post an updated ETA for the whitepaper soon.

    Thursday, March 15, 2012 3:00 AM
    Moderator
  • Eric, it's still not completely clear to me. How's this permission granted? via metro app ID (which is different for each app) or is there a generic way to allow all apps to be able to talk to an internal device?

    Rahul


    Rahul Ghosh

    For specialized devices (devices with IOCTL interfaces) it is by App ID.
    Thursday, March 15, 2012 3:03 AM
    Moderator
  • Hi Eric,

    All the internal devices would be part of a PC container. From your post it seems that we will have a PC devicemetadata associated with a PC container in order to give privileges to the Metro-style applications. This PC devicemetadata needs to be updated to specify AppID of allowed applications. However, internal devices would be manufactured by multiple companies. Who will own the task of updating this PC devicemetadata to provide access rights?

    The change made in the PC devicemetadata container for a particular device may reflect throughout the system. Wouldn’t this method give privileges to the application which IHV has not intended?

    As there may be a single PC devicemetadata container for the all internal devices, what would be the upper-bound on the number of applications allowed to be specified in the PC devicemedata privileged application list?

    Please consider our request to publish more documetation on handilng internal devices ASAP. This document would help us in answering above questions.

    Thanks

    Thursday, March 15, 2012 2:22 PM
  • Eric, what is the status on this white paper?  Why is there a delay?
    Monday, March 19, 2012 7:56 PM
  • The OEM owns the metadata.  The OEM owns the decision about which apps can access devices internal to the PC.

    If the IHV has a metro style device app that they want on a user’s start screen, they need to convince their OEMs to include their app.  And since the number of apps the OEM can include is limited they’ll need to convince the OEM that there’s value in having their app over some other IHV’s app for their device.


    Tuesday, March 20, 2012 2:17 AM
    Moderator
  • Eric, what about internal devices that provides generic service(s) that can be used by multiple ISVs? e.g. an internal NFC reader, security engine providing hardware based crypto services, etc. Such devices can be used by multiple ISVs to provide enhanced offerings to clients on supported platforms and can help differentiate a vendor's platform from competitors.  OEMs would want ISVs to be able to use services provide by these devices with minimum enablement. Having to update the OEM metadata for each new ISV is going to be a scaling as well as deployment issue.

    What's the recommended usage model for these devices? Will there need to be a default app for these devices that other ISV apps will somehow need to invoke with some kind of app-app communication?

    Thanks,
    Rahul


    Rahul Ghosh

    Tuesday, March 20, 2012 6:34 AM
  • There is a WinRT API for NFC.  This allows Metro style apps to access the NFC easily without being specified in the metadata.

    There are also WinRT APIs for cameras, printers, network devices, WPD and removable storage. 

    Tuesday, March 20, 2012 8:53 PM
    Moderator
  • Hi Eric :

    We are eager to have this information too.

    Any ETA on this ?

    regards

    Neo Wong

    Monday, March 26, 2012 2:37 PM
  • Neo Wong,

    Not yet.  I will post here as soon as I have more.

    Best Wishes - Eric

    Monday, March 26, 2012 7:23 PM
    Moderator
  • Dear Eric,

    For external device, Metro UI application of FX2 can acess the special device successfully.

    My detail steps are:

    1) Update my function driver to register one device interface . The device interface GUID is same as FX2 sample.

    2) Update my INF file to add privildged right for the device interface.

    3) Update the Metadata from FX2 sample. In fact, I just modify the hardware id.

    4) Restart OS after my diver and my metadata are installed successfully.

    FX2 Metro Application can access my device  and open successfully.

    But for internal device, the Metro UI apllication of FX2 always return access dined.

    Comparing with the external device, the differences of my operation are:

    1) Installed the same driver for internal device, such as ACPI device.

    2) When update metadata from FX2 sample, we choose computer(or notbook) as our primary category and use "ComputerMetadata\XXX" as

         hardware id.

         XXXX - it is created by one WDK tool, ComputerHardwareIds.exe

    We have tested many times. But still can not access the internal device.  

    I am not sure that whether my operation steps are all right or not!

    Can you give me some advises?

    Dear ALL:

    Cound you access specialized internal device successfully now?

    Please give me some information if possible!

    Thanks a lot!


    • Edited by xptx Wednesday, March 28, 2012 5:43 AM
    Wednesday, March 28, 2012 5:41 AM
  • xptp,

    For the external scenario did you enable test signing  before rebooting?  Also this paper goes into detail on this topic:  http://msdn.microsoft.com/en-us/library/windows/hardware/br259108.aspx

    For the internal device:

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


    • Proposed as answer by xptx Saturday, March 31, 2012 10:10 AM
    • Unproposed as answer by xptx Saturday, March 31, 2012 10:11 AM
    • Proposed as answer by xptx Saturday, March 31, 2012 10:11 AM
    Wednesday, March 28, 2012 7:26 AM
    Moderator
  • Dear Eric,

    Thanks for your information!

    It seems that Metro Application can access both external device and internal device on Win8 8250.

    Friday, March 30, 2012 3:00 AM
  • @xptx,

    Could you please describe us how you were able to access internal device on Win8 8250?

    Thanks in advance.

    Friday, March 30, 2012 4:32 AM
  • U K,

    Please refer the information that I have post last wednesday.

    After install the internal device driver and PC Metadata,

    please enable testsigning flag of OS as following steps.

    1) Start Cmd.exe as administrator.

    2) Execute the following command line. bcdedit -set testsigning ON

    3) Restart OS.

    After OS is restarted and PC metadata is loaded, the FX2 Metro sample can access all of

    the inernal devices.

    Note:

    Please refer CreateDevMetadataPkg.docx to get detail about how to create PC (Computer) device Metadata.

    Please refer DevMetadataPkgPipe.docx to get detail about how to load PC device Metadata.

    Monday, April 02, 2012 3:02 AM
  • Dear Eric,

    Sorry for bother you again!

    I am writing my own Merto APP which can access devices.

    And I find a strange issue. The detail info is:

    When I create a Metro App with C++ language and modify the publisher to my company info, and then build it, I find the package uses

    an other specific string for the publisher. Such as "CN= Microsoft Corporation".

    I check it by reading AppxManifest.xml file located in the Output Directory, "$(OutDir)". 

    After I update the publisher name string to my expect string, the App can access devcies successfully.

    Furthermore, I create another Metro App with Java language for checking. But I have not found the same issue.

    Now I am still not sure if it is a VS2011 Bug.

    Please gvie me some advices if you know about this!

    Thanks advance!


    • Edited by xptx Tuesday, April 03, 2012 11:09 AM
    Tuesday, April 03, 2012 11:06 AM
  • I think your question can be boiled down to:

    When I create a Metro App with C++ language and modify the publisher to my company info, and then build it, I find the package uses an other specific string for the publisher. Such as "CN= Microsoft Corporation".  I check it by reading AppxManifest.xml file located in the Output Directory, "$(OutDir)".  Is this a known issue?

    If you post the question that way here: 

    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/threads

    That would be the best approach.

    Best Wishes - Eric

    Tuesday, April 03, 2012 6:08 PM
    Moderator
  • Dear Eric,

    Thanks for your kindly help!

    Wednesday, April 04, 2012 1:18 PM
  • You are most welcome.

    Best Wishes - Eric

    Wednesday, April 04, 2012 2:30 PM
    Moderator
  • Hi Eric

    Any news of the white paper on internal device access from a metro app?

    Best Wishes.

    Monday, April 09, 2012 1:54 AM
  • Hi Eric,

    Do you have any update on the whitepaper release date? It has been a month and a half since Consumer Preview release.

    Thanks

    Wednesday, April 18, 2012 12:33 PM
  • I will post an update to this thread as soon as I have more information.

    Best Wishes - Eric

    Sunday, April 22, 2012 1:20 AM
    Moderator
  • Hi Eric,

    Do you have any update? It has now been 10 weeks since Consumer Preview release? Will this information ever become available?

    Thanks,

    David

    Monday, May 07, 2012 11:19 PM
  • Hello Eric,

    It look like this thread explains why I can't access my device. Is there any news on a white paper. This is really blocking development of our Metro apps!

    Thanks,

    Stan

    Monday, July 02, 2012 8:56 PM
  • Stan,

    Nothing yet.  I will update this thread with any updates.
    Best Wishes - Eric

    Tuesday, July 03, 2012 10:14 PM
    Moderator
  • The OEM owns the metadata.  The OEM owns the decision about which apps can access devices internal to the PC.

    If the IHV has a metro style device app that they want on a user’s start screen, they need to convince their OEMs to include their app.  And since the number of apps the OEM can include is limited they’ll need to convince the OEM that there’s value in having their app over some other IHV’s app for their device.


    Hello Eric,

    Does it mean that privileged App needs to be declared in PC metadata and Internal Device metadata? Or does it need to be declared only in PC metadata?

    Thanks.


    • Edited by Yevgeniy I Monday, September 17, 2012 7:21 PM
    Monday, September 17, 2012 7:00 PM
  • Hi Eric,

    Is there any update on the white paper?

    Thanks,

    Kuan

    Wednesday, October 24, 2012 6:01 PM
  • Hi Eric,

    We are developing  Windows Store App based tool for Windows 8 Tablet.

    Windows 8 Tablet has our eMMC and uses Microsoft driver stack (not our custom driver).

    As mentioned in the post earlier,

    * Had the device interface GUID listed in the metro app manifest's Capabilities section.
      <Capabilities>
        <DeviceCapability Name="<device interface GUID>"/>
      </Capabilities>
    * created a devicemetadata package for the device with hardware id specified, hardware id was read from the Device Manager entry for the device. I used the metadata wizard in wdk 8.0 dev preview for this. Entered the metro app package name and publisher name under the Privileged Applications section. Did not specify a default application since there were none.
    * Had the resulting package copied to the devicemetadata store.
    * updated the driver inf file to register the device interface class as privileged (used the OSRUSBFX2 sample inf file as example):
      [XXXX_Interface_AddProperty]
      {026e516e-b814-414b-83cd-856d6fef4822},6,0x11,,1 ; Privileged Interface
    * reinstalled the driver with the updated inf
    * rebooted the machine

    In our case,

    Since we are using Standard MS driver stack, we don't need to do anything with Driver inf.

    But we need to call standard SD/MMC IOCTLs (IOCTL_SFFDISK_DEVICE_COMMAND) to send MMC commands to our eMMC device.

    Please guide me the approach to follow.

    Thanks,

    Raphel 

    Wednesday, February 06, 2013 12:06 PM
  • Hi Eric,

    Is there any update on white paper about accessing internal devices from windows store application.

    Thanks,

    Sridevi.

    Thursday, February 07, 2013 6:50 AM
  • Hi,

    Could you please answer my queries.

    We are developing  Windows Store App based tool for Windows 8 Tablet.

    Windows 8 Tablet has our eMMC and uses Microsoft driver stack (not our custom driver).

    As mentioned in the post earlier,

    * Had the device interface GUID listed in the metro app manifest's Capabilities section.
      <Capabilities>
        <DeviceCapability Name="<device interface GUID>"/>
      </Capabilities>
    * created a devicemetadata package for the device with hardware id specified, hardware id was read from the Device Manager entry for the device. I used the metadata wizard in wdk 8.0 dev preview for this. Entered the metro app package name and publisher name under the Privileged Applications section. Did not specify a default application since there were none.
    * Had the resulting package copied to the devicemetadata store.
    * updated the driver inf file to register the device interface class as privileged (used the OSRUSBFX2 sample inf file as example):
      [XXXX_Interface_AddProperty]
      {026e516e-b814-414b-83cd-856d6fef4822},6,0x11,,1 ; Privileged Interface
    * reinstalled the driver with the updated inf
    * rebooted the machine

    In our case,

    Since we are using Standard MS driver stack, we don't need to do anything with Driver inf.

    But we need to call standard SD/MMC IOCTLs (IOCTL_SFFDISK_DEVICE_COMMAND) to send MMC commands to our eMMC device.

    Please guide me the approach to follow.

    Thanks,

    Raphel 

    Thursday, February 14, 2013 4:07 AM