none
Details regarding E_ACCESSDENIED from ICreateDeviceAccessAsync::GetResult?

    Pertanyaan

  • Is there a way to get more details regarding an E_ACCESSDENIED failure from ICreateDeviceAccessAsync::GetResult?  Is there something written to the event logs that can provide some insight as to why the call failed?  Between driver metadata, device interface properties, application manifests, etc., it seems like there are several places where something can go wrong.  It would be nice to have some additional information to help troubleshoot the problem.
    11 April 2012 0:57

Jawaban

  • Thunk Monkey,

    Use traceview from the WDK to view the error messages reported from deviceaccess.dll.  The output from that will tell you what part of the authentication process failed.  If you point traceview at the public symbol server, you should be able to add deviceaccess.dll to your trace session through the UI and get trace message decoding.

    If you don’t have test signing enabled on the system (and haven’t rebooted since enabling it) the device metadata system won’t set the properties that enable device access.  But it will set the other properties, so you may still see the fancy device icon.

    The instructions below will help you figure out if the device property is actually being set on their device.

    DRAFT instructions:

    Debug the device container properties by Using Ddodiag.exe If you debug a device metadata package problem or any device properties problem, we recommend that you use Ddodiag.exe.

    Beginning with Windows 7, the Ddodiag.exe supports listing all values of the device properties in device containers.

    Follow these steps to run Ddodiag.exe:

    1.    Launch command prompt.

    2.    Type “Start /wait ddodiag.exe –o <Filename.xml>” and hit enter key.

    3.    Type notepad.exe <Filename.xml>.

    Note:  The xml contains all properties of device containers in the system. If you are investigating given specific device problem, find the hardwareID or ModelID in the XML output file and see the properties of the device container. If you are investigating whether given property value is set or not, try to find the value in that XML output file.

    Here is how you can quickly tell if Device Metadata is installed properly:

    1.       For the relevant Hardware ID - look for the DDO element (the device container) and see all properties that belong to the container.   One of the properties is MetadataPath. 

    2.       If filename listed in MetadataPath does not match the target name, it isn’t installed properly and solution is to re-install the device metadata.


    If device metadata is installed properly, the values you set for Manufacturer Name or Package Name for that Hardware ID should be listed properly.  At this point, look for the relevant properties needed are properly declared in device metadata.

     Best Wishes - Eric


    11 April 2012 5:16

Semua Balasan

  • Thunk Monkey,

    Use traceview from the WDK to view the error messages reported from deviceaccess.dll.  The output from that will tell you what part of the authentication process failed.  If you point traceview at the public symbol server, you should be able to add deviceaccess.dll to your trace session through the UI and get trace message decoding.

    If you don’t have test signing enabled on the system (and haven’t rebooted since enabling it) the device metadata system won’t set the properties that enable device access.  But it will set the other properties, so you may still see the fancy device icon.

    The instructions below will help you figure out if the device property is actually being set on their device.

    DRAFT instructions:

    Debug the device container properties by Using Ddodiag.exe If you debug a device metadata package problem or any device properties problem, we recommend that you use Ddodiag.exe.

    Beginning with Windows 7, the Ddodiag.exe supports listing all values of the device properties in device containers.

    Follow these steps to run Ddodiag.exe:

    1.    Launch command prompt.

    2.    Type “Start /wait ddodiag.exe –o <Filename.xml>” and hit enter key.

    3.    Type notepad.exe <Filename.xml>.

    Note:  The xml contains all properties of device containers in the system. If you are investigating given specific device problem, find the hardwareID or ModelID in the XML output file and see the properties of the device container. If you are investigating whether given property value is set or not, try to find the value in that XML output file.

    Here is how you can quickly tell if Device Metadata is installed properly:

    1.       For the relevant Hardware ID - look for the DDO element (the device container) and see all properties that belong to the container.   One of the properties is MetadataPath. 

    2.       If filename listed in MetadataPath does not match the target name, it isn’t installed properly and solution is to re-install the device metadata.


    If device metadata is installed properly, the values you set for Manufacturer Name or Package Name for that Hardware ID should be listed properly.  At this point, look for the relevant properties needed are properly declared in device metadata.

     Best Wishes - Eric


    11 April 2012 5:16
  • Thanks for the info!  This is definitely useful, but it has still not helped me solve my problem.  I am writing a Metro app for an internal device.  When I try to access the device interface, it is returning E_ACCESSDENIED, and the deviceaccess.dll logs show the following:

    DeviceInterfaceAccessCheck: Container for path \\?\MyDeviceInterfacePath is {00000000-0000-0000-FFFF-FFFFFFFFFFFF}.
    DeviceBroker: Failed access check with hr 80070005.

    According to ddodiag.exe, the metadata is configured for the machine, and indeed, I do see an icon in "Devices and Printers".  The metadata correctly specifies the app as privileged.  The device interface for my driver is marked "restricted" and is also specified in <Capabilities> section of the application manifest.  I have enabled test signing.

    What else could be the problem here?

    12 April 2012 0:44
  • My problem is fixed, and I can now access the driver.  It seems the device metadata cache takes a while to update after replacing the metadata package.  It would be nice if the log output implicated the metadata as the problem.
    17 April 2012 6:52
  • Hi Thunk Monkey:

    what OS Edition do you use?

    I have the same problem like yours,

    and each time when I check, the metadata cache is already update.

    you can see the detail about my problem:

    http://social.msdn.microsoft.com/Forums/en-US/tailoringappsfordevices/thread/2f45fb63-5fbc-458a-bc71-6b9548172245

    Do you have any advices to me?

    27 April 2012 9:30
  • I was using the consumer preview.  What is the traceview output for deviceaccess.dll from your app?
    30 April 2012 22:12
  • Thunk Monkey:

    the same with you, like that:

    DeviceInterfaceAccessCheck: Container for path \\?\MyDeviceInterfacePath is {00000000-0000-0000-FFFF-FFFFFFFFFFFF}.
    DeviceBroker: Failed access check with hr 80070005.

    it worked before, But not now so strange.

    i fellow all steps strictly given by Eric Hanson, but still return E_ACCESSDENIED.

    Thunk Monkey, can you try to deploy your driver and Metro to a new computer which just install OS and VS11, and test whether it is OK or not?

    best wishes 

    Leonard.

    02 Mei 2012 1:19
  • I actually had to reinstall the consumer preview in order to get it to work.  I think it's because my metadata store/cache became corrupt, because I kept manually adding and removing metadata packages and messing around with the files in the cache.  I currently have my device app working on the consumer preview, which has many updates that were automatically installed through Windows Update.
    02 Mei 2012 22:45