USB 串口 COM 端口消失：重新枚举、驱动绑定、端口号变化与 CDC 桥排查

USB 串口设备到处都是：Arduino 板、工业控制器、Modem、GPS 接收机、测试夹具、调试探针、PLC 工具、条码设备、自定义 CDC ACM 固件。COM 端口一消失，用户就会搜 "USB 串口 COM 端口消失"、"设备管理器里 COM 端口丢失"、"USB 串口重新枚举"、"CDC ACM 设备断连"、"重连后 COM 端口变了"——因为应用那边通常只告诉你"打不开端口"。

Bus Scope 在这个场景下有用，因为 COM 端口丢失可以来自很多不同的层：USB 枚举、描述符问题、驱动绑定、设备复位、应用句柄过期、Line Coding 请求失败、Windows 重新分配了 COM 号。

COM 端口不是 USB 设备本身

COM 端口是操作系统在 USB 设备枚举完、串口驱动绑定之后才生成的一个抽象。USB 设备没枚举，COM 端口就根本不会出来。USB 设备枚举成功了，但 CDC 接口失败，COM 端口可能还是出不来。

把各层拆开：

• USB 设备有没有插入？
• 描述符读对了吗？
• Configuration 有没有走完？
• CDC 接口有没有出来？
• 驱动有没有绑上？
• 操作系统有没有分配 COM 端口？
• 应用有没有打开正确的、当前的端口？

重新枚举会改变 COM 号

Windows 可能在以下情况下给设备分配新的 COM 号：序列号变了、USB 路径变了、VID/PID 变了、接口标识变了。一台设备如果重置进 bootloader 模式，可能暴露完全不同的 COM 端口，或者干脆没有 COM 端口。

症状：

• 设备原来是 COM8，现在变成 COM11
• 应用记着旧的 COM 号
• 换到另一个 USB 口，分配结果变了
• Bootloader 用的是另一个端口
• 固件升级完之后设备变成 unknown

总线 trace 能识别出设备身份是不是真的变了。

CDC ACM 控制请求

CDC 串口设备经常收到这些类请求：

• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE
• SEND_BREAK

如果固件 STALL 或者处理错了这些请求，端口可能打得开但数据完全不走，或者驱动绑定直接失败。

抓包要看"打开端口"这个动作，不只是"插入设备"。很多故障就出在应用打开 COM 端口、驱动发 Line Coding 或 DTR/RTS 状态变化的那一刻。

应用句柄过期

有时候 USB 重新枚举一切正常，但应用仍然攥着旧的句柄或者缓存了一份过时的 COM 端口列表。总线上新设备明明在，应用却还失败——因为它没有释放或刷新端口。

这不是 USB 总线的故障，是应用或设备管理层的行为。

排查清单

按这个流程：

1. 从插入开始抓
2. 确认 Device Descriptor 和 Configuration Descriptor
3. 检查 CDC Interface Descriptor
4. 抓应用打开 COM 端口的过程
5. 检查 CDC 类请求
6. 查 Line Coding 之后有没有复位或断连
7. 对比重连前后的设备身份
8. 查 COM 号是不是变了
9. 查应用是否在用过期的端口名
10. 保留 USB 证据 + 操作系统端口分配记录

最终诊断

USB 串口 COM 端口消失，原因可能是：枚举失败、CDC 描述符失败、驱动绑定失败、以新身份重新枚举、Line Coding 请求失败、负载下复位、应用状态过期。

Bus Scope 的价值是把 USB 这一侧的故事摆出来——这样 COM 端口的症状就能和插入、描述符、CDC 请求、复位、真实设备身份对得上号。