Find out which process has an exclusive lock on a USB device handle

Question

I have a library that reads/writes to a USB-device using CreateFile() API. The device happens to implement the HID-device profile, such that it's compatible with Microsoft's HID class driver.

Some other application installed on the system is opening the device in read/write mode with no share mode. Which prevents my library (and anything that consumes it) from working with the device. I suppose that's the rub with being an HID-compatible device -- other driver software (mice, controllers, PHIDGETS, etc) can be uncooperative.

Anyway, the device file path is of the form:

1: "\\?\hid#hpqremhiddevice&col01#5&21ff20e7&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}".

2: "\\?\hid#vid_045e&pid_0023#7&34aa9ece&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}".

3: "\?\hid#vid_056a&pid_00b0&col01#6&5b05f29&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}".

And I'm trying to open it using code, like:

//  First, open it with minimum permissions, this device may not be ours.
//  we'll re-open it later in read/write
hid_device_ref = CreateFile(
    device_path, GENERIC_READ,
    0, NULL, OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL, NULL);

I've considered a tool like FileMon or Process Monitor from SysInternals. But I can't seem to get it to report usage on device file handles like the one listed above.

Answer 1

Have you tried the tool called handle from sysinternals?

Anyway, neither windows does this (display the name of the application that locked the device): when you try to eject an USB device, Windows just says that the device is currently in use and cannot be remove right now.

Answer 2

This is what I use to read from a Magtek card reader:

//Open file on the device
deviceHandle = 
    CreateFile (deviceDetail->DevicePath, 
    GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, 
    NULL, OPEN_EXISTING, 0, NULL);

Try those options and see if you can at least read from the device.

I understand your pain here... I found the USB HID documentation to be basically wrong in several places.

[Edit] There's not much out there on this problem. Here's a codeproject link that lightly touches on the subject in a thread at the bottom. Sounds like maybe if it's a keyboard or mouse windows grabs it exclusively.

Answer 3

There's a trick you can do where you open the device handle requesting neither read nor write permission and interact with it using only feature reports. Jan Axelson mentions this trick in her books about USB HID devices. I believe this gets around the problem with the exclusive lock, which you would encounter (for example) when trying to open a handle to a device that Windows considers a system keyboard or mouse. Even though you can't read or write the handle, you can still send a feature report to the device using HidD_SetFeature and read a report from the device using HidD_GetFeature. I don't know offhand of a way to read input reports or send output reports under these circumstances, and perhaps it's impossible to do so, but you might not need either of those, especially if the device is "your" device in the sense that you control the firmware. Strictly speaking this does nothing to answer your question as asked, but it seemed potentially relevant so I figured I'd throw it out there.

Answer 4

Cool - I'll try those options, as they're probably better defaults given my intentions. Unfortunately, I know my device is there and I'll eventually need read/write access later on (once I inspect the descriptors and have verifed it is infact my device).

Which means that my real goal IS to know what's using it, so I can inform the customer/user: "Hey man, 'iexplore.exe' is currently using your SuperWidget device. You'll have to close that down in order to use SuperWidget application." (if not at the application-level, then at least at the phone support level.)

I forgot to mention that the windows error reported by GetLastError() is:

0x20. The process cannot access the file because it is being used by another process.

(So your sharing alternatives will probably get the file open, assuming no FILE_SHARE_NONE on behalf of the other process).

[edit]

Yeah, it's painful alright. I have seen mice and keyboards get locked by whatever Windows uses to read from them. I've also seen a lot of people have trouble inside a VM like Paralells on OS X, where the HID class driver has the device open exclusively preventing the VM from using standard USB requests.

I've seen some code that recreates what ProcessMonitor does. Maybe SysInternals is just electing to ignore device handles, but the same method (or a slight variation) can be employed here to determine the PID.

Mike