找出哪个进程对 USB 设备句柄具有独占锁

发布于 2024-07-04 11:05:26 字数 981 浏览 10 评论 0 原文

我有一个使用 CreateFile() API 读取/写入 USB 设备的库。 该设备恰好实现了 HID 设备配置文件,因此它与 Microsoft 的 HID 类驱动程序兼容。

系统上安装的其他一些应用程序正在以读/写模式打开设备,而没有共享模式。 这会阻止我的库(以及使用它的任何内容)使用该设备。 我想这就是 HID 兼容设备的问题所在——其他驱动程序软件(鼠标、控制器、PHIDGETS 等)可能不合作。

无论如何,设备文件路径的形式为:

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}".

我正在尝试使用代码打开它,例如:

//  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);

我考虑过使用 SysInternals 的 FileMon 或 Process Monitor 等工具。 但我似乎无法让它报告设备文件句柄的使用情况,如上面列出的那样。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

友欢 2024-07-11 11:05:26

您可以使用一个技巧,打开设备句柄,既不请求读取也不请求写入权限,并仅使用功能报告与其进行交互。 Jan Axelson 在她关于 USB HID 设备的书中提到了这个技巧。 我相信这可以解决排它锁的问题,例如,当您尝试打开 Windows 认为是系统键盘或鼠标的设备的句柄时,您会遇到该问题。 即使您无法读取或写入句柄,您仍然可以使用 HidD_SetFeature 并使用 HidD_GetFeature。 我不知道在这种情况下读取输入报告或发送输出报告的方法,也许这是不可能的,但您可能不需要其中任何一个,特别是如果设备在某种意义上是“您的”设备您控制固件。 严格来说,这并不能回答你提出的问题,但它似乎可能相关,所以我想我会把它扔在那里。

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.

浅黛梨妆こ 2024-07-11 11:05:26

您是否尝试过 sysinternals 中名为 handle 的工具?

无论如何,Windows 都不会这样做(显示锁定设备的应用程序的名称):当您尝试弹出 USB 设备时,Windows 只是说该设备当前正在使用,现在无法删除。

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.

沙与沫 2024-07-11 11:05:26

这就是我用来从 Magtek 读卡器读取数据的方法:

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

尝试这些选项,看看是否至少可以从设备读取数据。

我理解您的痛苦...我发现 USB HID 文档在几个地方基本上是错误的。

[编辑] 关于这个问题目前还没有太多的内容。 这是代码项目链接,在底部的线程中轻轻触及主题。 听起来好像如果是键盘或鼠标窗口可能会独占它。

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.

风尘浪孓 2024-07-11 11:05:26

酷 - 我会尝试这些选项,因为考虑到我的意图,它们可能是更好的默认值。 不幸的是,我知道我的设备在那里,我最终将需要读/写访问权限(一旦我检查描述符并验证它实际上是我的设备)。

这意味着我的真正目标是知道什么在使用它,因此我可以通知客户/用户:“嘿,伙计,‘iexplore.exe’当前正在使用您的 SuperWidget 设备。您必须将其关闭才能使用SuperWidget 应用程序。” (如果不是在应用程序级别,那么至少在电话支持级别。)

我忘了提及 GetLastError() 报告的 Windows 错误是:

0x20。 该进程无法访问该文件,因为该文件正在被另一个进程使用。

(因此,假设没有 FILE_SHARE_NONE 代表其他进程,您的共享替代方案可能会打开文件)。

[编辑]

是的,很痛苦。 我见过鼠标和键盘被 Windows 用于读取数据的任何内容锁定。 我还看到很多人在 OS X 上的 Parallels 等 VM 中遇到麻烦,其中 HID 类驱动程序以专门方式打开设备,阻止 VM 使用标准 USB 请求。

我看到一些代码重新创建了 ProcessMonitor 的功能。 也许 SysInternals 只是选择忽略设备句柄,但这里可以采用相同的方法(或略有不同)来确定 PID。

迈克

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文