一、故障环境项目信息WindowsWindows 11Build 22621.3880原 ADBAndroid Debug Bridge 1.0.41 / Platform-Tools 34.0.5-10900879目标设备Android 车机USB VID_05C6 / PID_9015ADB 子接口MI_00兼容 ID 为 USB\Class_FFSubClass_42Prot_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”上。图 1iAP 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列表仍然为空。图 2ADB 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图 4MI_00ADB InterfaceMI_01iAPMI_02NCM其中 MI_00 的兼容 ID 为USB\Class_FFSubClass_42Prot_01这一步非常关键车机已经把标准 ADB USB Interface 暴露给 Windows。五、ADB Interface 驱动正常Microsoft WinUSB 已经启动ADB Interface 属性显示设备运转正常驱动为 Microsoft WinUSB驱动程序提供商Microsoft驱动程序版本10.0.22621.2506设备类USBDevice驱动winusb.inf图 5ADB Interface 已正常绑定 Microsoft WinUSB一个容易误判的点“设备管理器显示运行正常”只代表 WinUSB 功能驱动已经成功加载并不等价于某个用户态程序一定能按自己需要的 Device Interface 找到这个设备。六、关键证据历史同型号实例注册过 ADB DeviceInterfaceGUID当前实例没有继续检查 Windows 的 Device Interface 注册状态。当前连接的 MI_00 实例没有出现在传统 ADB 接口 GUID 下但同一台电脑的历史记录里存在同型号VID_05C6PID_9015MI_00实例并明确记录DeviceInterfaceGUID {F72FE0D4-CBCB-407D-8814-9ED673D0DD6B}图 6历史同型号实例存在 ADB DeviceInterfaceGUIDMicrosoft 的 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。图 7Platform-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.5devices 为空 ADB 37.0.1立即显示 device并且 adb root 成功这组 A/B 结果直接把故障定位到了旧版 ADB 与当前 Windows USB 枚举方式的兼容性层。参考资料Android DevelopersSDK Platform-Tools release notesMicrosoft LearnWinUSB (Winusb.sys) 安装Microsoft LearnWinUSB 设备与 Device Interface GUID