New for getresult returning "E_ACCESSDENIED General access denied error" when I try to access the driver in metro app using ICreateDeviceAcessAsync.

Question

I've seen a lot of similar questions on this issue and tried all them out:

1. Enabled the test mode.

2. Create class interface and set the restricted property in .sys file as the fx2 driver sample.

3. Create and copy the metadata into metadata store and set the devicecapability with the same class interface. Make sure the publisher and package name same with the metro app manifest. Hardware id correspond with the device manager.

4. Using traceview to track the event, returning:

DeviceBroker: Opening handle for instance path \\?\HID#VID_1522&PID_0007#7&13DC1CE8&0&0000#{4d36e96f-e325-11ce-bfc1-08002be10318}
DeviceBroker: Failed opening handle for instance path \\?\HID#VID_1522&PID_0007#7&13DC1CE8&0&0000#{4d36e96f-e325-11ce-bfc1-08002be10318} with hr 80070005
DeviceBroker: Exiting OpenDeviceFromInterfacePath with hr 8007000

5. For “Start /wait ddodiag.exe –o <Filename.xml>”,  I checked the manufacturer and metadata path and found one that was correct.(Since I tried many times , so there're a lot of information inside.)  When I change the category from "Others" to "Input", it would correspondingly change from other to Input in the device and printer page. I think maybe the metadata has been set right.

But it still cannot work.  I'm thinking about it, maybe it's because

1: I build my driver using WDK 7 and install  , debug the driver in Win 8. Does this matter?

2: My class interface is {4d36e96f-e325-11ce-bfc1-08002be10318} which is the default guid for mouse in windows system. I didn't create a customer one but create the same guid again, is that ok?

3: I also tried using vs 2012 to build my driver and replacing this output driver with the original one.  It just differs that I didn't install using the .inf file because the default inf is too big and relied on other inf files. It would be complicated to transfer all the files  and projects. Disappointingly,  the result still can't work. Since I create the interface and set property in my driver, I think it would not matter when I just replace this new driver with original one. 

4:  Using vs2012 to build driver can get a test signed certificate which is different with my original one. Do we also need to test sign the driver after set to the test mode on windows since win 8 focus security so much? I just double click the output certificate and import it . What else need to do for the certificate?

This troubles me much, please, help. Thanks.

Answer 1

When authoring device metadata, the box for "use custom driver" should be checked. 

If in doubt, try starting with the inf and driver for the fx2 sample to see if you can get that to work.  The steps you described above look right.

Answer 2

The trace indicates that a handle can't be opened to your device; it's not failing any of the related policy checks.  Have you tried using a desktop (Win32) application running as normal (non-elevated) user to see if you can open your interface and send IOCTLs to it?

Answer 3

When authoring device metadata, the box for "use custom driver" should be checked. 

If in doubt, try starting with the inf and driver for the fx2 sample to see if you can get that to work.  The steps you described above look right.

You're referring to "Access Customer Driver" checkbox in the privileged applications of application tabs? Yes, I did that already.

Answer 4

The trace indicates that a handle can't be opened to your device; it's not failing any of the related policy checks.  Have you tried using a desktop (Win32) application running as normal (non-elevated) user to see if you can open your interface and send IOCTLs to it?

Yes, desktop version app can access the driver and function well.  "Failed opening handle for instance path" , what would lead to this situation?

Answer 5

    Any one? Help.

Answer 6

Paul is correct in that the failure is in opening the handle to the device and not related to the policy checks. 

Did you confirm that the desktop app is able to use the exact same instance path (\\?\HID#VID_XXX&PID_0007#7&13DC1CE8&0&0000#{4d36e96f-e325-11ce-bfc1-08002be10318}) to open the handle to the device when running as a normal user (not elevated)?

It may help to paste both the CreateFile call (desktop) and the ICreateDeviceAccessAsync call (Windows Store app) so we can take a look.  My guess is there could be something specific in the flags you're using on the desktop for the success case.

Answer 7

Paul is correct in that the failure is in opening the handle to the device and not related to the policy checks. 

Did you confirm that the desktop app is able to use the exact same instance path (\\?\HID#VID_XXX&PID_0007#7&13DC1CE8&0&0000#{4d36e96f-e325-11ce-bfc1-08002be10318}) to open the handle to the device when running as a normal user (not elevated)?

It may help to paste both the CreateFile call (desktop) and the ICreateDeviceAccessAsync call (Windows Store app) so we can take a look.  My guess is there could be something specific in the flags you're using on the desktop for the success case.

   Yes, I'm sure that I'm using the same instance path(I changed the VID manually for privacy at first).  

   For the CreateFile call (desktop), it's in my com part, it's like:

    HANDLE hHandle = CreateFile(szDevicePath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, (LPSECURITY_ATTRIBUTES)NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

    For the ICreateDeviceAccessAsync  call(Windows strore app):

 

hr = CreateDeviceAccessInstance(InstancePath->Data(),GENERIC_READ | GENERIC_WRITE, &access);

THROW_HR(hr);

hr = access->Wait(INFINITE);
THROW_HR(hr);

hr = access->GetResult(IID_PPV_ARGS(&deviceControl));          (return access denied);

    

      It seems that it's ok here. Thanks.

Answer 8

CreateDeviceAccessInstance does not support sharing modes (i.e. it will always pass 0 for the third parameter to CreateFile).  Does your driver require that these are passed?  What happens in the Win32 application if you pass 0 for this parameter?

Answer 9

   Reply Paul:

Everything works fine in my desktop app for this code. I didn't use sharing modes in CreateDeviceAccessInstance. 

  (1)For the CreateFile call (desktop), it's in my com part, it's like:

    HANDLE hHandle = CreateFile(szDevicePath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, (LPSECURITY_ATTRIBUTES)NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

  (2) For the ICreateDeviceAccessAsync  call(Windows strore app):

 

hr = CreateDeviceAccessInstance(InstancePath->Data(),GENERIC_READ | GENERIC_WRITE, &access);

 Why would MS make accessing driver so difficult.  It's too difficult compared to original one and cost much more energy to the developers.    Help continuously!

Answer 10

Do you get access denied if you call CreateFile exclusive (without the sharing flags) from the desktop app?

Answer 11

To be a bit more specific, what happens if your desktop code looks like this:

HANDLE hHandle = CreateFile(szDevicePath, GENERIC_READ | GENERIC_WRITE, 0, (LPSECURITY_ATTRIBUTES)NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

Answer 12

Hi, I tried createfile without share flag in my desktop. It still works. Maybe this 's not the problem .   Can you help answer the questions below?  I think maybe that's the reason.

1: I build my driver using WDK 7 and install  , debug the driver in Win 8. Does this matter?

2: My class interface is {4d36e96f-e325-11ce-bfc1-08002be10318} which is the default guid for mouse in windows system. I didn't create a customer one but create the same guid again, is that ok?

3: I also tried using vs 2012 to build my driver and replacing this output driver with the original one.  It just differs that I didn't install using the .inf file because the default inf is too big and relied on other inf files. It would be complicated to transfer all the files  and projects. Disappointingly,  the result still can't work. Since I create the interface and set property in my driver, I think it would not matter when I just replace this new driver with original one. 

4:  Using vs2012 to build driver can get a test signed certificate which is different with my original one. Do we also need to test sign the driver after set to the test mode on windows since win 8 focus security so much? I just double click the output certificate and import it . What else need to do for the certificate?

Thanks.

Answer 13

    It stills works after I tried the code above. Could you help answer questions above? Thanks.

Answer 14

To answer your questions:

1. How the driver was built should not matter as long as you're setting the restricted property on the interface.  You are not even getting far enough to check that this is the case, but since you can open from the desktop your driver is clearly loading okay.
2. That GUID is the Setup Class GUID for the mouse class.  The mouse interface class is a different GUID (and the system listens for arrival of interfaces using it), but since you aren't using that GUID you won't see anyone trying to access your interface.
3. See #1.
4. Your driver is loading so there's nothing else you need to do here.

I'd like to reiterate again - we don't do anything special for the specific CreateFile call that appears to be failing (beyond passing 0 for sharing mode which you've already checked works).  Are you running your desktop application as an Administrator?  Does your INF or driver set a security descriptor on the device?

Answer 15

       

Hi,  for your question:

1:Are you running your desktop application as an Administrator? 

I tried both administrator and non-administrator mode. They both works well.

2.Does your INF or driver set a security descriptor on the device?

No. I didn't set any security descriptor on device. 

The reason why I ask about win 7 driver building question is that setting restricted property (DEVPKEY_DeviceInterface_Restricted) is available starting with Windows 8. I changed the header file Devpkey.h to define DEVPKEY_DeviceInterface_Restricted as it's like in win 8. I suppose maybe it could not work in win 7 correctly though, but could run well when i install it in win8.

Answer 16

It's okay to set a property that doesn't exist in Windows 7 headers, it will simply not be used by anything on Windows 7.

Do you see your IRP_MJ_CREATE dispatch routine called when you go through the broker?  Also, can you try using CreateDeviceAccessInstance from a desktop app and verify this works? (It won't go through the broker in this case).

Answer 17

Is there a solution to this problem?

I experience the same problem, in my case with a smart card reader device:

DeviceBroker: Opening handle for instance path \\?\USB#VID_1A44&PID_0101#6&10354432&0&7#{50dd5230-ba8a-11d1-bf5d-0000f805f530}
DeviceBroker: Failed opening handle for instance path \\?\USB#VID_1A44&PID_0101#6&10354432&0&7#{50dd5230-ba8a-11d1-bf5d-0000f805f530} with hr 80070005

What does this error mean exactly? What goes wrong in Windows?

In my case it's even more curios, as I have developed a driver, meta-data and an application which is working fine on one Windows 8 machine and testing the same set of binaries on a second Windows 8 machine traceview displays this error and the application gets access denied. This means that the problem is not in the driver, meta-data or application as it works fine on one machine.

Both machines have test signing enabled.

Answer 18

Have you confirmed that metadata was updated on the second machine?

Answer 19

Finally solved the problem. It had nothing to do with the metadata, it was much earlier.

The problem was that the driver had no security descriptor defined in the inf file. It seems that the driver get different default access rights on different Windows 8 machines, no idea why. On one machine only administrative users had access, on another machine everyone had access to the driver and in that case it was working. I found this out using WinObj.

The solution was to add the security descriptor to the inf file in the following form:

HKR,,"Security",,"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGX;;;RC)"

It seems that my problem had nothing to do with the initial problem in this post. But it seems that this traceview error "DeviceBroker: Failed opening handle for instance path" indicates that the ACL may have wrong settings which can be verified using WinObj.

Answer 20

Stonator,

The fact that the ACL is different on multiple systems indicates that you may be using a pre-defined class when creating your device object; you're conflicting with another driver that uses the same class that happened to set the security first on the system.

Is your driver a WDF driver?  If so, are you calling WdfDeviceInitSetDeviceClass or WdfPdoInitAssignRawDevice and if so what class are you passing?

If it's not a WDF driver, are you calling IoCreateDeviceSecure and if so are you passing a class as the second last parameter?

I'm glad you were able to figure this out.

Cheers!

-paul

Answer 21

Dear Sir,

 I meet the same issue MyDevice is ACPI\xxxx

hr = access->GetResult(IID_PPV_ARGS(&deviceControl));          (return access denied);

Would you kind of pass inf and driver code(addDevice)for me refer

Please

My Email is [e-mail]

 Please help me ,please ~~~