获取连接的USB设备列表

我知道我是在回答一个老问题，但我只是做了同样的练习，发现了一些更多的信息，我认为这些信息会对讨论有很大的帮助，帮助其他人找到这个问题，并发现现有的答案有哪些不足。这个接受答案是关闭的，并且可以使用内德科的评论敬它。更详细地理解所涉及的WMI类有助于完成这幅图。Win32_USBHub只返回usb枢纽..事后看来，这似乎是显而易见的，但上述讨论却忽略了这一点。它并不包括所有可能的USB设备，只有那些(至少在理论上)可以充当附加设备的集线器的设备。它忽略了一些不是集线器的设备(特别是复合设备的部分)。Win32_PnPEntity包括所有的USB设备，以及数百个更多的非USB设备.罗素甘特曼氏使用WHERE子句搜索的通知Win32_PnPEntity对于以“USB%”开头的设备ID来说，筛选列表很有帮助，但稍微不完整；它忽略了蓝牙设备、一些打印机/打印服务器以及符合HID的鼠标和键盘。我见过“USB”、“USBSTOR”、“USBPRINT”、“BTH”、“SWD”和“HID”。Win32_PnPEntity然而，当您拥有其他来源的PNPDeviceID时，它是一个很好的“主”引用来查找信息。我发现枚举usb设备的最佳方法是查询Win32_USBControllerDevice..虽然它没有给出设备的详细信息，但是它完全枚举了您的usb设备，并给出了一个预先/依赖的对PNPDeviceID对系统上的每一个USB设备(包括集线器、非集线器设备和符合HID的设备)都使用。从查询中返回的每个依赖项都将是一个USB设备。前面的控制器将是它被分配给的控制器，它是通过查询返回的USB控制器之一。Win32_USBController.作为一项奖励，WMI似乎在引擎盖下遍历设备树响应Win32_USBControllerDevice查询，因此返回这些结果的顺序可以帮助识别父/子关系。(这是没有记录的，因此只是猜测；使用SetupDiAPI的cm取母(或儿童 + 兄弟姐妹)确定的结果。)作为SetupDiAPI的一个选项，看起来对于下面列出的所有设备Win32_USBHub它们可以在注册表中查找(在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ + PNPDeviceID)，并且将有一个参数ParentIdPrefix，它将是其子级的PNPDeviceID中最后一个字段的前缀，因此也可以在通配符匹配中使用它来筛选Win32_PnPEntity查询。在我的申请中，我做了以下工作：(可选)Win32_PnPEntity并将结果存储在键值映射中(以PNPDeviceID作为密钥)以供以后检索。如果以后要执行单独的查询，这是可选的。被质疑Win32_USBControllerDevice获得我的系统上USB设备的明确列表(所有受抚养人)，并提取这些设备的PNPDeviceID。我更进一步，根据设备树后面的顺序，将设备分配给根集线器(返回的第一个设备，而不是控制器)，并基于ParentIdPrefix构建了一棵树。查询返回的顺序与通过SetupDi进行的设备树枚举匹配，是每个根集线器(先导标识控制器的根集线器)，然后是下面的设备迭代，例如，在我的系统上：第二个控制器根集线器下的第一个集线器(有ParentIdPrefix)第二控制器根轮毂下的第二个集线器第二个控制器根轮毂下的第三个集线器等。组合装置的HID装置部分复合设备的HID设备部分(PNPDeviceID与复合设备的ParentIDPrefix匹配)第一个复合设备在第二个控制器根集线器下的第一个复合设备(PNPDeviceID与集线器的ParentIdPrefix匹配；有自己的ParentIdPrefix)第二控制器根集线器下第一个集线器下的第二个装置第二控制器根轮毂下的第一个装置第一控制器的根轮毂第二控制器根轮毂被质疑Win32_USBController..这给了我控制器的PNPDeviceID的详细信息，这些控制器位于设备树的顶部(这是前面的查询)。使用在前一步中派生的树，递归地迭代其子节点(根集线器)、其子节点(其他集线器)及其子节点(非集线器设备和复合设备)及其子程序，等等。通过引用存储在第一步中的映射来检索树中每个设备的详细信息。(可以选择跳过第一步，然后查询Win32_PnPEntity单独使用PNPDeviceId在这一步获取信息；可能是CPU与内存之间的权衡，以确定哪个顺序更好。)总之，Win32USBControllerDevice受抚养人是系统上USB设备的完整列表(控制器本身除外，控制器本身是同一查询中的先决条件)，并通过交叉引用这些设备。PNPDeviceId与注册表和其他查询中的信息配对，可以构造详细的图片。

获取连接的USB设备列表

3回答