一、故障环境
| 项目 | 信息 |
|---|---|
| Windows | Windows 11，Build 22621.3880 |
| 原 ADB | Android Debug Bridge 1.0.41 / Platform-Tools 34.0.5-10900879 |
| 目标设备 | Android 车机，USB VID_05C6 / PID_9015 |
| ADB 子接口 | MI_00，兼容 ID 为 USB\Class_FF&SubClass_42&Prot_01 |
| 验证版本 | Platform-Tools 37.0.1-15733141 |
二、故障现象：ADB 一直等设备，设备管理器却并不"像坏了"
客户通过 USB 连接车机后，最直接的表现是：
adb logcat -c
- waiting for device -
adb root
adb: unable to connect for root: no devices/emulators found
adb devices
List of devices attached设备管理器里同时看到 iAP Interface 黄色感叹号，属性显示 Code 28：驱动程序未被安装。这个现象很容易把排查方向带到"先装高通驱动 / 先修 iAP"上。
图 1：iAP Interface 存在 Code 28，但后续证据证明它不是本次 ADB 失败的原因
三、先确认 ADB 工具本身：Server 能启动，但设备列表为空
先查实际调用的是哪一套 ADB，避免电脑中 scrcpy、手机助手、Android SDK 等多个 ADB 混用：
where adb
adb version
adb kill-server
adb start-server
adb devices -l故障机只命中 C:\platform-tools\adb.exe，版本为 34.0.5。ADB Server 可以正常监听 5037，但 devices 列表仍然为空。
图 2：ADB 34.0.5 能启动 Server，但 adb devices -l 没有任何设备
这里可以排除什么？
5037 端口并不是当前主要问题，因为 ADB Server 已经成功启动；问题发生在"ADB Server 如何枚举 / 打开 USB 设备"这一层。
四、设备管理器按连接查看：车机其实已经暴露了 ADB Interface
把设备管理器切换为查看 → 按连接显示设备，同一个 USB Composite Device 下能看到：
USB Composite Device
├─ ADB Interface
├─ iAP Interface
└─ UsbNcm Host Device #2
图 3：同一复合 USB 设备同时枚举出 ADB、iAP 和 NCM 三个接口
进一步通过 PowerShell 查询 VID_05C6，可以确认接口关系：
Get-PnpDevice -PresentOnly |
Where-Object { $_.InstanceId -like '*VID_05C6*' } |
Format-Table Status,Class,FriendlyName,InstanceId -AutoSize
图 4：MI_00=ADB Interface，MI_01=iAP，MI_02=NCM；
其中 MI_00 的兼容 ID 为：
USB\Class_FF&SubClass_42&Prot_01这一步非常关键：车机已经把标准 ADB USB Interface 暴露给 Windows。
五、ADB Interface 驱动正常：Microsoft WinUSB 已经启动
ADB Interface 属性显示设备运转正常，驱动为 Microsoft WinUSB：
- 驱动程序提供商：Microsoft
- 驱动程序版本：10.0.22621.2506
- 设备类：USBDevice
- 驱动：winusb.inf
图 5：ADB Interface 已正常绑定 Microsoft WinUSB
一个容易误判的点：
"设备管理器显示运行正常"只代表 WinUSB 功能驱动已经成功加载，并不等价于某个用户态程序一定能按自己需要的 Device Interface 找到这个设备。
六、关键证据：历史同型号实例注册过 ADB DeviceInterfaceGUID，当前实例没有
继续检查 Windows 的 Device Interface 注册状态。当前连接的 MI_00 实例没有出现在传统 ADB 接口 GUID 下；但同一台电脑的历史记录里，存在同型号 VID_05C6&PID_9015&MI_00 实例，并明确记录：
DeviceInterfaceGUID
{F72FE0D4-CBCB-407D-8814-9ED673D0DD6B}
图 6：历史同型号实例存在 ADB DeviceInterfaceGUID；
Microsoft 的 WinUSB 文档说明，加载 winusb.sys 与"应用如何枚举这个设备"是两回事；用户态程序通常通过 Device Interface GUID 枚举相应设备。传统 Windows ADB 代码也存在按接口类枚举活动设备的路径。
这里可以确认"当前实例与历史实例的 Device Interface 注册状态不同"。但没有手工给当前实例补 GUID 再做 A/B，因此不能严谨地写成"缺 GUID 就是唯一直接原因"。更准确的判断是：旧版 ADB 与当前 WinUSB / Device Interface 枚举状态存在兼容性问题，GUID 差异是高度相关的解释证据。
七、最有价值的一步：直接做新旧 ADB A/B 测试
这时没有继续折腾 Qualcomm 驱动，也没有改注册表，而是把新版 Platform-Tools 解压到独立目录，保留旧环境：
C:\platform-tools\adb.exe kill-server
C:\platform-tools-37-test\platform-tools\adb.exe version
C:\platform-tools-37-test\platform-tools\adb.exe start-server
C:\platform-tools-37-test\platform-tools\adb.exe devices -l结果没有修改任何其他条件，新版 37.0.1 立即识别到车机，并显示为 device。
图 7：Platform-Tools 37.0.1 立即识别设备；
继续执行实际业务命令：
adb root
adb devices返回 adbd is already running as root，并持续显示 device，说明不只是"看到了设备"，实际 ADB 通信也已经恢复。
图 8：最终功能验证成功；
八、最终原因与解决方案
最终确认：
原使用的 Platform-Tools / ADB 34.0.5 与当前 Windows 下车机的 WinUSB / Device Interface 枚举状态存在兼容性问题。
车机 ADB 功能、USB 物理连接、MI_00 标准 ADB 接口以及 Microsoft WinUSB 驱动本身均正常；仅替换 ADB 版本后即恢复，A/B 证据闭环。
处理方式：
- 备份原
C:\platform-tools。 - 从 Google 官方渠道下载新的 Platform-Tools，整套替换，不只替换单个
adb.exe。 - 重新打开 CMD，执行
where adb、adb version，确认路径和版本正确。 - 执行
adb devices -l，确认目标设备为device。 - 再验证实际业务命令，如
adb logcat、adb root。 - 如果业务软件自带自己的
adb.exe，还要检查它是否仍在调用旧版本。
版本提醒： Google 官方 release notes 当前将 37.0.1 标注为 2026 年 7 月 Canary，并说明 Windows 端引入 libadbusb 替代 libusb。本案例用它完成了故障验证；如果要在企业环境长期固定使用，建议保留旧包以便回退，并对实际业务命令做回归验证。
九、总结
这个问题的关键不是"看到黄色感叹号就修黄色感叹号"，而是把 USB 复合设备拆开看：哪个接口是 ADB、它有没有正确加载驱动、ADB 到底用什么方式枚举它。
最终最有价值的证据不是某一条注册表或某一个驱动名称，而是：
同一台电脑
同一台车机
同一根 USB 连接
同一套 Windows / WinUSB 驱动
ADB 34.0.5：devices 为空
ADB 37.0.1：立即显示 device，并且 adb root 成功这组 A/B 结果直接把故障定位到了旧版 ADB 与当前 Windows USB 枚举方式的兼容性层。