user-mode driver communication with desktop service

Question

Hi,

I have a desktop service providing a particular functinality. I would like to access this service from a user-mode driver (UMD). I have used the CoCreateInstance with local server for communication. The driver is compiled and installed properly, however this CoCreateInstance fails with error code 0x80070005 (Access denied).

I have registered the COM server component and able to open the same from a console application. However, when the same functinality it moved into UMD, the CoCreateInstance fails.

Is there any specific settings required to support UMD - desktop service communication?

Thanks

Answer 1

I am using Windows 8 Consumer Preview. I have used the template from VS2011 to create desktop service and UMD.

I have tried both in-proc and out-of-proc methods for creating/using COM servers. Both are working with console application, however none of them works with UMD.

Answer 2

by UMD, do you mean a UMDF based driver?  exposing a COM server out a umdf driver is not something we test nor recommend. why not open a handle and use normal io mechanisms if it is umdf?

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 3

Thanks for the reply.

Yes, it is UMDF based driver. I am not exposing the COM server out a UMDF. My UMDF wants to use some functionality provided by a desktop service. Instead of replicating the functionality in UMD, I want to communicate with desktop service to achieve the desired functionality. Here the destkop service would work as a COM server and UMD would work as a COM client.

Would you please give more details, about what you mean by open a handle or use normal IO mechanism in UMDF? I am getting a handle using CoCreateInstance only to communicate with COM server.

Answer 4

i thought you wanted it the other way around. the UMDF runs in a limited security context, from http://msdn.microsoft.com/en-us/windows/hardware/gg463301

UMDF drivers run in a driver host process, which runs in the security credentials of a LocalService account, although the host process itself is not a Windows service. Thus, user-mode drivers are as secure as any other user-mode service.

so you need to ACL your COM server properly to allow for the UMDF driver to acces it. I would put the functionality into a .lib and link against it to keep your life simpler.

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 5

Thanks for the reply.

I am not much familiar with COM programming, could you please point me to some link where I can get more information setting ACL for COM server. 

When I have used in-proc COM within UMD (i.e. create COM DLL and use the same within UMD), I had also faced the issue of "Access Denied" during CoCreateInstance. How to set ACL for COM in such a scenario? In this case COM server is part of UMD host process, so there should not be any requirement of specific security. What can be the reason behind the error?

Answer 6

don't know how to set the security either. but you are going off into unsupported land, so there are no clear answers here and things may break in the next release. good luck.

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 7

Thanks for the reply. UMD - desktop service communication unsupported land !!

I have another alternative. I can remove the desktop service altogether and add that functionality in UMD. As UMD runs in host process, I can achieve the same functionality which desktop service is currently providing.

But, I was curious in this alternative, would there be any issue in Winqual of this user-mode driver? This driver would be a software-only root-enumerated user-mode driver. Does Microsoft allows certification of software-only drivers for Windows 8? 

Answer 8

yes, you can certify a root enumerated driver for w8. the certification process does not look deep enough into the UMDF driver or process to know that you are doing something not recommended like communicating with an out of proc com server

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 9

Thanks for the quick reply.

In this alternative, I may not be required to communicate with an out of proc com server. I can directly load DLLs in my user-mode driver to get required functionality.

Is there any requirement about ClassGuid for the software-only user-mode drivers? I have observed that for WDK samples the ClassGuid of "Sample". If I change the ClassGuid to System, would there be any specific protocol/standard which I need to follow?

In case if I would like to make this device a removable device, how should I tell Windows? 

Answer 10

the class GUID effects stack security settings (in terms of how handles are opened) and other drivers added tot he stack.  changing the ClassGuid to something else will not solve your COM server issue.  Don't use the System class either.   as for removable, call IWDFDeviceInitialize::SetPnpCapability(WdfPnpCapRemovable, WdfTrue)   http://msdn.microsoft.com/en-us/library/windows/hardware/ff556993(v=vs.85).aspx

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 11

Thanks for the reply. What should be the class GUID for software-only user-mode driver? Would making the device Removable is sufficient in order to have its own container instead of a PC container?

Answer 12

I think removable is enough. perhaps you need to publish your own metadata package. why is it important not to be in the pc container?

as for the class guid, it has nothing to do with the enumerator (usb, software only, pci, etc). it has to do with what the device DOES.  what device interface does the device expose?

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 13

Thanks for the reply. It is just a software-only user-mode driver. It is not associated with any specific device. 

Answer 14

what does the driver DO?

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 15

It provides some proprietary utilities. There does not seem a requirement for a driver to me. I will talk with other project members, to see if the driver can be removed out of the design.

Thank you for your posts. It clears up many design questions.