====================
人工输入（2026-02-23）

接下来我需要你和我一起尝试定位解决我的电脑故障。你需要把你的发言也记录在这篇文档内，以便后续查阅。
我有一台拯救者刃9000k 2024台式机，遇到了非常奇怪的问题：我的主板上有一个usb-c口，之前一直使用这个c口连接拓展坞使用。今天突然不能用了。
我尝试定位，发现：
1. 这个c口连接拓展坞，拓展坞上再连接其他设备就都不能使用；
2. 这个c口直接连接其他设备（如键盘）可以使用，直接连接我的外置ssd，可以按照usb3.0速率进行文件传输；
3. 这个c口直连我的手机，可以充电，但是无法激活usb连接模式；
4. 其他的usb-a口连接我的手机都可以激活usb连接模式；
5. 同一个拓展坞使用同一根数据线连接到其他电脑上可以正常使用连接到拓展坞的设备。
6. 重启电脑后，这个c口连接拓展坞依然无法使用，上述现象全部可以复现

根据以上信息，我怀疑这个c口的物理连接应当是正常的，但是可能存在某些软件或驱动方面的问题导致无法正常使用拓展坞。
我打开设备管理器，在其他设备下并没有发现任何异常设备，也没有看到任何与usb-c相关的错误提示。
在通用串行总线控制器下，也没有任何错误提示，但是我注意到有2个重复的USB根集线器(USB 3.0)，各自打开，进入到事件，都存在以下特征：

USB根集线器(USB 3.0) #1
- 位置：Port_#0004.Hub_#0001
- 事件：
    - 2026-02-23 00:38:34 - 设备设置未迁移
        由于设备部分匹配或不明确，USB\VID_1D5C&PID_5011\6&10f81194&0&4的设备设置未从以前的 OS 安装迁移。

        最后一个设备实例 ID： USB\VID_05E3&PID_0610\5&218bfa3c&0&9
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        位置路径：
        迁移排名： 0xF000FFFF0000F120
        Present： false
        状态： 0xC0000719

    - 2026-02-23 00:38:34 - 已配置设备（usbhub3.inf)
        已配置设备USB\VID_1D5C&PID_5011\6&10f81194&0&4。

        驱动程序名称： usbhub3.inf
        驱动程序包 ID： usbhub3.inf_amd64_77ea074f504b65c1
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        驱动程序日期： 01/26/2026
        驱动程序版本： 10.0.26100.7705
        驱动程序提供程序： Microsoft
        驱动程序部分： Generic.Install.NT
        驱动程序级别： 0x802000
        匹配设备 ID： USB\USB20_HUB
        超限驱动程序：
        设备已更新： false
        父设备： USB\ROOT_HUB30\5&323bdd91&2&0

    - 2026-02-23 00:38:34 - 已启动设备
        已启动设备 USB\VID_1D5C&PID_5011\6&10f81194&0&4。

        驱动程序名称: usbhub3.inf
        类 GUID: {36fc9e60-c465-11cf-8056-444553540000}
        服务: USBHUB3
        低层筛选程序:
        高层筛选程序:

USB根集线器(USB 3.0) #2
- 位置：Port_#0005.Hub_#0002
- 事件：
    - 2026-02-23 00:39:36 - 设备设置未迁移
        由于设备部分匹配或不明确，USB\VID_1A40&PID_0101\5&213b2cfc&0&4的设备设置未从以前的 OS 安装迁移。

        最后一个设备实例 ID： USB\VID_05E3&PID_0610\5&218bfa3c&0&9
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        位置路径：
        迁移排名： 0xF000FFFF0000F120
        Present： false
        状态： 0xC0000719

    - 2026-02-23 00:39:36 - 已配置设备（usbhub3.inf)
        已配置设备USB\VID_1A40&PID_0101\5&213b2cfc&0&4。

        驱动程序名称： usbhub3.inf
        驱动程序包 ID： usbhub3.inf_amd64_77ea074f504b65c1
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        驱动程序日期： 01/26/2026
        驱动程序版本： 10.0.26100.7705
        驱动程序提供程序： Microsoft
        驱动程序部分： Generic.Install.NT
        驱动程序级别： 0x802000
        匹配设备 ID： USB\USB20_HUB
        超限驱动程序：
        设备已更新： false
        父设备： USB\ROOT_HUB30\4&35627a0b&2&0


    - 2026-02-23 00:39:36 - 已启动设备
        已启动设备 USB\VID_1A40&PID_0101\5&213b2cfc&0&4。

        驱动程序名称: usbhub3.inf
        类 GUID: {36fc9e60-c465-11cf-8056-444553540000}
        服务: USBHUB3
        低层筛选程序:
        高层筛选程序:

====================
AI记录（2026-02-23）

已阅读当前记录（至 00:39:36 的设备事件）。根据你描述的复现规律：
- USB-C 口直连单设备多为正常（键盘、外置 SSD 可按 USB3 速率传输）；
- 但 USB-C 连接拓展坞后，拓展坞下游设备全部不可用；
- 手机在该 USB-C 口可充电但无法进入 USB 数据连接模式；
- 其他 USB-A 口连接手机可正常进入数据模式；
- 同一拓展坞+同一数据线连接其他电脑正常；
- 重启后问题持续可复现。

对设备管理器事件的初步解读：
- “设备设置未迁移（Present:false / 状态 0xC0000719）”常见于 Windows 升级/驱动栈重建后的历史迁移记录，本身不一定代表当前设备故障；
- 但结合“拓展坞不可用 + 手机仅充电不枚举”，更像是该 USB-C 所在链路出现“枚举/协商”相关问题（尤其是 USB2 通道或 Hub 枚举环节），或被电源管理/过滤驱动/控制器驱动状态影响。

后续排查优先级建议（按从易到难、从软件到硬件）：
1) 明确该 USB-C 端口属性：前置/后置？端口旁是否有 SS/10/20/40/⚡/DP 标识？（用于判断是否涉及 USB4/雷电/DP Alt 相关栈）
2) 抓“插拔拓展坞当下”的系统日志（比设备管理器事件更直接）：
   - 事件查看器 → Windows 日志 → 系统
   - 重点来源：Kernel-PnP、USBHUB3、DriverFrameworks-UserMode
   - 操作：拔掉拓展坞 → 重新插上 → 立即查看同一时间段的错误/警告/信息并记录（文本内容即可）
3) 若日志显示枚举失败/端口复位失败/设备描述符请求失败等，再进一步定位到：
   - USB 选择性挂起/电源管理导致端口进入异常状态
   - 芯片组/USB 控制器驱动（含厂商 Type-C 相关组件）异常或被替换
   - 第三方安全/虚拟化/USB 过滤驱动干预
   - 端口供电协商异常（拓展坞对 VBUS/电流/角色切换更敏感）

待补充信息（写入本记录中，便于后续推断）：
- 该 USB-C 是前置还是后置？端口标识是什么？
- 插上拓展坞时“系统日志”中 Kernel-PnP / USBHUB3 / DriverFrameworks 的实时事件内容（时间点、事件 ID、详细文本）。

====================
人工补充（2026-02-23）

1) 该 USB-C 口为后置端口，配置上写的是 USB3.2 Type-C。
2) 拔插拓展坞时，事件查看器（系统日志，级别包含“信息”）没有任何与 USB/设备枚举相关的日志打印；同一时间仅看到少量来自 WindowsUpdateClient 的信息。

====================
AI记录（2026-02-23）

基于新增信息的判断更新：
- 后置 USB3.2 Type-C（非明确 USB4/雷电口）→ 优先按“USB3 控制器/USB2 兼容通道/Hub 枚举”思路排查，不必先假设雷电/USB4 协议栈。
- 插拔拓展坞在“系统”日志完全无记录 → 不像常规的“设备已连接但驱动失败”，更像是：
  1) 端口对该拓展坞在连接阶段就未触发正常枚举（例如 USB2 D+/D- 通道未建立、CC 角色/电流协商异常导致设备未进入数据角色），或
  2) 相关事件没有进入系统日志（可能在专用日志通道/被关闭），或
  3) 设备瞬断（反复复位）导致你看到不到稳定事件。

下一步建议（优先做“能在本机直接采集”的证据，减少猜测）：
1) 用 USB 设备树工具查看实时拓扑（建议 USB Tree View / UsbTreeView 或 Windows SDK 的 USBView）：
   - 分别在“直连外置 SSD（正常）”与“连接拓展坞（异常）”两种情况下截图/导出：
     - 是否出现新的 Hub 节点（常见 Vendor: VIA/Genesys/Realtek 等）
     - 该端口的连接速度（HighSpeed/SuperSpeed）
     - 设备是否反复 Connect/Disconnect
2) 用 Windows 的“设备管理器 → 查看 → 按连接”观察：
   - 展开到“USB xHCI 兼容主机控制器 → USB 根集线器(USB 3.0)”
   - 插拔拓展坞时，树结构是否有任何变化（哪怕一瞬间）
3) 关闭可能影响枚举的省电策略（可回退）：
   - 设备管理器中对“USB Root Hub(USB 3.0)”和“通用 USB 集线器(如有)”取消勾选“允许计算机关闭此设备以节约电源”
   - 电源选项中临时关闭“USB 选择性暂停设置”
4) 收集更底层的枚举日志：
   - 开启“Microsoft-Windows-USB-USBHUB3/Operational”与“Microsoft-Windows-USB-UCX/Operational”（事件查看器 → 应用程序和服务日志 → Microsoft → Windows → USB*）
   - 重新插拔拓展坞后导出对应时间段事件。

需要你补充到本记录的关键信息（越精确越好）：
- 主板型号/芯片组（或联想整机的主板信息），以及是否近期有 Windows 大版本更新或芯片组驱动更新。
- 该拓展坞是否带外接供电（PD 充电器）？连接方式是“拓展坞自供电”还是“只靠主机供电”。
- 连接拓展坞时：拓展坞上的指示灯/网口灯是否有变化？拓展坞是否能对外供电？

====================
人工补充（2026-02-23）

- 尚未下载新软件；在设备管理器中“查看 → 按连接”观察：
  - 外接 SSD 时，USB 根集线器(USB 3.0) #2 会挂到“Intel(R) USB 3.20 可扩展主机控制器 - 1.20 (Microsoft)”下，且其下出现 SSD 设备；连接稳定，速度正常。
  - 插入拓展坞时系统“完全没有反应/无任何变化”。
- 进一步测试：插入拓展坞，并在拓展坞上插入手机时，手机连充电都不会有。
- 事件查看器 → 应用程序和服务日志 → Microsoft → Windows 下仅看到：USB-UCMUCSICX、USB-USBXHCI、USBVideo；不清楚如何开启我先前提到的 USBHUB3/UCX 日志。

====================
AI记录（2026-02-23）

基于最新现象的关键推断（优先级更靠近硬件/供电/协商链路）：
- SSD 能稳定枚举到 Intel xHCI 且速度正常 → 该后置 Type-C 口的 USB3 SuperSpeed 通道、主机控制器与驱动栈“大概率正常”。
- “插入拓展坞完全无反应”且“拓展坞接手机连充电都没有” → 这更像是端口与拓展坞之间在最早期阶段就失败：
  - 可能是 Type-C 的 CC 识别/供电策略（VBUS）未对该坞打开，导致坞本体不工作；
  - 或坞依赖 USB-C 的默认供电/PD 相关路径（某些坞不接外部电源时需要主机端提供更高电流或正确的 Rp/Rd 判断）；
  - 也可能是“你拿来接坞的这根 C-C 或 C-A 线材/转接链路”在当前端口上触发不了（但你之前说同线材+同坞在其他电脑正常，因此更可能是本机端口的 CC/供电策略变化或异常状态）。

关于你看到的日志通道：
- 你当前只看到 USB-USBXHCI / USB-UCMUCSICX / USBVideo 是正常的；不同 Windows 版本/组件安装状态下，USBHUB3/UCX 的 Operational 通道可能“默认不存在/被折叠/名称不同”。

下一步：不装新软件也能做的定位（建议按顺序做，尽量一次只改一个变量）
1) 先确认拓展坞供电形态与 PD：
   - 拓展坞是否有外接 PD 充电器口？
   - 若有：请分别测试「坞接 PD 电源」与「坞不接 PD 电源」两种情况下，插入该后置 Type-C 口，是否仍旧“完全无反应/无充电”。
   - 记录：坞指示灯、网口灯、HDMI 是否亮、手机是否充电。
2) 换一种连接组合（排除“端口对某种线材/方向敏感”）：
   - 同一根线翻转插头方向再试（Type-C 端子翻面）。
   - 换一根数据线（最好是已验证可传数据的全功能线），再试。
   - 如果这台机器还有其他 Type-C（例如前置），也用同一线同一坞对比。
3) 在设备管理器继续观察“按连接”的瞬时变化：
   - 展开 Intel(R) USB 3.20 xHCI → USB Root Hub(USB 3.0)
   - 插入拓展坞时哪怕出现/消失一瞬间的“USB Hub/Unknown USB Device”，也请记下名字（或截图）。

下一步：用系统自带命令把可用日志通道列出来（不依赖你手动找）
- 目标：列出所有包含 USBHUB/UCX/UCSI/XHCI 的事件通道名称，然后再对存在的通道启用 Operational。
- 推荐执行（管理员 PowerShell）：
  - `wevtutil el | findstr /i usb`（列出包含 usb 的日志通道）
  - 若看到类似 `Microsoft-Windows-USB-USBXHCI/Operational`、`...UCMUCSICX/Operational`：可用
    `wevtutil sl "<通道名>" /e:true` 启用。
- 你把 `wevtutil el | findstr /i usb` 的输出粘贴到本记录里，我再告诉你应启用哪些更有用。

如果以上测试显示“无论是否外接 PD、无论换线/翻转，拓展坞在该口都完全不供电”，而 SSD 仍正常：
- 需要重点怀疑：该 Type-C 口的 VBUS/电源开关或 CC 控制器/Type-C Port Controller 进入异常状态（固件/驱动/电源管理）或硬件故障。
- 软件侧可尝试的修复路径将集中在：芯片组驱动/ME/Type-C 相关组件重装、BIOS/EC 更新、关机断电后放电复位（断电+长按电源键）。

====================
人工补充（2026-02-23）

- 拓展坞有 PD 供电接口：此前未使用；刚才接入 PD 电源后再插电脑后置 Type-C：
  - 设备管理器里“闪了一下”，短暂出现了几个“通用 USB 集线器”，随后又闪一下并消失。
  - 目前未修改事件查看器设置，仍未看到明显信息输出。
  - 在“拓展坞接 PD 电源 + 插电脑后置 Type-C”情况下，拓展坞可以给手机充电。
- 数据线翻面已尝试过，对现象无影响。

====================
AI记录（2026-02-23）

对现象的关键更新：
- “接 PD 后能给手机充电” + “通用 USB 集线器短暂出现又消失” → 说明：
  1) 纯供电（VBUS）链路在接 PD 后是成立的；
  2) 枚举并非完全没有发生，而是很可能在某个阶段反复复位/崩溃式断开（典型表现就是设备树闪现）。
- 这进一步把嫌疑集中到：
  - 该 Type-C 口在面对“外接供电+Hub”的拓展坞时，发生端口复位风暴、供电策略/电流限制触发、或 USB2/设备描述符阶段失败；
  - 或者拓展坞的 Hub/下游设备拉起后瞬间过流/短时压降导致口保护断开（但因为 SSD 正常，可能是“仅在坞这种复杂负载/Hub”下触发）。

下一步最有效的证据采集（不装新软件）：把“闪现的那一下”变成可读日志
1) 启用你目前已经能看到的两个日志通道的 Operational（若存在）：
   - Microsoft → Windows → USB-USBXHCI → Operational（启用）
   - Microsoft → Windows → USB-UCMUCSICX → Operational（启用）
   启用后，重复一次“坞接 PD → 插后置 Type-C”，然后导出/复制这两个 Operational 中同一时间段的事件。

2) 同时查看 PnP 设备安装日志（很多时候比系统日志更有用）：
   - 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → DeviceSetupManager → Admin
   - 以及：Microsoft → Windows → Kernel-PnP → Configuration（若存在）
   关注是否出现：设备安装开始/失败、设备已移除、问题代码、容器 ID 等。

3) 在设备管理器做一次“抓瞬时设备名”的操作：
   - 视图改为“按连接”，展开到 Intel USB xHCI 下的根集线器
   - 用手机录屏（或连拍）捕捉闪现时出现的设备名称（例如 Unknown USB Device、USB Composite、Generic SuperSpeed Hub、Billboard Device 等）。记录出现过的名字即可。

快速修复尝试（低风险、对 Type-C 控制器异常状态常有效）：
4) 完整断电复位（台式机建议这样做）：
   - 关机 → 拔掉电源线 → 等待 30 秒
   - 长按机箱电源键 15–30 秒（放电）
   - 再插电开机后，先不要插其他 USB 复杂设备，只测试“后置 Type-C + 拓展坞(接 PD)”

后续若日志显示端口复位/描述符失败/过流：
- 再走驱动/固件路线：更新/重装 Intel 芯片组驱动、ME 组件、联想电源管理/USB 相关组件；检查 BIOS/EC 是否有更新。

====================
人工补充（2026-02-23）

DeviceSetupManager/Admin（11:22:08 附近）
- 事件ID 100（信息）：DSM 服务已启动，模式 Normal，上一个会话 72 秒前。
- 事件ID 30（信息）：设备容器 {18eaf965-7eca-5c7b-956c-6f78644d5109} 已排队等待安装。
- 事件ID 112（信息）：已为设备容器 'USB3.0 Card Reader' ({18eaf965-7eca-5c7b-956c-6f78644d5109}) 提供服务、处理 5 任务，并在 0 ms 中写入 0 属性。
- 事件ID 11（信息）：DSM 服务处于空闲状态，正在等待 stop。

补充：setupapi.dev.log 已复制到同目录（copilot_workspace\\usb_c_debug\\setupapi.dev.log）。

====================
AI记录（2026-02-23）

对你提供的 DeviceSetupManager/Admin 的解读：
- 这组 11:22:08 的记录只体现“某个设备容器（USB3.0 Card Reader）被排队/处理”，没有出现典型的“设备安装失败/问题代码/驱动匹配失败”等错误条目。
- 结合你前面描述“插坞/接 PD 会闪一下但最终消失”，更像是设备在更底层就掉线，DSM 没来得及进入稳定的安装失败流程。

我已读取当前目录下的 setupapi.dev.log（开头几百行）并发现：
- 目前日志片段主要是历史记录（2/21、2/22 晚间、2/23 凌晨）以及你手动在设备管理器做过的 USB Root Hub / 若干 USB 设备移除操作；
- 其中出现过多个 Hub/设备 VID/PID，例如：
  - `USB\VID_2109&PID_2817` / `USB\VID_2109&PID_4817` / `USB\VID_2109&PID_8817`（这类 VID=2109 常见于 VIA Labs 的 USB Hub/控制器，和很多拓展坞/读卡器链路相关）；
- 但在我已读取的片段中，尚未看到与“2026/02/23 11:22”时间窗口直接对应的 setupapi 记录（我用关键词搜索未命中该时间）。

下一步要把日志对齐到你刚刚测试的时间点（11:22 附近）：
1) 请在 setupapi.dev.log 里用查找（Ctrl+F）定位 `2026/02/23 11:` 或接近你复现的时间段；
2) 或者你再复现一次“先插电脑再接 PD（会闪烁）”，记下精确到秒的时间点，然后我们就抓该时间点附近的 setupapi block。

我们在 setupapi/devsetup 中要重点盯的关键词：
- `USB\\VID_2109`（Hub/坞相关）
- `USB\\ROOT_HUB30`、`xHCI`、`USBXHCI`
- `UCM` / `UCSI` / `Type-C`
- `Unknown USB Device` / `Device Descriptor Request Failed`
- `Port reset` / `over-current` / `CM_PROB_` / `Problem code`

只要在 11:22 附近抓到 1-2 个失败 block（包含设备实例路径和错误码），基本就能判断是“端口复位/描述符失败（多为链路/供电/兼容性/硬件）”还是“驱动/策略层失败（可通过重装组件解决）”。====================

====================
人工补充（2026-02-23）

- 已执行“触发变化的序列”（先插电脑 Type-C 再插 PD，会出现设备管理器闪烁/瞬时设备变化）。
- 但 setupapi.dev.log 文件完全没有发生更新，文件最后更新时间一直停留在 11:07。
- 提醒：需要把本轮对话内容也持续写入 communication_record.txt。

====================
AI记录（2026-02-23）

问题纠偏与当前关键点：
- 如果你确认复现时设备管理器确实发生了瞬时变化，但 setupapi.dev.log 的“文件时间戳完全不变”，优先怀疑不是“没有日志”，而是：
  1) 你正在查看/复制的是一份静态副本（而不是系统正在写入的那份原始日志），或
  2) 系统原始日志写入受限/被锁定/写入到其他位置（相对少见），或
  3) 你的复现并未触发 PnP 安装流程（仅发生 Type-C/供电状态变化，未进入设备安装阶段），因此 setupapi 不一定新增，但通常仍应有部分记录。

建议的验证动作（目标：确认“系统原始日志是否在写”）：
1) 直接核对系统原始路径的时间戳：
   - `C:\Windows\INF\setupapi.dev.log`（系统原始位置）
   - 以及你工作区副本：`D:\MyCodingProject\general_tools\copilot_workspace\usb_c_debug\setupapi.dev.log`
   若两者时间戳不同或只有系统原始文件在变，则说明你看的副本未刷新。

2) 用最朴素的方式验证末尾是否新增：
   - 复现一次“先插电脑 Type-C → 再插 PD（会闪烁）”
   - 立即打开 `C:\Windows\INF\setupapi.dev.log` 跳到文件末尾，查看是否新增 `>>>` 段落。

3) 如果系统原始 setupapi 也完全不更新：
   - 改抓“设备列表差分”这条证据链（例如使用 pnputil 枚举 connected devices），因为这类瞬时设备即使不触发安装，也会在枚举里出现/消失。

后续策略：
- 一旦确认“系统原始 setupapi”能更新，我们就以复现时间点为锚，抓取对应 `USB\VID_2109...` / `Unknown USB Device` / `ROOT_HUB30` 的 install/remove block。
- 若确认 setupapi 确实不写入，则转向 UCSI/Type-C 控制链路或供电状态机层面，用 UCMUCSICX / USBXHCI / 设备枚举差分来定位。

====================
人工补充（2026-02-23）

- 结论更新：系统原始 setupapi.dev.log 也完全不更新。
- 诉求：不知道如何执行后续操作，需要一步一步指导。

====================
AI记录（2026-02-23）

当 setupapi.dev.log（系统原始）也不更新时，说明问题很可能停留在“Type-C 供电/角色/连接状态机”或“极短暂的枚举闪断”阶段，Windows 的设备安装日志链路没有进入可记录的安装流程。

因此下一步改用两条更可靠的证据链：
A) 设备枚举差分（抓“闪现的设备实例 ID/VID/PID”）
B) 更贴近 Type-C/UCSI 的事件通道（UCM/UCSI/USBXHCI 等）

下面给出可直接照做的步骤（每一步只做一件事，做完把结果贴回本记录）：

步骤 1：准备复现条件（用于稳定触发“闪烁”）
- 按你已验证最容易触发变化的顺序：先把拓展坞的 Type-C 数据线插到电脑后置 Type-C（此时不接 PD），然后再把 PD 电源插到拓展坞（触发设备管理器闪烁）。

步骤 2：用 PowerShell 采集“连接设备列表”（复现前）
- 以管理员打开 PowerShell。
- 执行：`pnputil /enum-devices /connected | findstr /i "USB\\ VID_ PID_"`
- 将输出全文复制保存（命名为 BEFORE）。

步骤 3：复现闪烁
- 立刻按步骤 1 的顺序操作一次（触发设备管理器闪一下）。

步骤 4：再次采集“连接设备列表”（复现后）
- 回到 PowerShell 再执行同一条命令：
  `pnputil /enum-devices /connected | findstr /i "USB\\ VID_ PID_"`
- 将输出全文复制保存（命名为 AFTER）。

步骤 5：对比 BEFORE/AFTER
- 重点找 AFTER 里新增或消失的条目，尤其是：
  - `USB\VID_2109&PID_....`（拓展坞 Hub 常见）
  - `Unknown USB Device`（如果能枚举到名字）
  - 任意 `USB\VID_xxxx&PID_yyyy` 新出现又消失
- 把“新增/消失的那几行”贴出来即可，不需要全量。

步骤 6：补抓 DeviceSetupManager/Admin（即使只有信息也要）
- 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → DeviceSetupManager → Admin
- 复现一次闪烁后，刷新并将同一时间点附近新增事件贴出来。

步骤 7（可选但很有价值）：抓 USB-UCMUCSICX / USB-USBXHCI Operational
- 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → USB-UCMUCSICX → Operational
- 以及：Microsoft → Windows → USB-USBXHCI → Operational
- 复现闪烁后，刷新并粘贴新增事件。

执行到步骤 5 后，我们基本就能拿到“闪现设备的 VID/PID/实例路径”，才能进一步判断：
- 是 Hub 被识别但立刻断开（偏供电/保护/兼容），还是
- 根本没能建立稳定数据角色（偏 UCSI/Type-C 控制器/驱动/固件）。====================

====================
人工补充（2026-02-23）

- 已执行步骤 1-4，抓取到 BEFORE/INPROGRESS/AFTER 三个阶段的 pnputil 结果。
- 现象：插入拓展坞后，设备管理器会闪烁一下，随后恢复正常（无拓展坞设备）。
- 注意：拓展坞接入 PD 电源后，拓展坞上的指示灯会亮起。

====================
AI记录（2026-02-23）

已分析你保存的 3 次抓取（BEFORE / INPROGRESS / AFTER）。结论非常明确：

1) BEFORE 与 AFTER：几乎完全一致
- 说明“最终稳定状态”下，拓展坞链路并没有保持连接（即没有把 Hub/网卡/读卡器等作为已连接设备留在系统里）。

2) INPROGRESS 相比 BEFORE/AFTER：新增了一组典型“拓展坞内部器件”实例 ID（但只在中间瞬时出现）
新增项包括：
- `USB\VID_2109&PID_2817\MSFT20000000000`
- `USB\VID_2109&PID_1817\MSFT30000000000`
- `USB\VID_2109&PID_0817\MSFT30000000000`
  说明：这是拓展坞内部的 USB Hub 链路（VID=2109 常见于 VIA Labs，很多拓展坞使用）。

- `USB\VID_0BDA&PID_8153\000001`
  说明：Realtek USB 千兆网卡（RTL8153 系列非常常见）。

- `USB\VID_05E3&PID_0749\000000001539`
  说明：Genesys Logic 的 Hub/读卡器相关控制器（很多拓展坞/读卡器会出现 05E3）。

=> 这证明：在你执行“先插电脑再插 PD（会闪）”的序列时，拓展坞不是完全无响应，而是：
- 设备确实被枚举出来了（Hub + 网卡 + 读卡器/Hub 组件都出现过）
- 但随后整条链路又掉线（因此 AFTER 里看不到它们）。

3) 现象定位：不是驱动缺失，而是“枚举后立即断连（闪断）”
- 这些 VID/PID 都是 Windows 自带驱动可识别的通用设备（USB Hub / Realtek 8153 / Genesys 控制器），若是单纯驱动问题通常会留下“Unknown device/带问题代码”的连接痕迹。
- 现在的模式更像：端口复位/供电策略/过流保护/Type-C 状态机导致链路重置，导致所有下游设备瞬时出现又消失。

下一步最小验证（只做 2 件事即可进一步定性）：
A) 复现闪断时，同时只让“拓展坞空载”（不要插手机/硬盘/键鼠），并保持拓展坞接 PD：
- 目标：排除下游负载触发过流/压降。
- 看是否仍会出现 INPROGRESS 里的同一组 VID/PID 闪现。

B) 如果空载仍闪断：优先走固件/驱动/电源管理侧
- 检查并更新：联想 Vantage / 官网提供的 BIOS/EC、芯片组驱动、Intel ME、以及与 Type-C/UCSI 相关组件。
- 在设备管理器“系统设备”里找到类似 “UCSI / USB Connector Manager / Type-C Port Controller” 的设备，记录其驱动提供商/版本/日期（用于判断是否发生过更新/回退）。

（补充）如果你能再抓一次“空载 + 接 PD + 闪断”的 BEFORE/INPROGRESS/AFTER，我们可以确认是否为“下游设备启动导致掉线”还是“仅 Hub 链路就不稳定”。
====================
人工补充（2026-02-23）

- 复现抓取（BEFORE/INPROGRESS/AFTER）时，拓展坞确实是空载状态。
- 此前已尝试更新所有能找到的驱动，包括：芯片组、BIOS、Intel Serial IO 等；仍无改善。

====================
AI记录（2026-02-23）

在“空载仍闪断 + BIOS/芯片组/Serial IO 已更新”的前提下，优先级从“常规驱动缺失”进一步转向以下几类：

1) Type-C/UCSI 控制链路或端口供电/保护策略异常（软件状态或硬件级）
- 证据：Hub+网卡+读卡器等能同时闪现，说明坞已上电且可枚举；但随后整条链路被重置/断开。

2) 第三方过滤驱动/安全软件/虚拟化组件干预 USB 栈（会导致枚举后立刻移除）
- 你日志里曾出现 spacedesk 相关服务操作；这类软件有时会插入过滤层。

3) Windows 电源管理/选择性挂起/端口复位风暴
- 尤其是“先连电脑再上 PD 才会触发闪断”模式，像是协商状态机切换触发的复位。

下一步建议（尽量都可回退，且每步只改一个变量）：
A) 检查并临时禁用第三方 USB 相关过滤驱动（无须卸载软件）
- 设备管理器 → 查看“按驱动程序”或在设备属性中查看是否有 UpperFilters/LowerFilters（尤其在 USB、WPD、Net、HID 类）。
- 若你装有：虚拟网卡/屏幕投送/手机助手/某些安全软件，建议做一次“干净启动”验证：
  - msconfig → 服务：勾选“隐藏所有 Microsoft 服务”→ 全部禁用；启动项全部禁用；重启后只测试拓展坞。

B) USB 控制器与 UCSI 设备重装（让 Windows 重新枚举端口控制器）
- 设备管理器：
  - 在“通用串行总线控制器”下，对 Intel(R) USB 3.20 xHCI 兼容主机控制器、USB Root Hub(USB 3.0) 逐个“卸载设备”（不要勾选删除驱动），重启让系统自动重装。
  - 在“系统设备”下找到 UCSI/USB Connector Manager/Type-C Port Controller（名称可能不同），同样可尝试卸载后重启。

C) 电源管理彻底关闭（用于验证是否为省电导致的复位/掉线）
- 电源选项：USB 选择性暂停 = 禁用。
- 设备管理器：对所有 USB Root Hub(USB 3.0) 取消“允许计算机关闭此设备以节约电源”。

D) 如果以上软件侧验证均无变化：倾向硬件层（端口的 CC/供电开关/保护电路）
- 由于该口对 SSD 正常、对复杂 Hub 链路闪断，典型是端口在“多设备/Hub 拉起”时触发保护或协商异常。
- 此时较实用的最终验证是：
  - 用同主板的其他 Type-C（若有）对比；或
  - 使用带独立供电、且对上游兼容性更强的不同型号拓展坞/Type-C Hub 交叉验证；
  - 若仅此口对所有 Hub/坞均闪断，而直连设备正常，则可基本判定该 Type-C 口的相关硬件链路存在问题。