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?

Answer 1

rdghosh,

 

I will look into this for you.

 

Best Wishes - Eric

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

You are welcome Rahul. 

Thanks for your request.  I will pass it along.

Best Wishes - Eric

 

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

Rahul,

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

Best Wishes - Eric

Answer 11

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

Answer 12

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

Answer 13

Hi Eric,

The windows 8 consumer perview had been released already.

Is there any solution can solve this problem?

Thanks

Answer 14

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

Answer 15

Can you at least confirm that this is a supported scenario in Windows 8?

Answer 16

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.

Answer 17

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.

Answer 18

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. 

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

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

Answer 24

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

Answer 25

Rahul,

I will post an updated ETA for the whitepaper soon.

Answer 26

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.

Answer 27

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

Answer 28

Eric, what is the status on this white paper?  Why is there a delay?

Answer 29

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.

Answer 30

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

Answer 31

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. 

Answer 32

Hi Eric :

We are eager to have this information too.

Any ETA on this ?

regards

Neo Wong

Answer 33

Neo Wong,

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

Best Wishes - Eric

Answer 34

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!

Answer 35

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.

Answer 36

Dear Eric,

Thanks for your information!

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

Answer 37

@xptx,

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

Thanks in advance.

Answer 38

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.

Answer 39

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!

Answer 40

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

Answer 41

Dear Eric,

Thanks for your kindly help!

Answer 42

You are most welcome.

Best Wishes - Eric

Answer 43

Hi Eric

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

Best Wishes.

Answer 44

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

Answer 45

I will post an update to this thread as soon as I have more information.

Best Wishes - Eric

Answer 46

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

Answer 47

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

Answer 48

Stan,

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

Answer 49

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.

Answer 50

Hi Eric,

Is there any update on the white paper?

Thanks,

Kuan

Answer 51

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 

Answer 52

Hi Eric,

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

Thanks,

Sridevi.

Answer 53

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