OSRUSBFX2 sample missing privileged access property in INF file RRS feed

  • Question

  • Hello,

    In one of previous posts, Eric mentioned following as one of important steps in getting access to custom driver:

    "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."

    I downloaded OSRUSBFX2 sample and built the driver.  I also have the actual "OSR USB FX-2 Learning Kit" device with me, and using Custom Driver Access Sample as well.  I am still getting E_ACCESSDENIED after CreateDeviceAccessInstance!  I verified that I set testsigning and restarted, the device metadata is properly installed and I see the FX2 icon in devices and printers, the metadata has the checkbox for the custom driver access and properly sets the application ID for the Custom Driver Access Sample app.  The app has proper DeviceCapability field in app manifest XML.  The last thing I would suspect was the INF file itself.  It turns out, the OSRUSBFX2 project does NOT have this property!  Here is part of osrusbfx2.inf that gets generated when the driver is build (for Win8BetaRelease|x64):

    Signature="$WINDOWS NT$"

    ; ================= Class section =====================



    There is no "InterfaceInstall32" section as expected by official documentation at http://msdn.microsoft.com/en-us/library/windows/desktop/hh404264(v=vs.85).aspx.  I assume that the "ClassInstall32" plays that role, but there is no trace of any privileged access property, or any property being added.  It goes without saying that I installed the sample from the proper website (http://code.msdn.microsoft.com/windowshardware/OSR-USB-FX2-Sample-2a69f5a6)

    Overall, my question goes back to recommendation saying "Look at the OSRUSBFX2 sample INF for information on how to set this property key.".  So I looked and searched, but I can't see any trace of property key in this OSRUSBFX2 sample (?!)

    Tuesday, May 8, 2012 6:39 PM


  • Petar,

    The sample sets this in the driver code. The property is the restricted property.  This is the preferred method.

    Best Wishes - Eric

    Tuesday, May 22, 2012 11:01 PM

All replies

  • Petar,

    I will look into this for you.

    Best Wishes - Eric

    Wednesday, May 9, 2012 5:34 PM
  • Hello, any updates on this?

    It's been more than a week.  From my perspective, this task is just to upload the corrected sample to MSDN...

    Saturday, May 19, 2012 12:46 AM
  • Petar,

    The sample sets this in the driver code. The property is the restricted property.  This is the preferred method.

    Best Wishes - Eric

    Tuesday, May 22, 2012 11:01 PM
  • Hello Eric,

    According to MSDN documentation:

    "Instead of the AddInterface directive, the driver can also call the IoRegisterDeviceInterfaceroutine to register the device interface class.

    You can also set the privileged interface property by calling the IoSetDevicePropertyData routine."

    I searched for both of these in the driver source code, and couldn't find any.  Maybe there is a (fourth) method that can be used which is not listed in MSDN.  Can you paste the part of the sample code that actually sets the property using one of these methods?


    Thursday, May 24, 2012 12:28 AM
  • In device.c look for:

    status = g_pIoSetDeviceInterfacePropertyData(&symbolicLinkName, 
                                                         &isRestricted ); 

    Best Wishes - Eric

    Thursday, May 24, 2012 8:06 PM
  • Nice, thanks.  Note that MSDN documentation lists "IoSetDevicePropertyData" but in fact it should say "IoSetDeviceInterfacePropertyData", right?

    That said, if this part is correct, then there must be something else wrong in my setup, as I have the actual FX2 device and the driver and the app, and I still get access denied error from Metro.

    Thursday, May 24, 2012 8:21 PM
  • Petar,

    Yes that does appear to be a doc error.  I will file it. 

    Most common issues is to enable test signing and re-boot.  Many people have thought they had this but did not. 

    More detailed instructions in case that does not work:

    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

    Thursday, May 24, 2012 8:50 PM