Multiple app device access limitations using winusb.dll?

NTDEV
1

We currently have WDM USB drivers in XP for our product, and we
communicate to our device from multiple applications at the same time:
Our regular application, a monitoring application, and a debug app.
We would like to do the same in the Vista environment using the WinUSB
API instead of writing a UMDF driver, but I saw one post where a developer
mentioned that the WinUSB API could only be used from one application (no
simultaneous access to the device from other applications). Can someone
verify or refute this? I didn’t see this limitation mentioned in any of
the WinUSB API documentation, but I need to verify that it does not
have this limitation.

If it turns out that simultaneous application access cannot be done with
the WinUSB API, the next obvious thing to try is a UMDF driver.
Does it have any similar application-related limitations?

Thanks!

2

Yes, winusb is an exclusive device and only one application can have a handle against it at a time. UMDF does not have the same limitations by default, but you can specify that your UMDF device be exclusive access if you need it. In this case, it is not the desired results so you don’t mark your device as exclusive (which is the default) and away you go…

d

3

Hi. This is an interesting thread. So you can’t “clone” the handle to a WinUSB device? This is what my company does currently with the handle to a COM port to get “multiple handles”. The API function we use is ‘DuplicateHandle’. This sounds like it should work with WinUSB (please correct if I’m wrong).

Another option I can think of is to just use the handle to the device as the session semaphore. This will greatly slow down ownership switching between multiple applications but I would like to know why this wouldn’t work as well. Essentially you acquire the handle, use it, and then release it for the next application. This may not be ideal, but could work (unless this can’t be done with WINUSB)…

Anybody know if these would work? Any potential problems or pitfalls?

If used by itself without UMDF, will WINUSB handle hibernation and sleep states? Or, does the application have to deal with this?

Thanks,

–Brian Hindman

4

DuplicateHandle should work since the driver does not see this API reflected to it in any new file handle related IRPs. WinUSB is the power policy owner for the device when UMDF is not attached to it (it cannot assume a well behaving application), so it will handle power state transitions properly.

d