UMDF - Communication between Application and Driver

NTDEV
1

Hello.

I am upgrading our usb drivers to UMDF (because of 64 bit support and faster work with a simple toolkit), which was easy in the beginning (thanks to the fx2 example), but I am now hanging on the interprocess communication between application and driver.

Driver installs without problems, is found with SetupDiGetClassDevs(), and is accessible through File operation (CreateFile, ReadFile, …). Read and Write operates directly on the both available bulk pipes.

The difficulty is now to upgrade the implementation for handling the interrupt pipe respectively inform the application about (surprised) removed devices. In the old drivers we transfer three handles per DeviceIoControl to the driver, which are then used to inform the application about specific tasks. The handles are duplicated with ObReferenceObjectByHandle() and later signaled by KeSetEvent().

Following things I have tested in the new implementation (and all of them failed):

  1. To use the handles directly. Gives ERROR_INVALID_HANDLE because of complete other process the driver is running.

  2. Use DuplicateHandle. Tried to transfer also the PID of the application will result in ERROR_ACCESS_DENIED for OpenProcess() of the app-PID called in driver.

  3. Use a global Event. Call CreateEvent(…, “Global\UNIQUE_NAME”) in application and call then also in driver results also in ERROR_ACCESS_DENIED.

  4. Use old Kernel Mode Driver implementation. Tried to use ObReferenceObjectByHandle() from kernel implementation (was difficult, because headers “wudfddi.h” and “wdm.h” are NOT compatible!), this needs linking of the Ntoskrnl.lib and therefore the driver dll has a dependency to NTOSKRNL.EXE. This makes the driver dll not loading successfully on the target platform.

I am at one’s wits’ end. :wink:

My Questions:

  1. Is there a possibility besides the preferred way of intercommunication (as to use pending events, forward to other io queues and use overlapped file communication)?

  2. What is the expected way to inform the application about (surprise) removal of devices or other malfunctions? And how should it be handled by the application? (I found nothing to this topic in the wddk help).

Many thanks in advance,
Tristan.

2

You can’t share events by passing them in ioctls with a umdf driver. The app is notified about surprise removal by calling RegisterDeviceNotification on the device handle. RDN also allows for your app to participate in graceful remove, which allows update driver or disable to not require a reboot while your app is running. For device specific async events use the inverted call model. That involves an overlapped handle and a manual queue that you store the requests in.

d

dent from a phine with no keynoard

-----Original Message-----
From: xxxxx@ifak-system.com
Sent: Wednesday, March 09, 2011 7:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF - Communication between Application and Driver

Hello.

I am upgrading our usb drivers to UMDF (because of 64 bit support and faster work with a simple toolkit), which was easy in the beginning (thanks to the fx2 example), but I am now hanging on the interprocess communication between application and driver.

Driver installs without problems, is found with SetupDiGetClassDevs(), and is accessible through File operation (CreateFile, ReadFile, …). Read and Write operates directly on the both available bulk pipes.

The difficulty is now to upgrade the implementation for handling the interrupt pipe respectively inform the application about (surprised) removed devices. In the old drivers we transfer three handles per DeviceIoControl to the driver, which are then used to inform the application about specific tasks. The handles are duplicated with ObReferenceObjectByHandle() and later signaled by KeSetEvent().

Following things I have tested in the new implementation (and all of them failed):

  1. To use the handles directly. Gives ERROR_INVALID_HANDLE because of complete other process the driver is running.

  2. Use DuplicateHandle. Tried to transfer also the PID of the application will result in ERROR_ACCESS_DENIED for OpenProcess() of the app-PID called in driver.

  3. Use a global Event. Call CreateEvent(…, “Global\UNIQUE_NAME”) in application and call then also in driver results also in ERROR_ACCESS_DENIED.

  4. Use old Kernel Mode Driver implementation. Tried to use ObReferenceObjectByHandle() from kernel implementation (was difficult, because headers “wudfddi.h” and “wdm.h” are NOT compatible!), this needs linking of the Ntoskrnl.lib and therefore the driver dll has a dependency to NTOSKRNL.EXE. This makes the driver dll not loading successfully on the target platform.

I am at one’s wits’ end. :wink:

My Questions:

  1. Is there a possibility besides the preferred way of intercommunication (as to use pending events, forward to other io queues and use overlapped file communication)?

  2. What is the expected way to inform the application about (surprise) removal of devices or other malfunctions? And how should it be handled by the application? (I found nothing to this topic in the wddk help).

Many thanks in advance,
Tristan.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Hello Doran,

thank you for your clear words. That leads me to another question, which haunt my mind.

If my only tasks involving our driver are Read/Write over the bulk pipes, overlapped io and manual queuing with the interrupt pipe and information about (surprise) removing the device, wouldn’t it be advisable to use the straight WinUSB driver concept (as described in “How to Use WinUSB to Communicate with a USB Device”). So I only need to provide an *.inf file and then implement a new user-mode client application that calls the Windows-supplied WinUSB driver? (Wouldn’t that even remove the dialog box “this driver is not signed”?)

Thank you and Greetings,
Tristan.

4

Yes. The reason you go with a umdf driver over straight up winusb is if
a) you want to share that device across multiple apps, winusb is exclusive access
b) you want a different io interface other than winusb (like a com port or something like that)

you still need to have your INF and driver package signed. Winusb.sys is signed, but there is no built in package that installs winusb that is signed, so you will still get the not signed dialog until you sign your package

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@ifak-system.com
Sent: Wednesday, March 09, 2011 11:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF - Communication between Application and Driver

Hello Doran,

thank you for your clear words. That leads me to another question, which haunt my mind.

If my only tasks involving our driver are Read/Write over the bulk pipes, overlapped io and manual queuing with the interrupt pipe and information about (surprise) removing the device, wouldn’t it be advisable to use the straight WinUSB driver concept (as described in “How to Use WinUSB to Communicate with a USB Device”). So I only need to provide an *.inf file and then implement a new user-mode client application that calls the Windows-supplied WinUSB driver? (Wouldn’t that even remove the dialog box “this driver is not signed”?)

Thank you and Greetings,
Tristan.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer