update
This commit is contained in:
Binary file not shown.
@@ -1,180 +0,0 @@
|
|||||||
====================
|
|
||||||
人工输入（2026-01-16）
|
|
||||||
====================
|
|
||||||
|
|
||||||
|
|
||||||
我的windows11电脑遇到了一个非常偶发的卡死问题，接下来你需要和我一起尝试定位解决这个问题。你需要把你的发言也记录在这篇文档内，以便后续查阅。
|
|
||||||
以下是我遇到的问题以及我尝试过的解决方案
|
|
||||||
我的电脑是一台联想拯救者刃9000k 2023，搭载RTX 4090, i9-13900KF，z690主板
|
|
||||||
最近半年左右，电脑会偶发的出现黑屏卡死的问题。表现为，从睡眠/休眠/息屏状态下敲击键盘或者移动鼠标尝试唤醒的时候，有一定概率会卡在正在锁定的界面上。此时画面会完全卡死，双屏显示器中，主显示器卡在正在锁定的转圈界面，副显示器直接失去信号输入。
|
|
||||||
此时，键盘的Caps Lock键是没有反应的（正常状态下Caps Lock键应该按下以后会显示是否开启大写锁定，所以我认为这可能是一个重要的信号，但我不知道这意味着什么）
|
|
||||||
在这个状态下如果我不做任何操作，电脑会一直卡死在这个状态下，电脑上安装的机械硬盘持续仍然在工作，风扇也在转，但是不会有任何响应。唯一的方法就是长按电源键强制重启
|
|
||||||
在强制重启完成以后查看windows事件查看器，找不到任何有用的信息，只能看到一个非正常关机的报错。
|
|
||||||
我当前尝试过的操作包括：
|
|
||||||
1. 关闭了快速启动
|
|
||||||
2. 把我的windows版本更新到了最新版本
|
|
||||||
3. 重装了电源管理驱动
|
|
||||||
4. 在卡死状态下通过长按win+ctrl+shift+B尝试重启显卡驱动，没有成功
|
|
||||||
|
|
||||||
在卡死状态下，尝试通过windows自带的远程桌面进入系统，会一直卡在正在配置远程电脑这一步，看起来像是初始的网络连接已经建立成功，但是电脑在某个阶段没有响应导致一直卡在这里。我之前遇到过一次，还没有卡死的情况下直接远程到这台电脑，成功建立远程连接，然后我关闭远程连接，尝试将其从息屏状态下唤醒，就卡死了，然后再尝试远程桌面，就卡在配置远程电脑这一步了
|
|
||||||
|
|
||||||
因为这个卡死是一个偶发的问题，我也不能100%复现，所以非常头疼，我需要你的帮助
|
|
||||||
|
|
||||||
|
|
||||||
====================
|
|
||||||
Copilot 记录（2026-01-16）
|
|
||||||
====================
|
|
||||||
|
|
||||||
【我对现象的结构化归纳】
|
|
||||||
- 设备：拯救者刃9000k 2023；RTX 4090 + i9-13900KF + Z690；双显示器。
|
|
||||||
- 触发场景：从“睡眠/休眠/息屏”被键鼠唤醒时，有概率卡在锁屏“正在锁定/转圈”界面；副屏无信号。
|
|
||||||
- 卡死特征：Caps Lock 指示无响应（倾向于系统/输入栈整体失去调度，而非单纯显示问题）；风扇/机械盘仍工作；只能硬关机。
|
|
||||||
- 复现后：事件查看器几乎只有非正常关机；Win+Ctrl+Shift+B 无效；RDP 连接会卡在“正在配置远程电脑”。
|
|
||||||
|
|
||||||
【初步判断（先不下结论）】
|
|
||||||
这更像“唤醒路径上的系统级挂起”：可能发生在 GPU/显示驱动恢复、PCIe/电源管理、或会话/锁屏相关组件恢复阶段。副屏掉信号 + Win 图形重置快捷键无效 + RDP 卡住，说明不只是显示器‘没亮’，而是系统在较早阶段就僵住了。
|
|
||||||
|
|
||||||
【下一步目标】
|
|
||||||
因为问题偶发且当前日志不足，我们优先做两件事：
|
|
||||||
1) 明确你机器当前到底在用哪种睡眠/待机模型（S3 vs 现代待机 S0），以及究竟是“睡眠/休眠/仅息屏”哪一种更相关；
|
|
||||||
2) 配置并采集“下一次发生时/发生后”的证据（电源与唤醒报告、关键事件日志、GPU LiveKernelReports、可靠性历史），让我们能定位到具体链路。
|
|
||||||
|
|
||||||
【我需要你回答的 3 个关键信息（尽量精确）】
|
|
||||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
|
||||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
|
||||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
|
||||||
|
|
||||||
（下一条我会给出一套可执行的数据采集步骤，并在工作区提供一键导出脚本；你运行后把生成的压缩包里关键信息贴回来即可。）
|
|
||||||
|
|
||||||
|
|
||||||
====================
|
|
||||||
Copilot 记录：证据采集方案（2026-01-16）
|
|
||||||
====================
|
|
||||||
|
|
||||||
【采集原则】
|
|
||||||
- 先做一次“基线采集”（现在电脑正常时做）；下次复现卡死并强制重启后，立刻再做一次“复现后采集”。
|
|
||||||
- 复现后采集重点是：最后一次进入睡眠/唤醒、显示驱动恢复、内核电源事件、WHEA 硬件错误、以及是否生成 LiveKernelReports。
|
|
||||||
|
|
||||||
【手动采集（你可以先不等脚本，直接跑这些命令）】
|
|
||||||
请用“管理员 PowerShell”依次执行（每条单独一行）：
|
|
||||||
|
|
||||||
1) 查看系统支持的睡眠模型（非常关键）
|
|
||||||
- `powercfg /a`
|
|
||||||
|
|
||||||
2) 生成睡眠/唤醒诊断报告（适用于大多数机器）
|
|
||||||
- `powercfg /systemsleepdiagnostics`
|
|
||||||
|
|
||||||
3) 查看最近一次唤醒来源
|
|
||||||
- `powercfg /lastwake`
|
|
||||||
|
|
||||||
4) 检查是否存在阻止睡眠/唤醒的请求
|
|
||||||
- `powercfg /requests`
|
|
||||||
|
|
||||||
5) 若你的机器支持“现代待机 S0”，再额外生成 SleepStudy
|
|
||||||
- `powercfg /sleepstudy`
|
|
||||||
|
|
||||||
【需要你回传/提供的结果】
|
|
||||||
- 把 `powercfg /a` 的输出原文贴到这里（它会告诉我们是 S3 还是 S0）。
|
|
||||||
- `powercfg /systemsleepdiagnostics` 和（如有）`powercfg /sleepstudy` 生成的报告文件路径与文件本身（之后我会让脚本自动打包）。
|
|
||||||
|
|
||||||
【复现后必查的目录（强烈建议）】
|
|
||||||
- `C:\Windows\LiveKernelReports\`（特别是 `WATCHDOG`、`DISPLAY`、`PoW32kWatchdog` 等子目录）
|
|
||||||
- 如果这里出现新的 `.dmp`，通常对定位 GPU/显示/电源路径很有帮助。
|
|
||||||
|
|
||||||
【事件日志导出（复现后优先做）】
|
|
||||||
先不要求你手工导出全部；你只需要告诉我以下几个日志里是否出现“黄色/红色”的关键事件（脚本会自动导出更完整的）：
|
|
||||||
- 事件查看器 → Windows 日志 → 系统：
|
|
||||||
- 重点来源：`Kernel-Power`、`Kernel-Boot`、`Power-Troubleshooter`、`Display`、`WHEA-Logger`、`volmgr`
|
|
||||||
- 事件查看器 → 应用程序和服务日志 → Microsoft → Windows：
|
|
||||||
- 重点：`DxgKrnl`、`DriverFrameworks-UserMode`、`Kernel-PnP`
|
|
||||||
|
|
||||||
【一个重要解释：Caps Lock 无响应意味着什么】
|
|
||||||
Caps Lock 灯不切换通常表示：系统已经严重挂起/中断风暴/内核死锁等，连键盘输入处理都无法及时响应；这比“仅显示黑屏”更偏向系统级冻结。
|
|
||||||
|
|
||||||
下一步我会在工作区加一个一键采集脚本：自动收集上述报告、关键事件日志、LiveKernelReports、驱动与版本信息，并打包成 zip，方便你每次复现后直接发我分析。
|
|
||||||
|
|
||||||
|
|
||||||
====================
|
|
||||||
Copilot 记录：一键采集脚本（2026-01-16）
|
|
||||||
====================
|
|
||||||
|
|
||||||
我已在工作区新增脚本：
|
|
||||||
- `Copilot_id_card\tools\collect-freeze-diag.ps1`
|
|
||||||
|
|
||||||
【如何运行（推荐：管理员 PowerShell）】
|
|
||||||
在 `d:\CodingProject\AI_Playground\Copilot_id_card` 目录下执行：
|
|
||||||
- `powershell -ExecutionPolicy Bypass -File .\tools\collect-freeze-diag.ps1`
|
|
||||||
|
|
||||||
可选参数：
|
|
||||||
- `-RecentDays 30`（默认 14，控制收集最近多少天的 LiveKernelReports 文件）
|
|
||||||
|
|
||||||
【产物】
|
|
||||||
- 输出目录：`Copilot_id_card\diag_out\freeze-时间戳\`
|
|
||||||
- 同目录会生成一个 zip：`freeze-时间戳.zip`
|
|
||||||
|
|
||||||
【你需要给我的内容】
|
|
||||||
- 直接把生成的 `freeze-*.zip` 发我（或把其中 `powercfg-a.txt`、`system-last600.txt`、以及 `LiveKernelReports` 里新增的文件信息贴出来）。
|
|
||||||
|
|
||||||
【注意】
|
|
||||||
- 不用等复现，现在先跑一次当“基线”；下次卡死强制重启后再跑一次当“复现后样本”。两份 zip 对比非常关键。
|
|
||||||
|
|
||||||
|
|
||||||
====================
|
|
||||||
Copilot 记录：逐步排除清单（2026-01-16）
|
|
||||||
====================
|
|
||||||
|
|
||||||
【操作纪律】
|
|
||||||
- 一次只改 1 项；至少观察 3-7 天或经历若干次睡眠/唤醒循环。
|
|
||||||
- 每改一次，跑一次 `collect-freeze-diag.ps1` 留存样本（便于回滚与对比）。
|
|
||||||
|
|
||||||
【第 0 步：先确定睡眠模型与触发面】
|
|
||||||
- 先执行并贴出：`powercfg /a`
|
|
||||||
- 如果显示支持/正在用 S0（现代待机），后续排查路径会偏向“现代待机 + 驱动恢复”。
|
|
||||||
- 如果是 S3，路径会偏向“传统睡眠恢复 + PCIe/显卡/多屏握手”。
|
|
||||||
|
|
||||||
【低风险（优先）】
|
|
||||||
1) BIOS/固件与主板驱动
|
|
||||||
- 更新到联想/主板最新 BIOS；同时更新 Intel ME（管理引擎）与芯片组驱动。
|
|
||||||
- 验证：更新后连续多次睡眠/唤醒是否仍复现；并查看复现后样本里是否出现 WHEA 相关事件。
|
|
||||||
|
|
||||||
2) NVIDIA 驱动“干净重装”并做版本对照
|
|
||||||
- 用 DDU（安全模式）卸载后，安装一个明确版本做对照：优先尝试 Studio Driver（或换到相邻的大版本）。
|
|
||||||
- 验证：复现概率是否变化；复现后 `DxgKrnl/Display` 是否出现新的错误；`LiveKernelReports` 是否新增。
|
|
||||||
|
|
||||||
3) Windows 图形相关开关（可逆）
|
|
||||||
- 关闭 HAGS：设置 → 系统 → 显示 → 图形 → 默认图形设置 → 关闭“硬件加速 GPU 调度”。
|
|
||||||
- 如仍复现，再考虑关闭 MPO（多平面叠加）：我建议等我们先拿到一次样本后再做，避免变量过多。
|
|
||||||
|
|
||||||
4) 电源计划里禁用容易引发唤醒问题的省电项（可回滚）
|
|
||||||
- 控制面板 → 电源选项 → 高级设置：
|
|
||||||
- “睡眠”：关闭“混合睡眠”（若开启）；
|
|
||||||
- “PCI Express”：将“链接状态电源管理”设为“关闭”；
|
|
||||||
- “USB 设置”：将“USB 选择性暂停”设为“已禁用”。
|
|
||||||
|
|
||||||
【中风险（需要更谨慎）】
|
|
||||||
5) 多显示器链路排除
|
|
||||||
- 临时只接主屏使用一段时间，或更换 DP/HDMI 线材与接口（避免转接头/延长线）；
|
|
||||||
- 若显示器支持，尝试关闭 DSC/降低刷新率做对照（仅用于定位）。
|
|
||||||
|
|
||||||
6) 稳定性与超频因素
|
|
||||||
- 若有开启 XMP/CPU 自动超频/显卡超频，建议先回到默认（特别是 WHEA 有记录时）。
|
|
||||||
|
|
||||||
【高风险/最后手段（我们拿到证据后再决定）】
|
|
||||||
7) 配置更强的“卡死取证”（例如强制触发转储/更激进的验证器）
|
|
||||||
- 这类手段可能影响日常使用与稳定性，建议等我们先从日志判断方向再上。
|
|
||||||
|
|
||||||
【你现在可以做的两件事（最有效）】
|
|
||||||
1) 运行一次脚本生成“基线 zip”；
|
|
||||||
2) 把 `powercfg /a` 输出 + 你显示器连接方式（DP/HDMI/是否转接）+ BIOS 与 NVIDIA 驱动版本 回到这份文档里。
|
|
||||||
|
|
||||||
====================
|
|
||||||
人工输入（2026-01-16）
|
|
||||||
====================
|
|
||||||
我现在没在我那台故障的机器跟前，我会尽可能先回答你的问题，但是暂时没办法做测试。我们先收集我已知的信息并尝试确定定位解决方向，等到我可以操作故障的机器了我会通知你。
|
|
||||||
关于你需要我回答的三个问题：
|
|
||||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
|
||||||
我无法确认这三者哪个更容易出问题，看起来三者都有可能故障。不过我最常用的状态是息屏和休眠。休眠是我通过powercfg -h on来开起来的，我也不知道是那种。
|
|
||||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
|
||||||
我的两台显示器分别通过HDMI和DP连接到4090上，没有经过任何扩展坞/转接头/延长线。我尝试把这两台显示器调换过，也没能解决息屏问题。
|
|
||||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
|
||||||
我暂时看不到这些信息，但我需要你提供如何查看这些信息的step-by-step指引。
|
|
||||||
@@ -18,207 +18,318 @@
|
|||||||
|
|
||||||
因为这个卡死是一个偶发的问题，我也不能100%复现，所以非常头疼，我需要你的帮助
|
因为这个卡死是一个偶发的问题，我也不能100%复现，所以非常头疼，我需要你的帮助
|
||||||
====================
|
====================
|
||||||
|
AI记录（2026-01-22）
|
||||||
|
|
||||||
|
已阅读当前文档内容：目前记录仅包含 2026-01-16 的一次人工描述与已尝试措施。现问题“刚刚又出现一次”，但文档尚未记录本次复现的时间点、当时电源状态（睡眠/休眠/仅息屏）、以及是否有新增的系统日志/症状。
|
||||||
|
|
||||||
====================
|
初步判断要点（基于已有描述）：
|
||||||
Copilot 记录（2026-01-16）
|
1) “Caps Lock 无反应”通常意味着系统在更底层已失去调度（可能为内核/驱动级卡死），而不仅是图形界面假死；也可能是输入堆栈/中断被阻塞。
|
||||||
|
2) 副屏无信号 + 主屏停在锁屏转圈，且 Win+Ctrl+Shift+B 无法恢复，提示可能涉及：显卡驱动/显示链路在唤醒路径失败、Modern Standby/睡眠唤醒路径中的设备电源状态切换异常、或某个内核驱动死锁。
|
||||||
|
3) 远程桌面“正在配置远程电脑”卡住，说明网络握手可能建立，但目标机在登录/会话初始化阶段无响应（与系统级卡死一致）。
|
||||||
|
|
||||||
【我对现象的结构化归纳】
|
下一步目标：把“偶发”变成“可定位”，优先收集一次卡死前后 5~10 分钟的可关联证据。
|
||||||
- 设备：拯救者刃9000k 2023；RTX 4090 + i9-13900KF + Z690；双显示器。
|
|
||||||
- 触发场景：从“睡眠/休眠/息屏”被键鼠唤醒时，有概率卡在锁屏“正在锁定/转圈”界面；副屏无信号。
|
|
||||||
- 卡死特征：Caps Lock 指示无响应（倾向于系统/输入栈整体失去调度，而非单纯显示问题）；风扇/机械盘仍工作；只能硬关机。
|
|
||||||
- 复现后：事件查看器几乎只有非正常关机；Win+Ctrl+Shift+B 无效；RDP 连接会卡在“正在配置远程电脑”。
|
|
||||||
|
|
||||||
【初步判断（先不下结论）】
|
A. 立刻补充的记录项（请在每次发生后追加到本文档）
|
||||||
这更像“唤醒路径上的系统级挂起”：可能发生在 GPU/显示驱动恢复、PCIe/电源管理、或会话/锁屏相关组件恢复阶段。副屏掉信号 + Win 图形重置快捷键无效 + RDP 卡住，说明不只是显示器‘没亮’，而是系统在较早阶段就僵住了。
|
- 发生时间（精确到分钟）
|
||||||
|
- 发生前状态：睡眠/休眠/仅关闭显示器/锁屏后待机（以及持续了多久）
|
||||||
|
- 唤醒方式：键盘/鼠标/电源键/定时器/网络唤醒
|
||||||
|
- 现象细节：主屏内容、分辨率是否变化、副屏是“无信号”还是黑屏有背光
|
||||||
|
- 机器指示：键盘灯、NumLock/CapsLock、机箱电源灯、硬盘灯、风扇转速是否明显变化
|
||||||
|
- 是否插拔过外设/USB扩展坞/VR设备/采集卡等
|
||||||
|
|
||||||
【下一步目标】
|
B. 建议立刻做的“取证型设置”（为下一次复现做准备）
|
||||||
因为问题偶发且当前日志不足，我们优先做两件事：
|
1) 启用/检查系统转储（用于驱动/内核死锁分析）
|
||||||
1) 明确你机器当前到底在用哪种睡眠/待机模型（S3 vs 现代待机 S0），以及究竟是“睡眠/休眠/仅息屏”哪一种更相关；
|
- 系统属性 → 启动和故障恢复：写入调试信息建议至少“自动内存转储”（或“内核内存转储”）。
|
||||||
2) 配置并采集“下一次发生时/发生后”的证据（电源与唤醒报告、关键事件日志、GPU LiveKernelReports、可靠性历史），让我们能定位到具体链路。
|
- 确认页面文件存在且足够（通常需位于系统盘）。
|
||||||
|
2) 可靠性监视器定位崩溃/硬件错误线索
|
||||||
|
- 查看“可靠性历史记录”，重点关注：Windows 错误报告、硬件错误（WHEA）、显示驱动重启等。
|
||||||
|
3) 事件查看器重点频道（下次按时间点回溯）
|
||||||
|
- Windows 日志：系统（Kernel-Power 41、BugCheck、Display、WHEA-Logger）
|
||||||
|
- 应用程序和服务日志：Microsoft-Windows-Kernel-PnP/Configuration、Power-Troubleshooter
|
||||||
|
4) 生成/保存电源与唤醒报告（事后分析用）
|
||||||
|
- powercfg /systemsleepdiagnostics（睡眠诊断）
|
||||||
|
- powercfg /sleepstudy（如果设备支持 Modern Standby）
|
||||||
|
- powercfg /lastwake（最近一次唤醒来源）
|
||||||
|
|
||||||
【我需要你回答的 3 个关键信息（尽量精确）】
|
C. 下一次卡死时（在保证安全前提下）可尝试的操作（按优先级）
|
||||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
1) 等待 60~120 秒观察是否自动恢复（某些驱动超时会自行回滚）。
|
||||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
2) 若键盘仍有响应：尝试 Ctrl+Alt+Del（看是否能切到安全桌面）。
|
||||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
3) 仍无反应：记录现象后再强制重启（避免反复硬断电）。
|
||||||
|
|
||||||
（下一条我会给出一套可执行的数据采集步骤，并在工作区提供一键导出脚本；你运行后把生成的压缩包里关键信息贴回来即可。）
|
D. 需要你立刻回答的 6 个关键问题（用于缩小范围）
|
||||||
|
1) “刚刚那次”发生前，电脑处于：睡眠/休眠/仅息屏/锁屏？
|
||||||
|
2) 你是否使用了 HDR、G-Sync/VRR、多显示器不同刷新率（例如 4K144 + 2K60）？
|
||||||
|
3) 显示器连接方式：HDMI/DP？是否有 DP 线材/转接头/延长线？
|
||||||
|
4) BIOS 与显卡驱动版本（大概即可），以及是否开启了 HAGS（硬件加速 GPU 调度）？
|
||||||
|
5) 是否开启了“允许网络唤醒/USB唤醒/快速启动/现代待机”中的任何一项（快速启动已关闭，其他待确认）？
|
||||||
|
6) 强制重启后，“可靠性监视器”在对应时间点是否出现硬件错误或显示驱动相关条目？
|
||||||
|
|
||||||
|
（后续计划）
|
||||||
|
- 若能拿到一次 BugCheck/转储文件：优先走“驱动/死锁”方向。
|
||||||
|
- 若完全没有 BugCheck 且仅 Kernel-Power 41：优先走“睡眠唤醒链路/BIOS/显示链路/电源策略”方向，并通过 powercfg 报告与事件日志交叉验证。
|
||||||
====================
|
====================
|
||||||
|
|
||||||
====================
|
====================
|
||||||
Copilot 记录：证据采集方案（2026-01-16）
|
人工输入（2026-01-22）
|
||||||
|
刚刚的这次卡死，
|
||||||
|
A.
|
||||||
|
- 发生在2026年1月22日晚上20点28分。
|
||||||
|
- 发生前的状态是正在从休眠中唤醒，之前休眠了大约24小时。
|
||||||
|
- 唤醒的方式是通过电源键。
|
||||||
|
- 主副屏分辨率都没有发射变化。副屏幕是亮起来了一小下，然后就变成无信号输入了。主屏出现了正在锁定的转圈，但是连转圈都卡死了
|
||||||
|
- 键盘灯亮起，CapsLock键没有反应，机箱电源灯常亮，硬盘灯持续闪烁，风扇转速没有明显变化
|
||||||
|
- 没有插拔过任何外设
|
||||||
|
|
||||||
【采集原则】
|
B.
|
||||||
- 先做一次“基线采集”（现在电脑正常时做）；下次复现卡死并强制重启后，立刻再做一次“复现后采集”。
|
1) 系统转储已经启用，设置为自动内存转储
|
||||||
- 复现后采集重点是：最后一次进入睡眠/唤醒、显示驱动恢复、内核电源事件、WHEA 硬件错误、以及是否生成 LiveKernelReports。
|
2) 可靠性历史记录中记录了如下信息：
|
||||||
|
<Event>
|
||||||
|
<Time>2026-01-22T20:31:28.420</Time>
|
||||||
|
<Impact>关键</Impact>
|
||||||
|
<Source>Windows</Source>
|
||||||
|
<Problem>Windows 停止工作</Problem>
|
||||||
|
</Event>
|
||||||
|
<Event>
|
||||||
|
<Time>2026-01-22T20:31:29.531</Time>
|
||||||
|
<Impact>关键</Impact>
|
||||||
|
<Source>Windows</Source>
|
||||||
|
<Problem>Windows 未正常关闭</Problem>
|
||||||
|
</Event>
|
||||||
|
3) 事件查看器节选以下记录：
|
||||||
|
2026/1/22 20:26:40 信息 系统启动时间为 413599 秒。
|
||||||
|
2026/1/22 20:26:41 警告 发生了已更正的硬件错误。 组件: PCI Express Root Port 错误源: Advanced Error Reporting (PCI Express)
|
||||||
|
2026/1/22 20:26:41 信息 系统会话已从10转换为 11. 原因 SxTransition BootId： 32
|
||||||
|
2026/1/22 20:26:42 警告 NtpClient 无法将手动对等机设置为用作时间源，因为“time.windows.com,0x9”上出现 DNS 解析错误。NtpClient 将在 15 分钟后重试，此后重试间隔增加一倍。错误为: 不知道这样的主机。 (0x80072AF9)
|
||||||
|
2026/1/22 20:26:43 信息 系统会话已从11转换为 13.
|
||||||
|
2026/1/22 20:27:53 错误 服务器 Microsoft.YourPhone_1.25112.36.0_x64__8wekyb3d8bbwe!App.AppXn958k7nsj8mxxmsepqdam8xk948t30sc.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:27:53 错误 服务器 Microsoft.BingWeather_4.54.63029.0_x64__8wekyb3d8bbwe!App.AppXydmptpzm8pts0mhzrytvzy52ye9x3ttq.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:27:53 错误 服务器 Microsoft.WindowsStore_22511.1401.6.0_x64__8wekyb3d8bbwe!App.AppXbes12ecwhvvewxbmkmnasc9amnxfsx1c.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:27:53 错误 服务器 Microsoft.WindowsFeedbackHub_1.2512.16303.0_x64__8wekyb3d8bbwe!App.AppX8a6w88secebzyje9nrqc47xt488tkbmc.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:27:53 错误 服务器 Microsoft.XboxGamingOverlay_7.325.11061.0_x64__8wekyb3d8bbwe!App.AppXpa8c6rgd3yzmnwb7kznbz0y2c2tmedk3.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:27:53 错误 服务器 MicrosoftWindows.Client.OOBE_1000.26100.28.0_x64__cw5n1h2txyewy!OobeHost.AppX57bnpdhb2y2keeh7gnjg18wys2747njp.mca 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:28:18 错误 服务器 {338B40F9-9D68-4B53-A793-6B9AA0C5F63B} 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:29:51 信息 NIC C08CB7B8-9B3C-408E-8E30-5E16A3AEB445 successfully disconnected from port .
|
||||||
|
2026/1/22 20:29:53 错误 服务器 Microsoft.AAD.BrokerPlugin_1000.19580.1000.2_neutral_neutral_cw5n1h2txyewy!Windows.Security.Authentication.Web.Core.BackgroundGetTokenTask.ClassId.WebAccountProvider 没有在要求的超时时间内向 DCOM 注册。
|
||||||
|
2026/1/22 20:31:12 信息 操作系统已在系统时间 2026-01-22T12:31:11.500000000Z 启动。
|
||||||
|
2026/1/22 20:31:28 错误 计算机已经从检测错误后重新启动。检测错误: 0x00000133 (0x0000000000000001, 0x0000000000001e00, 0xfffff801d8bc43b0, 0x0000000000000000)。已将转储的数据保存在: C:\WINDOWS\Minidump\012226-17125-01.dmp。报告 ID: 2d9c5441-44b1-4552-a0ea-3ff739039cbd。
|
||||||
|
|
||||||
【手动采集（你可以先不等脚本，直接跑这些命令）】
|
注意：012226-17125-01.dmp文件我已经保存到同目录下了。
|
||||||
请用“管理员 PowerShell”依次执行（每条单独一行）：
|
4)
|
||||||
|
- powercfg /systemsleepdiagnostics: 系统睡眠诊断报告已弃用且替换为系统电源报告。请改用命令 "powercfg /systempowerreport"。
|
||||||
|
- powercfg /systempowerreport: 已生成报告，保存到了同目录下的sleepstudy-report.html
|
||||||
|
- powercfg /sleepstudy: 已生成报告，保存到了同目录下的sleepstudy-report.html
|
||||||
|
- powercfg /lastwake: 唤醒历史记录计数 - 0
|
||||||
|
|
||||||
1) 查看系统支持的睡眠模型（非常关键）
|
C.
|
||||||
- `powercfg /a`
|
1) 这次卡死后我一直等待，系统自动重启了，然后正常进入了系统
|
||||||
|
2) 键盘完全没有任何响应
|
||||||
|
|
||||||
2) 生成睡眠/唤醒诊断报告（适用于大多数机器）
|
D.
|
||||||
- `powercfg /systemsleepdiagnostics`
|
1) 电脑处于休眠状态
|
||||||
|
2) 没有使用HDR，G-Sync/VRR，多显示器不同刷新率
|
||||||
|
3) 显示器连接方式是主显示器通过DP连接，副显示器通过HDMI连接，没有使用任何转接头
|
||||||
|
4) BIOS版本是最新的，显卡驱动版本是581.57，开启了HAGS
|
||||||
|
=====================
|
||||||
|
|
||||||
3) 查看最近一次唤醒来源
|
====================
|
||||||
- `powercfg /lastwake`
|
AI记录（2026-01-22）
|
||||||
|
我已读到你在文档里补充的 2026-01-22 这次复现细节与日志，关键信息很明确了：
|
||||||
4) 检查是否存在阻止睡眠/唤醒的请求
|
触发路径：休眠 24 小时 → 按电源键唤醒 → 卡在“正在锁定”转圈且转圈也停住；副屏短暂亮后变为无信号；键盘完全无响应（Caps/Num 都不行）。
|
||||||
- `powercfg /requests`
|
结果：你这次没硬重启，而是系统随后自动重启。
|
||||||
|
事件里最重要的一条是：BugCheck 0x00000133，并且已生成小转储：C:\WINDOWS\Minidump\012226-17125-01.dmp（你已拷贝到工作目录同级）。
|
||||||
5) 若你的机器支持“现代待机 S0”，再额外生成 SleepStudy
|
同一时间段还出现：“已更正的硬件错误：PCI Express Root Port / AER”（这是非常有价值的线索）。
|
||||||
- `powercfg /sleepstudy`
|
powercfg /lastwake 为 0（不意外：休眠恢复路径+非正常重启后，lastwake 往往拿不到可用记录）。
|
||||||
|
你还确认：NVIDIA 581.57 + HAGS 开启，无 HDR/G-Sync/VRR，主 DP 副 HDMI，无转接头。
|
||||||
【需要你回传/提供的结果】
|
基于这些，我的判断优先级变了：这已经不只是“黑屏卡死”，而更像 休眠恢复过程中某个驱动在高 DPC/ISR 下卡死或超时，最终触发 DPC_WATCHDOG_VIOLATION（0x133）。同时出现的 PCIe Root Port AER 更正错误提示：可能存在 PCIe 链路在低功耗/唤醒转换时不稳定（常见相关方：显卡/主板 PCIe、某些 NVMe、以及电源管理/BIOS/ASPM）。
|
||||||
- 把 `powercfg /a` 的输出原文贴到这里（它会告诉我们是 S3 还是 S0）。
|
接下来我建议走“两条线并行”，但都尽量做“可回退、改动小”的验证：
|
||||||
- `powercfg /systemsleepdiagnostics` 和（如有）`powercfg /sleepstudy` 生成的报告文件路径与文件本身（之后我会让脚本自动打包）。
|
1) 先把转储分析出来（定性：到底卡在哪个驱动）
|
||||||
|
你已经有 012226-17125-01.dmp，这是最关键证据。下一步我可以在你这个工作区里做自动化解析，但需要先确认你希望用哪种方式：
|
||||||
【复现后必查的目录（强烈建议）】
|
如果你机器上已装 WinDbg（预览版/商店版），我们可以直接用它出 !analyze -v 结果；
|
||||||
- `C:\Windows\LiveKernelReports\`（特别是 `WATCHDOG`、`DISPLAY`、`PoW32kWatchdog` 等子目录）
|
如果没装，我也可以帮你在文档里生成一套最短安装与分析流程（不需要你手动猜命令）。
|
||||||
- 如果这里出现新的 `.dmp`，通常对定位 GPU/显示/电源路径很有帮助。
|
为了避免你来回复制粘贴，我建议：我来直接在工作区新增一个 “dump 分析脚本/README”，把步骤固化下来。你确认后我就做。
|
||||||
|
2) 同时做 2 个最小化“排除项”（不改硬件、不大动系统）
|
||||||
【事件日志导出（复现后优先做）】
|
这两个改动的目的：验证是不是“GPU 调度/休眠恢复链路”导致的 0x133。
|
||||||
先不要求你手工导出全部；你只需要告诉我以下几个日志里是否出现“黄色/红色”的关键事件（脚本会自动导出更完整的）：
|
A. 先关闭 HAGS（强烈建议先试） 你已确认 HAGS 开启；HAGS 在部分驱动版本+多显示器+休眠恢复组合下，确实更容易触发卡死/0x133（不是必现，但与你现象吻合）。
|
||||||
- 事件查看器 → Windows 日志 → 系统：
|
验证方式：仅关闭、重启、观察下一次休眠唤醒。
|
||||||
- 重点来源：`Kernel-Power`、`Kernel-Boot`、`Power-Troubleshooter`、`Display`、`WHEA-Logger`、`volmgr`
|
B. 暂时禁用休眠（只为验证链路），改用“睡眠/仅息屏”一段时间 因为这次明确发生在“休眠恢复”。如果禁用休眠后现象明显消失，就能把范围锁在“hiber + 驱动恢复路径”。
|
||||||
- 事件查看器 → 应用程序和服务日志 → Microsoft → Windows：
|
这不一定是最终方案，但对定位很有用。
|
||||||
- 重点：`DxgKrnl`、`DriverFrameworks-UserMode`、`Kernel-PnP`
|
你日志里另一条关键：PCIe Root Port AER “已更正”错误
|
||||||
|
这类错误即使“已更正”，也常常意味着链路质量/省电策略/设备固件存在抖动。后续我们会重点看：
|
||||||
【一个重要解释：Caps Lock 无响应意味着什么】
|
错误对应的 设备实例路径/端口号（事件详情里能看到具体 Root Port，能映射到某个 PCIe 设备）
|
||||||
Caps Lock 灯不切换通常表示：系统已经严重挂起/中断风暴/内核死锁等，连键盘输入处理都无法及时响应；这比“仅显示黑屏”更偏向系统级冻结。
|
Sleepstudy 报告里是否出现某个设备在进入/退出低功耗时异常（你给我的 html 目前只读到开头样式部分，还没读到数据段；需要我继续往下定位“设备/会话/错误”章节）
|
||||||
|
我需要你补 2 个信息（都跟“PCIe/AER”和“dump 定位”强相关）
|
||||||
下一步我会在工作区加一个一键采集脚本：自动收集上述报告、关键事件日志、LiveKernelReports、驱动与版本信息，并打包成 zip，方便你每次复现后直接发我分析。
|
事件查看器里那条“PCI Express Root Port / AER”的事件详情（复制“常规”里更完整内容，尤其是端口/总线/设备/功能号，或“设备实例路径”字段）。
|
||||||
|
你是否愿意让我接下来直接读取并分析工作区里的 copilot_workspace/repair/012226-17125-01.dmp，然后把分析结论追加写回记录文档（会包含可能的“故障模块/驱动名”与建议下一步）。
|
||||||
|
只要 dump 能指向具体驱动（例如显示、存储、网卡、某个滤镜驱动），我们就能把排查从“猜”变成“改动—验证—收敛”。
|
||||||
====================
|
====================
|
||||||
|
|
||||||
====================
|
====================
|
||||||
Copilot 记录：一键采集脚本（2026-01-16）
|
AI记录（2026-01-22）- WinDbg分析结论（012226-17125-01.dmp）
|
||||||
|
|
||||||
我已在工作区新增脚本：
|
用户提供的 WinDbg `!analyze -v` 关键结论：
|
||||||
- `Copilot_id_card\tools\collect-freeze-diag.ps1`
|
- BugCheck：0x133 DPC_WATCHDOG_VIOLATION
|
||||||
|
- P1=1（系统累计在 DISPATCH_LEVEL 或更高 IRQL 停留时间过长）
|
||||||
|
- DPC_TIMEOUT_TYPE：DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
|
||||||
|
- Failure.Bucket：`0x133_ISR_nvlddmkm!unknown_function`
|
||||||
|
- 栈：在时钟中断/ISR 路径内触发，顶层第三方模块为 `nvlddmkm.sys`（NVIDIA 显卡内核驱动）
|
||||||
|
- 提示信息：`*** WARNING: Unable to verify timestamp for nvlddmkm.sys`
|
||||||
|
- 这通常不等同于“驱动必然损坏”，常见原因包括符号/时间戳验证不可用；但结合栈与 Bucket，显卡驱动在 ISR/DPC 路径异常超时的可能性很高。
|
||||||
|
- 环境：Hypervisor 标志为 1（系统启用了 Hyper-V/虚拟化相关能力；可能来自 Hyper-V、WSL2、VBS/内存完整性等）。
|
||||||
|
|
||||||
【如何运行（推荐：管理员 PowerShell）】
|
基于上述结论的优先排查顺序（从“改动最小、收益最大”开始）：
|
||||||
在 `d:\CodingProject\AI_Playground\Copilot_id_card` 目录下执行：
|
|
||||||
- `powershell -ExecutionPolicy Bypass -File .\tools\collect-freeze-diag.ps1`
|
|
||||||
|
|
||||||
可选参数：
|
1) 立即关闭 HAGS（硬件加速 GPU 调度）并复测
|
||||||
- `-RecentDays 30`（默认 14，控制收集最近多少天的 LiveKernelReports 文件）
|
- 你的环境此前已确认 HAGS=开启；0x133 + nvlddmkm ISR 的组合下，优先把 HAGS 作为第一可回退变量。
|
||||||
|
- 目标：观察“休眠→唤醒”在相同使用场景下是否不再触发卡死/自动重启。
|
||||||
|
|
||||||
【产物】
|
2) 显卡驱动做一次“干净重装”或回退一个稳定版本
|
||||||
- 输出目录：`Copilot_id_card\diag_out\freeze-时间戳\`
|
- 当前版本：NVIDIA 581.57。
|
||||||
- 同目录会生成一个 zip：`freeze-时间戳.zip`
|
- 建议路径：
|
||||||
|
- A) 先尝试回退到一个你历史上稳定的 WHQL 版本（减少回归风险）。
|
||||||
|
- B) 或使用 DDU（安全模式）做一次完全卸载后再安装（可排除升级残留/组件损坏）。
|
||||||
|
- 同时建议暂时禁用：GeForce Experience Overlay / Xbox Game Bar / 第三方叠加层（只作为验证变量）。
|
||||||
|
|
||||||
【你需要给我的内容】
|
3) 检查虚拟化相关功能（Hyper-V / VBS）对显示驱动路径的影响（仅做验证）
|
||||||
- 直接把生成的 `freeze-*.zip` 发我（或把其中 `powercfg-a.txt`、`system-last600.txt`、以及 `LiveKernelReports` 里新增的文件信息贴出来）。
|
- WinDbg 显示 Hypervisor.AnyHypervisorPresent=1。
|
||||||
|
- 若你确实启用了 Hyper-V/WSL2/内存完整性(VBS/HVCI)：
|
||||||
|
- 建议选择一个窗口期做 A/B Test：临时关闭其中一项（尤其是“内存完整性/核心隔离”）后复测“休眠→唤醒”。
|
||||||
|
- 目的：排除虚拟化安全特性对 GPU 调度/中断路径的放大效应。
|
||||||
|
|
||||||
【注意】
|
4) 结合此前事件中的 “PCIe Root Port / AER 已更正硬件错误” 做链路侧验证
|
||||||
- 不用等复现，现在先跑一次当“基线”；下次卡死强制重启后再跑一次当“复现后样本”。两份 zip 对比非常关键。
|
- 0x133 指向表现层（nvlddmkm ISR/DPC 超时），AER 指向底层链路（PCIe 纠错）。两者可同源：唤醒时 PCIe 链路抖动→驱动 ISR/DPC 被拖死。
|
||||||
|
- 建议：
|
||||||
|
- 在 BIOS/电源计划中，优先检视与 PCIe 省电相关选项（如 ASPM/Link State Power Management）。先“仅做一次调整并复测”，避免多变量同时变化。
|
||||||
|
- 下一次出现 AER 时，把事件查看器中该条目的“详细信息”（端口/总线/设备/功能号）记录下来，以便映射到具体设备（GPU/NVMe/网卡等）。
|
||||||
|
|
||||||
|
5) 若仍复现：升级取证等级
|
||||||
|
- 将转储类型从“小型转储”提升为“内核内存转储”（若当前并非内核转储），以便拿到更完整的 DPC/ISR 上下文（代价是 dump 更大）。
|
||||||
|
- 若能稳定抓到更完整 dump，再根据 `!analyze -v`、`lmvm nvlddmkm`、以及相关黑盒（blackboxpnp/winlogon/ntfs）进一步收敛。
|
||||||
|
|
||||||
|
（当前阶段结论）
|
||||||
|
- 这次卡死/自动重启并非“纯黑屏无日志”，而是已明确落到：`0x133 + nvlddmkm.sys ISR/DPC 超时`。
|
||||||
|
- 因此后续排查应优先围绕：HAGS/驱动版本与安装完整性/叠加层/虚拟化安全特性/PCIe 省电与链路稳定性。
|
||||||
|
|
||||||
|
====================
|
||||||
|
人工输入（2026-01-22）
|
||||||
|
- 已关闭 HAGS（硬件加速 GPU 调度），准备观察对“休眠→唤醒”卡死/0x133 的改善效果。
|
||||||
|
====================
|
||||||
|
AI记录（2026-01-22）- 关闭 HAGS 的影响与验证方案
|
||||||
|
|
||||||
|
关闭 HAGS 可能带来的影响（总体：更保守、更兼容）：
|
||||||
|
1) 性能/延迟：
|
||||||
|
- 大多数日常使用无感。
|
||||||
|
- 少部分游戏/高帧率场景可能出现极小的延迟上升或帧时间波动变化，也可能完全无差异。
|
||||||
|
2) 稳定性：
|
||||||
|
- 在本案已明确为 `0x133_ISR_nvlddmkm`（显卡驱动 ISR/DPC 超时）的前提下，关闭 HAGS 属于高收益、低风险的 A/B 验证变量，目标是降低休眠唤醒路径触发概率。
|
||||||
|
3) 兼容性：
|
||||||
|
- 不影响显卡基本功能、多屏、分辨率/刷新率设置；属于可随时回退的系统级开关。
|
||||||
|
|
||||||
|
验证方式（建议固定变量，避免混杂）：
|
||||||
|
- 在驱动版本、外设、显示模式不变的情况下，复测“长时间休眠（例如隔夜）→电源键唤醒”若干次。
|
||||||
|
- 若再次出现卡死/自动重启：
|
||||||
|
- 记录发生时间点；
|
||||||
|
- 检查是否再次生成 0x133 dump；
|
||||||
|
- 同步查看是否仍伴随 PCIe Root Port/AER 的“已更正硬件错误”。
|
||||||
|
|
||||||
|
回退与下一步：
|
||||||
|
- 若关闭 HAGS 后明显改善：维持关闭状态，并继续观察一段时间确认稳定。
|
||||||
|
- 若关闭 HAGS 后仍复现：进入下一优先级——显卡驱动“干净重装/回退稳定版”（必要时 DDU），并考虑临时关闭叠加层与虚拟化安全特性做 A/B Test。
|
||||||
|
|
||||||
|
====================
|
||||||
|
人工输入（2026-02-14）
|
||||||
|
- 今天又一次出现了类似的错误。
|
||||||
|
- 上一次因为等不下去直接强制重启，因此没有产生新的 .dmp 文件。
|
||||||
|
- 这一次等待系统自己重启，已产生新的 .dmp 文件（待进一步分析定位）。
|
||||||
|
- 已确认 HAGS（硬件加速 GPU 调度）已经关闭。
|
||||||
|
- 下一步：继续分析新产生的 dmp 与相关日志。
|
||||||
====================
|
====================
|
||||||
|
|
||||||
====================
|
====================
|
||||||
Copilot 记录：逐步排除清单（2026-01-16）
|
AI记录（2026-02-14）- 本轮取证计划（等待用户提供日志分析结果）
|
||||||
|
1) 先固化证据：
|
||||||
【操作纪律】
|
- 新生成的 dmp 文件请复制/保存到工作区（建议放在：copilot_workspace/repair/ 目录），并记录原始路径（通常为：C:\Windows\Minidump\*.dmp 或 C:\Windows\MEMORY.DMP）。
|
||||||
- 一次只改 1 项；至少观察 3-7 天或经历若干次睡眠/唤醒循环。
|
- 同步记录本次复现的关键信息：发生时间、触发前电源状态（睡眠/休眠/息屏）、唤醒方式、是否多显示器、是否出现 PCIe Root Port/AER 已更正硬件错误、是否出现 BugCheck 事件。
|
||||||
- 每改一次，跑一次 `collect-freeze-diag.ps1` 留存样本（便于回滚与对比）。
|
2) 为避免“强制重启导致无 dmp”：
|
||||||
|
- 若再次卡死且可以等待，尽量等待系统自动重启（或触发蓝屏）以生成转储。
|
||||||
【第 0 步：先确定睡眠模型与触发面】
|
3) 待用户提供：
|
||||||
- 先执行并贴出：`powercfg /a`
|
- 新 dmp 的 WinDbg `!analyze -v` 结果（或把 dmp 放到工作区我来解析）。
|
||||||
- 如果显示支持/正在用 S0（现代待机），后续排查路径会偏向“现代待机 + 驱动恢复”。
|
- 事件查看器中对应时间窗口（前后 10 分钟）的关键条目：BugCheck、WHEA-Logger、Display、Kernel-Power、PCIe/AER。
|
||||||
- 如果是 S3，路径会偏向“传统睡眠恢复 + PCIe/显卡/多屏握手”。
|
|
||||||
|
|
||||||
【低风险（优先）】
|
|
||||||
1) BIOS/固件与主板驱动
|
|
||||||
- 更新到联想/主板最新 BIOS；同时更新 Intel ME（管理引擎）与芯片组驱动。
|
|
||||||
- 验证：更新后连续多次睡眠/唤醒是否仍复现；并查看复现后样本里是否出现 WHEA 相关事件。
|
|
||||||
|
|
||||||
2) NVIDIA 驱动“干净重装”并做版本对照
|
|
||||||
- 用 DDU（安全模式）卸载后，安装一个明确版本做对照：优先尝试 Studio Driver（或换到相邻的大版本）。
|
|
||||||
- 验证：复现概率是否变化；复现后 `DxgKrnl/Display` 是否出现新的错误；`LiveKernelReports` 是否新增。
|
|
||||||
|
|
||||||
3) Windows 图形相关开关（可逆）
|
|
||||||
- 关闭 HAGS：设置 → 系统 → 显示 → 图形 → 默认图形设置 → 关闭“硬件加速 GPU 调度”。
|
|
||||||
- 如仍复现，再考虑关闭 MPO（多平面叠加）：我建议等我们先拿到一次样本后再做，避免变量过多。
|
|
||||||
|
|
||||||
4) 电源计划里禁用容易引发唤醒问题的省电项（可回滚）
|
|
||||||
- 控制面板 → 电源选项 → 高级设置：
|
|
||||||
- “睡眠”：关闭“混合睡眠”（若开启）；
|
|
||||||
- “PCI Express”：将“链接状态电源管理”设为“关闭”；
|
|
||||||
- “USB 设置”：将“USB 选择性暂停”设为“已禁用”。
|
|
||||||
|
|
||||||
【中风险（需要更谨慎）】
|
|
||||||
5) 多显示器链路排除
|
|
||||||
- 临时只接主屏使用一段时间，或更换 DP/HDMI 线材与接口（避免转接头/延长线）；
|
|
||||||
- 若显示器支持，尝试关闭 DSC/降低刷新率做对照（仅用于定位）。
|
|
||||||
|
|
||||||
6) 稳定性与超频因素
|
|
||||||
- 若有开启 XMP/CPU 自动超频/显卡超频，建议先回到默认（特别是 WHEA 有记录时）。
|
|
||||||
|
|
||||||
【高风险/最后手段（我们拿到证据后再决定）】
|
|
||||||
7) 配置更强的“卡死取证”（例如强制触发转储/更激进的验证器）
|
|
||||||
- 这类手段可能影响日常使用与稳定性，建议等我们先从日志判断方向再上。
|
|
||||||
|
|
||||||
【你现在可以做的两件事（最有效）】
|
|
||||||
1) 运行一次脚本生成“基线 zip”；
|
|
||||||
2) 把 `powercfg /a` 输出 + 你显示器连接方式（DP/HDMI/是否转接）+ BIOS 与 NVIDIA 驱动版本 回到这份文档里。
|
|
||||||
====================
|
====================
|
||||||
|
|
||||||
====================
|
====================
|
||||||
人工输入（2026-01-16）
|
AI记录（2026-02-14）- WinDbg分析结论（021426-11890-01.dmp）
|
||||||
我现在没在我那台故障的机器跟前，我会尽可能先回答你的问题，但是暂时没办法做测试。我们先收集我已知的信息并尝试确定定位解决方向，等到我可以操作故障的机器了我会通知你。
|
用户提供的 WinDbg `!analyze -v` 关键结论：
|
||||||
关于你需要我回答的三个问题：
|
- FILE_IN_CAB：021426-11890-01.dmp
|
||||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
- BugCheck：0x133 DPC_WATCHDOG_VIOLATION
|
||||||
我无法确认这三者哪个更容易出问题，看起来三者都有可能故障。不过我最常用的状态是息屏和休眠。休眠是我通过powercfg -h on来开起来的，我也不知道是那种。
|
- P1=1（系统累计在 DISPATCH_LEVEL 或更高 IRQL 停留时间过长）
|
||||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
- P2=0x1e00（watchdog 周期 tick）
|
||||||
我的两台显示器分别通过HDMI和DP连接到4090上，没有经过任何扩展坞/转接头/延长线。我尝试把这两台显示器调换过，也没能解决息屏问题。
|
- DPC_TIMEOUT_TYPE：DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
|
||||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
- Failure.Bucket：`0x133_ISR_nvlddmkm!unknown_function`
|
||||||
我暂时看不到这些信息，但我需要你提供如何查看这些信息的step-by-step指引。
|
- 堆栈：在时钟中断/ISR 路径内触发，第三方栈顶持续指向 `nvlddmkm.sys`（NVIDIA 显卡内核驱动）
|
||||||
|
- 本次偏移：`nvlddmkm+0x267e6a`（同时栈中出现 `nvlddmkm+0x168495` 等）
|
||||||
|
- 仍出现提示：`*** WARNING: Unable to verify timestamp for nvlddmkm.sys`
|
||||||
|
- Hypervisor 标志仍为 1（RootFlags.IsHyperV=1）：系统处于启用 Hyper-V/虚拟化相关能力状态（可能来自 Hyper-V、WSL2、VBS/内存完整性 等）。
|
||||||
|
|
||||||
|
与 2026-01-22 的对比结论：
|
||||||
|
- 即使已关闭 HAGS，本次依然复现同类 0x133，并且 Bucket 仍为 nvlddmkm ISR 超时。
|
||||||
|
- 说明 HAGS 不是唯一触发条件；需要把排查重点转向：显卡驱动安装/版本、叠加层与内核组件、虚拟化安全特性、以及 PCIe 链路/省电策略（与先前 AER 线索可能同源）。
|
||||||
|
|
||||||
|
下一步建议（按优先级，尽量一次只改一个变量）：
|
||||||
|
1) 显卡驱动“干净重装/回退稳定版”（优先级最高）
|
||||||
|
- 使用 DDU（安全模式）彻底卸载 NVIDIA 驱动后重装。
|
||||||
|
- 若当前为较新分支版本：建议回退到一个更成熟的 WHQL 版本做 A/B（以稳定为目标）。
|
||||||
|
- 同时禁用可能注入/叠加的组件做验证：GeForce Experience Overlay、Xbox Game Bar、Discord/Steam/NVIDIA overlay、录屏/监控类工具（只作为排除变量）。
|
||||||
|
2) 虚拟化相关能力做 A/B 验证（针对 Hypervisor 标志=1）
|
||||||
|
- 若你开启了“内存完整性/核心隔离（HVCI）”、Hyper-V、WSL2：选择其中一项在可控窗口期临时关闭后复测“休眠→唤醒”。
|
||||||
|
- 目的：验证虚拟化/安全内核是否放大了 GPU ISR/DPC 触发概率。
|
||||||
|
3) 继续跟踪 PCIe/AER（若事件里仍出现“PCI Express Root Port / AER 已更正硬件错误”）
|
||||||
|
- 把对应事件的“详细信息”记录下来（总线/设备/功能号/设备实例路径），用于映射到具体硬件（GPU/NVMe/网卡等）。
|
||||||
|
- 后续再决定是否调整 PCIe 省电策略（ASPM/Link State Power Management）做验证。
|
||||||
|
4) 提升转储取证能力（若仍频繁复现）
|
||||||
|
- 将转储类型调整为“内核内存转储”（或完整内存转储），以便拿到更完整的 DPC/ISR 上下文与相关对象信息（代价：dump 文件更大）。
|
||||||
|
|
||||||
|
待补充信息（用于下一轮收敛）：
|
||||||
|
- 本次复现发生前的电源状态：睡眠/休眠/仅息屏？持续多久？唤醒方式？
|
||||||
|
- 本次对应时间窗口是否仍有 WHEA-Logger / PCIe Root Port AER 的日志（若有请粘贴事件详情）。
|
||||||
====================
|
====================
|
||||||
|
|
||||||
====================
|
====================
|
||||||
Copilot 记录（2026-01-16）
|
人工输入（2026-02-14）- 补充：触发条件 & 事件日志
|
||||||
|
- 本次复现前：从“休眠”状态唤醒。
|
||||||
|
- 唤醒方式：电源键。
|
||||||
|
|
||||||
【本次回复目的】
|
事件查看器摘要：
|
||||||
- 回答你当前不在故障机器旁时能做的规划；
|
1) 11:31:47 警告：发生了已更正的硬件错误（AER）
|
||||||
- 提供你回到故障机器后可直接执行的 step-by-step 检查步骤，并约定如何把结果写回这份记录。
|
- 组件：PCI Express Root Port
|
||||||
|
- 错误源：Advanced Error Reporting (PCI Express)
|
||||||
【如何查看 BIOS 版本】
|
- 主总线:设备:函数：0x0:0x1C:0x4
|
||||||
1) 在故障机器上按 `Win + R`，输入 `msinfo32`，回车。
|
- 辅助总线:设备:函数：0x0:0x0:0x0
|
||||||
2) 在弹出的“系统信息”窗口中，右侧找到：
|
- 主要设备名称：PCI\VEN_8086&DEV_7A3C&SUBSYS_376A17AA&REV_11
|
||||||
- “BIOS 版本/日期”：请记录品牌 + 版本号 + 日期；
|
2) 11:33:38 错误：nvlddmkm 事件 ID 153（本机缺少描述/消息表）
|
||||||
- “基板产品”、“基板制造商”：如果方便，可以一并记下或截图。
|
- \Device\00000244
|
||||||
3) 你可以把这一整页直接截图，或把上述几个字段原文抄到后续的“人工输入”段落中。
|
- Resetting TDR occurred on GPUID:100
|
||||||
|
3) 11:38:00 错误：系统意外关机（上一次 11:35:55）
|
||||||
【如何查看 NVIDIA 驱动版本与类型】
|
====================
|
||||||
方法 A（优先）：通过 NVIDIA 控制面板
|
|
||||||
1) 在桌面空白处右键 → 点击“NVIDIA 控制面板”。
|
|
||||||
2) 打开后，在窗口左下角找到“系统信息”（System Information），点击。
|
|
||||||
3) 在弹出的“系统信息”窗口中：
|
|
||||||
- 找到“驱动程序版本”（Driver Version）：记下完整版本号；
|
|
||||||
- 若有“驱动类型”（例如 Game Ready / Studio）或类似说明，也一并记下。
|
|
||||||
4) 建议对这个窗口截图，或者把相关字段原文抄到“人工输入”里。
|
|
||||||
|
|
||||||
方法 B（备用）：通过设备管理器
|
|
||||||
1) 按 `Win + X` → 选择“设备管理器”。
|
|
||||||
2) 展开“显示适配器”，双击你的 RTX 4090 项。
|
|
||||||
3) 切换到“驱动程序”标签页，记录：
|
|
||||||
- “驱动程序日期”；
|
|
||||||
- “驱动程序版本”。
|
|
||||||
|
|
||||||
【如何确认 HAGS（硬件加速 GPU 调度）开关状态】
|
|
||||||
1) 打开“设置”：可以按 `Win + I`，或右键任务栏空白处 → “任务栏设置”，再左侧进入“系统”。
|
|
||||||
2) 路径一般为：`系统` → `显示` → 滚动到底部点击“图形” → 再点击“默认图形设置`（有些版本直接在“图形”页面里就能看到）。
|
|
||||||
3) 在“默认图形设置”页面中找到“硬件加速 GPU 调度”：
|
|
||||||
- 若开关显示为“开”，请记下“开”；
|
|
||||||
- 若开关显示为“关”，请记下“关”；
|
|
||||||
- 目前阶段我们只“记录现状”，先不要改动它（等拿到完整信息后再决定是否调整）。
|
|
||||||
|
|
||||||
【你下次在故障机器前可以做的事】
|
|
||||||
- 按上面三个小节的步骤，在故障机器上依次获取：
|
|
||||||
- BIOS 品牌 + 版本号 + 日期；
|
|
||||||
- NVIDIA 显卡驱动版本号、驱动日期，以及是否 Game Ready / Studio；
|
|
||||||
- HAGS（硬件加速 GPU 调度）当前是“开”还是“关”。
|
|
||||||
- 然后回到这份 `debug_communication_record.txt`，新增一段“====================\n人工输入（YYYY-MM-DD）\n...” 的记录，把这些信息按原文贴进去。
|
|
||||||
- 等你把这些信息补充完成后，我会在下一段“Copilot 记录”里基于这些信息给出更有针对性的下一步（例如：是否建议先更新 BIOS、是否先更换为某个显卡驱动版本、以及是否调整电源/图形相关设置）。
|
|
||||||
|
|
||||||
====================
|
====================
|
||||||
|
AI记录（2026-02-14）- 组合证据解读 & 下一步收敛
|
||||||
|
本次新增的关键点在于：
|
||||||
|
- 休眠唤醒路径中先出现 PCIe Root Port 的 AER“已更正硬件错误”（指向 PCIe 链路/电源状态切换抖动）。
|
||||||
|
- 随后出现 nvlddmkm 的 TDR 重置记录（GPU 超时检测与恢复），并且 dump 里仍然是 0x133 ISR nvlddmkm。
|
||||||
|
=> 这三者组合更像“GPU 在唤醒/链路恢复阶段出现响应异常（可能被 PCIe 链路错误/省电策略放大）→ 触发 TDR → 最终在 ISR/DPC 路径上超时导致 0x133”。
|
||||||
|
|
||||||
|
下一步建议（只改一项就复测，避免混杂变量）：
|
||||||
|
1) 优先：NVIDIA 驱动做一次 DDU 干净重装 + 回退到稳定 WHQL 版本做 A/B
|
||||||
|
- 目标：排除驱动升级残留/组件损坏，并验证是否为特定分支回归。
|
||||||
|
2) 叠加层/注入类组件最小化（仅作为验证变量）
|
||||||
|
- 临时关闭：NVIDIA/GeForce Experience Overlay、Xbox Game Bar、以及常见第三方 Overlay/监控/录屏（如有）。
|
||||||
|
3) 虚拟化/安全内核 A/B（dump 中 Hyper-V 标志一直为 1）
|
||||||
|
- 若启用了“内存完整性(HVCI)/核心隔离”、Hyper-V、WSL2：选一项在可控窗口期临时关闭复测。
|
||||||
|
4) PCIe 省电策略验证（基于 AER Root Port 线索）
|
||||||
|
- Windows 电源计划中把“PCI Express → 链路状态电源管理”临时设置为“关闭”做 A/B。
|
||||||
|
- BIOS 中若存在 ASPM/PCIe 电源相关选项，可在确认当前值后，仅改动一次做验证。
|
||||||
|
|
||||||
|
需要进一步补齐的定位信息（用于把 AER Root Port 映射到具体设备）：
|
||||||
|
- 请补充该 AER 事件的“详细信息”完整 XML（或至少包含：Port/Device Instance Path/Segment/Bus/Device/Function 的字段），以便确认该 Root Port 下挂设备是不是 GPU（或 NVMe/网卡等）。
|
||||||
|
- 另外建议在 WinDbg 中对该 dump 执行：`lmvm nvlddmkm`（记录驱动具体版本/时间戳信息，避免仅凭版本号猜测）。
|
||||||
|
====================
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,51 @@
|
|||||||
|
?? ID: USB\ROOT_HUB30\5&323bdd91&2&0
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
|
||||||
|
?? ID: USB\VID_1D5C&PID_5001\6&10f81194&0&8
|
||||||
|
?? ID: USB\VID_174F&PID_1809\200901010001
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801\0123456789AB
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548\5&213b2cfc&0&3
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
|
||||||
|
?? ID: HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
|
||||||
|
?? ID: USB\VID_1D5C&PID_5011\6&10f81194&0&4
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233\0429133856
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
|
||||||
|
?? ID: USB\ROOT_HUB30\4&35627a0b&2&0
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
|
||||||
|
?? ID: USB\VID_2808&PID_93A9\5&213b2cfc&0&5
|
||||||
|
?? ID: USB\VID_8087&PID_0033\5&213b2cfc&0&14
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF\20240420112909
|
||||||
|
?? ID: USB\VID_17EF&PID_C955\5&213b2cfc&0&13
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
|
||||||
|
?? ID: USB\VID_1A40&PID_0101\5&213b2cfc&0&4
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
|
||||||
@@ -0,0 +1,51 @@
|
|||||||
|
?? ID: USB\ROOT_HUB30\5&323bdd91&2&0
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
|
||||||
|
?? ID: USB\VID_1D5C&PID_5001\6&10f81194&0&8
|
||||||
|
?? ID: USB\VID_174F&PID_1809\200901010001
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801\0123456789AB
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548\5&213b2cfc&0&3
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
|
||||||
|
?? ID: HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
|
||||||
|
?? ID: USB\VID_1D5C&PID_5011\6&10f81194&0&4
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233\0429133856
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
|
||||||
|
?? ID: USB\ROOT_HUB30\4&35627a0b&2&0
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
|
||||||
|
?? ID: USB\VID_2808&PID_93A9\5&213b2cfc&0&5
|
||||||
|
?? ID: USB\VID_8087&PID_0033\5&213b2cfc&0&14
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF\20240420112909
|
||||||
|
?? ID: USB\VID_17EF&PID_C955\5&213b2cfc&0&13
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
|
||||||
|
?? ID: USB\VID_1A40&PID_0101\5&213b2cfc&0&4
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
|
||||||
@@ -0,0 +1,56 @@
|
|||||||
|
?? ID: USB\ROOT_HUB30\5&323bdd91&2&0
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
|
||||||
|
?? ID: USB\VID_0BDA&PID_8153\000001
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
|
||||||
|
?? ID: USB\VID_1D5C&PID_5001\6&10f81194&0&8
|
||||||
|
?? ID: USB\VID_174F&PID_1809\200901010001
|
||||||
|
?? ID: USB\VID_05E3&PID_0749\000000001539
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801\0123456789AB
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
|
||||||
|
?? ID: HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548\5&213b2cfc&0&3
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
|
||||||
|
?? ID: HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
|
||||||
|
?? ID: USB\VID_1D5C&PID_5011\6&10f81194&0&4
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233\0429133856
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
|
||||||
|
?? ID: USB\VID_2109&PID_0817\MSFT30000000000
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
|
||||||
|
?? ID: USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
|
||||||
|
?? ID: USB\ROOT_HUB30\4&35627a0b&2&0
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
|
||||||
|
?? ID: USB\VID_2109&PID_2817\MSFT20000000000
|
||||||
|
?? ID: USB\VID_2808&PID_93A9\5&213b2cfc&0&5
|
||||||
|
?? ID: USB\VID_8087&PID_0033\5&213b2cfc&0&14
|
||||||
|
?? ID: USB\VID_CB07&PID_1BCF\20240420112909
|
||||||
|
?? ID: USB\VID_17EF&PID_C955\5&213b2cfc&0&13
|
||||||
|
?? ID: USB\VID_2109&PID_1817\MSFT30000000000
|
||||||
|
?? ID: USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
|
||||||
|
?? ID: HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
|
||||||
|
?? ID: HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
|
||||||
|
?? ID: HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
|
||||||
|
?? ID: USB\VID_1A40&PID_0101\5&213b2cfc&0&4
|
||||||
|
?? ID: USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
|
||||||
|
?? ID: USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
|
||||||
|
?? ID: USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
|
||||||
@@ -0,0 +1,463 @@
|
|||||||
|
====================
|
||||||
|
人工输入（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 口的相关硬件链路存在问题。
|
||||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,281 @@
|
|||||||
|
######################################################################
|
||||||
|
### Automated Landing Library and Example
|
||||||
|
######################################################################
|
||||||
|
### Like all of the scripts in my folder here, this file contains
|
||||||
|
### functions you might want to include into your own scripts for
|
||||||
|
### actual use and a demo in the 'main' function that you can just
|
||||||
|
### run to see how it works.
|
||||||
|
###
|
||||||
|
### This file shows how to complete an automated landing. It
|
||||||
|
### does so in three phases - a deorbital burn, a suicide burn to a
|
||||||
|
### safety altitude and speed, and then a speed limited descent to
|
||||||
|
### final touch down.
|
||||||
|
######################################################################
|
||||||
|
|
||||||
|
import krpc
|
||||||
|
import math
|
||||||
|
import time
|
||||||
|
import numpy as np
|
||||||
|
|
||||||
|
from pid import PID
|
||||||
|
|
||||||
|
|
||||||
|
##############################################################################
|
||||||
|
### Main function - demonstrates the use of this library. Simply lands
|
||||||
|
### a vessel. Only propulsive landing - so really designed for planets
|
||||||
|
### without an atmosphere.
|
||||||
|
##############################################################################
|
||||||
|
|
||||||
|
|
||||||
|
###############################################################################
|
||||||
|
### High Level Functions
|
||||||
|
###
|
||||||
|
### These are the ones you'd actually maybe want to call from your script.
|
||||||
|
###############################################################################
|
||||||
|
|
||||||
|
def deorbit(vessel, eccentricity):
|
||||||
|
'''executes a deorbit burn until the given eccentricity
|
||||||
|
is achieved. If periapsis remains above the equatorial
|
||||||
|
radius, it continues burning.
|
||||||
|
'''
|
||||||
|
print("Deorbiting Vessel...")
|
||||||
|
vessel.control.speed_mode = vessel.control.speed_mode.surface
|
||||||
|
ap = vessel.auto_pilot
|
||||||
|
ap.sas = True
|
||||||
|
time.sleep(.1)
|
||||||
|
ap.sas_mode = ap.sas_mode.retrograde
|
||||||
|
|
||||||
|
while (vessel.orbit.eccentricity < eccentricity or
|
||||||
|
vessel.orbit.periapsis_altitude > 0):
|
||||||
|
vessel.control.throttle = 1.0
|
||||||
|
vessel.control.throttle = 0.0
|
||||||
|
|
||||||
|
|
||||||
|
def suicide_burn(conn, vessel, autowarp=True):
|
||||||
|
'''
|
||||||
|
Performs a 'Suicide Burn' using the calculator class.
|
||||||
|
'''
|
||||||
|
print("Calculating Suicide Burn...")
|
||||||
|
telem = vessel.flight(vessel.orbit.body.reference_frame)
|
||||||
|
vessel.control.speed_mode = vessel.control.speed_mode.surface
|
||||||
|
rf = vessel.orbit.body.reference_frame
|
||||||
|
ap = vessel.auto_pilot
|
||||||
|
ap.sas = True
|
||||||
|
time.sleep(.1)
|
||||||
|
ap.sas_mode = ap.sas_mode.retrograde
|
||||||
|
|
||||||
|
##calculate initial burn
|
||||||
|
computer = suicide_burn_calculator(conn, vessel, 5000)
|
||||||
|
computer.update() # run once with altitude of 5000m to get an estimated groundtrack distance
|
||||||
|
touchdown = coords_down_bearing(telem.latitude, telem.longitude, (180 + telem.heading), computer.ground_track,
|
||||||
|
vessel.orbit.body)
|
||||||
|
# update actual safe altitude over the groundtrack
|
||||||
|
computer.alt = check_terrain(telem.latitude, telem.longitude, touchdown[0], touchdown[1], vessel.orbit.body)
|
||||||
|
|
||||||
|
# Initial burn - aiming for the 'safe alt' (highest point over course)
|
||||||
|
# and a vertical velocity of 10 m/s
|
||||||
|
burn_until_velocity(conn, vessel, telem, 10, computer, True)
|
||||||
|
|
||||||
|
## update computer ti aim for 10m above current altitude.
|
||||||
|
computer.alt = vessel.orbit.body.surface_height(telem.latitude, telem.longitude) + 10
|
||||||
|
|
||||||
|
# Second half of burn - aiming for ground alt + 10m and a vertical
|
||||||
|
# velocity of 5 m/s
|
||||||
|
burn_until_velocity(conn, vessel, telem, 5, computer, True)
|
||||||
|
|
||||||
|
|
||||||
|
def burn_until_velocity(conn, vessel, telem, thresh, computer, autowarp):
|
||||||
|
'''
|
||||||
|
Helper Function for suicide_burn function - actually executes a burn
|
||||||
|
at the calculated time and burns until it reaches the threshold
|
||||||
|
vertical velocity.
|
||||||
|
|
||||||
|
'''
|
||||||
|
countdown = computer.update()
|
||||||
|
print("Burn in {} seconds".format(countdown))
|
||||||
|
|
||||||
|
if autowarp and (countdown > thresh):
|
||||||
|
conn.space_center.warp_to(conn.space_center.ut + countdown - 10) # warp to 10 seconds before burn
|
||||||
|
|
||||||
|
while countdown > 0.0: # Wait until suicide burn
|
||||||
|
time.sleep(.1)
|
||||||
|
countdown = computer.update()
|
||||||
|
|
||||||
|
while telem.vertical_speed < (-1 * thresh): # Loop until we're ready for final descent
|
||||||
|
countdown = computer.update()
|
||||||
|
vessel.control.throttle = .95 # 95% throttle
|
||||||
|
if countdown < 0.0: # use the emergencty 5% of throttle when needed
|
||||||
|
vessel.control.throttle = 1.0
|
||||||
|
vessel.control.throttle = 0.0
|
||||||
|
|
||||||
|
|
||||||
|
def final_descent(v):
|
||||||
|
''' manages final descent. At the moment keeps vertical velocity limited to 1/10 of the
|
||||||
|
current altitude above terrain - so at 200m would try to descend at 20m/s and at 10 m/s locks
|
||||||
|
descent speed to 1m/s.
|
||||||
|
'''
|
||||||
|
print("final descent")
|
||||||
|
telem = v.flight(v.orbit.body.reference_frame)
|
||||||
|
v.control.speed_mode = v.control.speed_mode.surface
|
||||||
|
ap = v.auto_pilot
|
||||||
|
ap.sas = True
|
||||||
|
time.sleep(.1)
|
||||||
|
ap.sas_mode = ap.sas_mode.retrograde
|
||||||
|
p = PID(.25, .25, .025)
|
||||||
|
while v.situation is not v.situation.landed:
|
||||||
|
# ap.sas_mode = ap.sas_mode.retrograde # SAS leaves retrograde mode if velocity gets to zero.
|
||||||
|
safe_descent = telem.surface_altitude / -10
|
||||||
|
# print safe_descent
|
||||||
|
if safe_descent < -15.0:
|
||||||
|
safe_descent = -15.0
|
||||||
|
p.setpoint(safe_descent)
|
||||||
|
v.control.throttle = p.update(telem.vertical_speed)
|
||||||
|
v.control.throttle = 0
|
||||||
|
|
||||||
|
|
||||||
|
###############################################################################
|
||||||
|
## Burn Calculator Class
|
||||||
|
###############################################################################
|
||||||
|
|
||||||
|
|
||||||
|
class suicide_burn_calculator(object):
|
||||||
|
'''
|
||||||
|
Class that calculates time until suicide burn.
|
||||||
|
'''
|
||||||
|
|
||||||
|
def __init__(self, conn, v, alt):
|
||||||
|
self.conn = conn
|
||||||
|
self.v = v
|
||||||
|
self.sc = conn.space_center
|
||||||
|
self.burn_time = np.inf
|
||||||
|
self.burn_duration = np.inf
|
||||||
|
self.ground_track = np.inf
|
||||||
|
self.effective_decel = np.inf
|
||||||
|
self.radius = np.inf
|
||||||
|
self.angle_from_horizontal = np.inf
|
||||||
|
self.impact_time = np.inf
|
||||||
|
self.alt = alt
|
||||||
|
|
||||||
|
self.rf = self.sc.ReferenceFrame.create_hybrid(
|
||||||
|
position=self.v.orbit.body.reference_frame,
|
||||||
|
rotation=self.v.surface_reference_frame)
|
||||||
|
|
||||||
|
def update(self):
|
||||||
|
'''
|
||||||
|
Returns an estimate of how many seconds until you need to burn at 95% throttle to avoid crashing.
|
||||||
|
This gives a 5% safety margin.
|
||||||
|
I do not even PRETEND to understand all of the math in this function. It's essentially a porting
|
||||||
|
of the routine from the Mechjeb orbit extensions.
|
||||||
|
'''
|
||||||
|
|
||||||
|
if self.v.orbit.periapsis_altitude > 0: ## We're not on a landing trajectory yet.
|
||||||
|
self.burn_time = np.inf
|
||||||
|
self.burn_duration = np.inf
|
||||||
|
self.ground_track = np.inf
|
||||||
|
self.effective_decel = np.inf
|
||||||
|
self.angle_from_horizontal = np.inf
|
||||||
|
self.impact_time = np.inf
|
||||||
|
return self.burn_time
|
||||||
|
|
||||||
|
rf = self.v.orbit.body.reference_frame
|
||||||
|
|
||||||
|
# calculate sin of angle from horizontal -
|
||||||
|
v1 = self.v.velocity(self.rf)
|
||||||
|
v2 = (0, 0, 1)
|
||||||
|
self.angle_from_horizontal = angle_between(v1, v2)
|
||||||
|
sine = math.sin(self.angle_from_horizontal)
|
||||||
|
|
||||||
|
# estimate deceleration time
|
||||||
|
g = self.v.orbit.body.surface_gravity
|
||||||
|
T = (self.v.max_thrust / self.v.mass) * .95 # calculating with 5% safety margin!
|
||||||
|
self.effective_decel = .5 * (-2 * g * sine + math.sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g)))
|
||||||
|
self.decel_time = self.v.flight(self.rf).speed / self.effective_decel
|
||||||
|
|
||||||
|
# estimate time until burn
|
||||||
|
radius = self.v.orbit.body.equatorial_radius + self.alt
|
||||||
|
TA = self.v.orbit.true_anomaly_at_radius(radius)
|
||||||
|
TA = -1 * TA # look on the negative (descending) side of the orbit
|
||||||
|
self.impact_time = self.v.orbit.ut_at_true_anomaly(TA)
|
||||||
|
self.burn_time = self.impact_time - self.decel_time / 2
|
||||||
|
self.ground_track = ((self.burn_time - self.sc.ut) * self.v.flight(self.rf).speed) + (
|
||||||
|
.5 * self.v.flight(self.rf).speed * self.decel_time)
|
||||||
|
return self.burn_time - self.sc.ut
|
||||||
|
|
||||||
|
|
||||||
|
###############################################################################
|
||||||
|
## Ground Navigation Functions - Probably ought to move to their
|
||||||
|
## own library file some day.
|
||||||
|
###############################################################################
|
||||||
|
|
||||||
|
def coords_down_bearing(lat, lon, bearing, distance, body):
|
||||||
|
'''
|
||||||
|
Takes a latitude, longitude and bearing in degrees, and a
|
||||||
|
distance in meters over a given body. Returns a tuple
|
||||||
|
(latitude, longitude) of the point you've calculated.
|
||||||
|
'''
|
||||||
|
bearing = math.radians(bearing)
|
||||||
|
R = body.equatorial_radius
|
||||||
|
lat = math.radians(lat)
|
||||||
|
lon = math.radians(lon)
|
||||||
|
|
||||||
|
lat2 = math.asin(math.sin(lat) * math.cos(distance / R) +
|
||||||
|
math.cos(lat) * math.sin(distance / R) * math.cos(bearing))
|
||||||
|
|
||||||
|
lon2 = lon + math.atan2(math.sin(bearing) * math.sin(distance / R
|
||||||
|
) * math.cos(lat), math.cos(distance / R) - math.sin(lat
|
||||||
|
) * math.sin(
|
||||||
|
lat2))
|
||||||
|
|
||||||
|
lat2 = math.degrees(lat2)
|
||||||
|
lon2 = math.degrees(lon2)
|
||||||
|
return (lat2, lon2)
|
||||||
|
|
||||||
|
|
||||||
|
def check_terrain(lat1, lon1, lat2, lon2, body):
|
||||||
|
'''
|
||||||
|
Returns an estimate of the highest terrain altitude betwen
|
||||||
|
two latitude / longitude points.
|
||||||
|
'''
|
||||||
|
lat = lat1
|
||||||
|
lon = lon1
|
||||||
|
highest_lat = lat
|
||||||
|
highest_lon = lon
|
||||||
|
highest_alt = body.surface_height(lat, lon)
|
||||||
|
latstep = (lat2 - lat1) / 20
|
||||||
|
lonstep = (lon2 - lon1) / 20
|
||||||
|
|
||||||
|
for x in range(20):
|
||||||
|
test_alt = body.surface_height(lat, lon)
|
||||||
|
if test_alt > highest_alt:
|
||||||
|
highest_lat = lat
|
||||||
|
highest_lon = lon
|
||||||
|
highest_alt = test_alt
|
||||||
|
lat = lat + latstep
|
||||||
|
lon = lon + lonstep
|
||||||
|
return highest_alt
|
||||||
|
|
||||||
|
|
||||||
|
###############################################################################
|
||||||
|
## Vector Math Functions - Probably ought to move to their
|
||||||
|
## own library file some day.
|
||||||
|
###############################################################################
|
||||||
|
|
||||||
|
def unit_vector(vector):
|
||||||
|
""" Returns the unit vector of the vector provided. """
|
||||||
|
return vector / np.linalg.norm(vector)
|
||||||
|
|
||||||
|
|
||||||
|
def angle_between(v1, v2):
|
||||||
|
""" Returns the angle in radians between vectors 'v1' and 'v2'"""
|
||||||
|
v1_u = unit_vector(v1)
|
||||||
|
v2_u = unit_vector(v2)
|
||||||
|
return np.arccos(np.clip(np.dot(v1_u, v2_u), -1.0, 1.0))
|
||||||
|
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
conn = krpc.connect()
|
||||||
|
sc = conn.space_center
|
||||||
|
v = sc.active_vessel
|
||||||
|
suicide_burn(conn, v)
|
||||||
|
final_descent(v)
|
||||||
|
|
||||||
@@ -1,6 +1,5 @@
|
|||||||
import time
|
import time
|
||||||
import krpc
|
import krpc
|
||||||
import math
|
|
||||||
|
|
||||||
|
|
||||||
G_EARTH = 9.80665
|
G_EARTH = 9.80665
|
||||||
@@ -83,6 +82,7 @@ def get_body_g(local_vessel):
|
|||||||
def auto_land_predictive(
|
def auto_land_predictive(
|
||||||
bottom_clearance_margin=12,
|
bottom_clearance_margin=12,
|
||||||
thrust_discount_wait=0.85,
|
thrust_discount_wait=0.85,
|
||||||
|
pre_ignite_seconds=2.5,
|
||||||
host='localhost',
|
host='localhost',
|
||||||
port=50000,
|
port=50000,
|
||||||
target_altitude=1.0,
|
target_altitude=1.0,
|
||||||
@@ -123,6 +123,11 @@ def auto_land_predictive(
|
|||||||
会用 avail_thrust * thrust_discount_wait 来保守估算用于决定何时点火（补偿推力建立/响应延迟）。
|
会用 avail_thrust * thrust_discount_wait 来保守估算用于决定何时点火（补偿推力建立/响应延迟）。
|
||||||
- 取值范围：0.0~1.0；越小越保守（更早点火）。默认 0.85。
|
- 取值范围：0.0~1.0；越小越保守（更早点火）。默认 0.85。
|
||||||
|
|
||||||
|
pre_ignite_seconds (float):
|
||||||
|
- 单位：秒(s)
|
||||||
|
- 说明：在预计点火时刻的倒计时触发点火的提前时间。用于补偿推力建立/响应延迟。
|
||||||
|
- 典型值：2.0~3.0，默认 2.5。
|
||||||
|
|
||||||
host (str) / port (int):
|
host (str) / port (int):
|
||||||
- 说明：连接 kRPC 服务的地址和 RPC 端口（用于 krpc.connect）。一般本地运行时用 'localhost' 和 50000。
|
- 说明：连接 kRPC 服务的地址和 RPC 端口（用于 krpc.connect）。一般本地运行时用 'localhost' 和 50000。
|
||||||
|
|
||||||
@@ -199,8 +204,11 @@ def auto_land_predictive(
|
|||||||
# 初始确保不点火
|
# 初始确保不点火
|
||||||
vessel.control.throttle = 0.0
|
vessel.control.throttle = 0.0
|
||||||
|
|
||||||
# 倒计时/等待点火
|
# 外层循环：允许在燃烧被中止时回退到 WAIT 阶段重新计算
|
||||||
|
phase_loop = True
|
||||||
last_log_t = 0.0
|
last_log_t = 0.0
|
||||||
|
while phase_loop:
|
||||||
|
# 倒计时/等待点火
|
||||||
while True:
|
while True:
|
||||||
alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
|
alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
|
||||||
# 用“雷达高度-底部余量”近似最低点离地高度
|
# 用“雷达高度-底部余量”近似最低点离地高度
|
||||||
@@ -235,20 +243,26 @@ def auto_land_predictive(
|
|||||||
f'WAIT alt={alt:.1f} radar={radar_alt:.1f} alt_eff={alt_eff:.1f} rem={remaining_alt:.1f} '
|
f'WAIT alt={alt:.1f} radar={radar_alt:.1f} alt_eff={alt_eff:.1f} rem={remaining_alt:.1f} '
|
||||||
f'srf_speed={srf_speed:.2f} vs={v_speed:.2f} '
|
f'srf_speed={srf_speed:.2f} vs={v_speed:.2f} '
|
||||||
f'a_max_up={a_max_up:.2f} braking={braking_dist:.1f} thr_disc={thrust_discount_wait:.2f} '
|
f'a_max_up={a_max_up:.2f} braking={braking_dist:.1f} thr_disc={thrust_discount_wait:.2f} '
|
||||||
f'countdown={(countdown if countdown is not None else float("nan")):.2f}'
|
f'countdown={(countdown if countdown is not None else float("nan")):.2f} pre_ignite={float(pre_ignite_seconds):.2f}'
|
||||||
)
|
)
|
||||||
status['logs'].append(msg)
|
status['logs'].append(msg)
|
||||||
print(msg)
|
print(msg)
|
||||||
|
|
||||||
# 点火条件：进入刹车距离 or 推力未知（inf）但高度很低
|
# 点火条件：进入刹车距离 or 推力未知（inf）但高度很低
|
||||||
should_ignite = (remaining_alt <= braking_dist + v_speed) or (braking_dist == float('inf') and remaining_alt < 200.0)
|
# 额外：若倒计时计算可用，则在 suicide burn 前 pre_ignite_seconds 提前点火
|
||||||
|
should_ignite = (
|
||||||
|
(remaining_alt <= braking_dist)
|
||||||
|
or (braking_dist == float('inf') and remaining_alt < 200.0)
|
||||||
|
or (countdown is not None and countdown <= float(pre_ignite_seconds))
|
||||||
|
)
|
||||||
if should_ignite:
|
if should_ignite:
|
||||||
break
|
break
|
||||||
|
|
||||||
# 确保仍在滑行
|
# 确保仍在滑行
|
||||||
time.sleep(0.05)
|
time.sleep(0.05)
|
||||||
|
|
||||||
# 燃烧闭环：根据 remaining_alt 反推需要的减速度 -> 油门
|
# 进入燃烧闭环：根据 remaining_alt 反推需要的减速度 -> 油门
|
||||||
|
break_burn_and_retry = False
|
||||||
while True:
|
while True:
|
||||||
alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
|
alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
|
||||||
alt_eff = max(0.0, float(radar_alt) - float(bottom_clearance_margin))
|
alt_eff = max(0.0, float(radar_alt) - float(bottom_clearance_margin))
|
||||||
@@ -267,6 +281,7 @@ def auto_land_predictive(
|
|||||||
status['logs'].append('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
|
status['logs'].append('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
|
||||||
if verbose:
|
if verbose:
|
||||||
print('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
|
print('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
|
||||||
|
phase_loop = False
|
||||||
break
|
break
|
||||||
|
|
||||||
# 兜底：极低高度 + 速度足够小（防止 situation 迟迟不切换导致卡死）
|
# 兜底：极低高度 + 速度足够小（防止 situation 迟迟不切换导致卡死）
|
||||||
@@ -275,15 +290,23 @@ def auto_land_predictive(
|
|||||||
status['result'] = 'touchdown_pending'
|
status['result'] = 'touchdown_pending'
|
||||||
status['logs'].append('达到高度/速度阈值，但 vessel.situation 仍未变为 LANDED')
|
status['logs'].append('达到高度/速度阈值，但 vessel.situation 仍未变为 LANDED')
|
||||||
if verbose:
|
if verbose:
|
||||||
print('达到高度/速度阈值，但 vessel.situation 仍未变为 LANDED')
|
print('达到高度/速度阈值，但 vessel.situation 仍未变为 LANED')
|
||||||
|
phase_loop = False
|
||||||
|
break
|
||||||
|
|
||||||
|
# 如果尚未落地但不再下降（v_down<=0），说明燃烧过强导致上升或已停止下落，停止燃烧并回退到等待
|
||||||
|
if (not is_landed) and v_down <= 0.0:
|
||||||
|
vessel.control.throttle = 0.0
|
||||||
|
status['logs'].append('BURN aborted: 未落地但竖直速度已<=0，返回等待点火')
|
||||||
|
if verbose:
|
||||||
|
print('BURN aborted: 未落地但竖直速度已<=0，返回等待点火')
|
||||||
|
break_burn_and_retry = True
|
||||||
break
|
break
|
||||||
|
|
||||||
# 低空策略：切换到“竖直速度跟踪”以确保最后几米把速度压到目标值
|
# 低空策略：切换到“竖直速度跟踪”以确保最后几米把速度压到目标值
|
||||||
if alt_eff <= float(low_altitude_pid_switch):
|
if alt_eff <= float(low_altitude_pid_switch):
|
||||||
# 低空：比例 + 前馈（用当前速度估算“需要多少距离才能刹到目标速度”）
|
# 低空：比例 + 前馈（用当前速度估算“需要多少距离才能刹到目标速度”）
|
||||||
# a_p：把竖直速度拉向目标
|
|
||||||
a_p = float(vspeed_p_gain) * max(0.0, (v_down - vf_down))
|
a_p = float(vspeed_p_gain) * max(0.0, (v_down - vf_down))
|
||||||
# a_ff：基于能量/距离的前馈，防止在最后几米才突然补救
|
|
||||||
if remaining_alt <= 1e-3:
|
if remaining_alt <= 1e-3:
|
||||||
a_ff = 0.0
|
a_ff = 0.0
|
||||||
else:
|
else:
|
||||||
@@ -313,6 +336,16 @@ def auto_land_predictive(
|
|||||||
throttle = max(throttle, 0.8)
|
throttle = max(throttle, 0.8)
|
||||||
|
|
||||||
vessel.control.throttle = throttle
|
vessel.control.throttle = throttle
|
||||||
|
# 异常点获取
|
||||||
|
if throttle > 0 and vessel.thrust <= 1e-3 and vessel.control.throttle <= 1e-3:
|
||||||
|
log_msg = '此时应当点火，但实际并未移动节流阀，也未产生推力'
|
||||||
|
print('Reconnected: ', end='')
|
||||||
|
conn.close()
|
||||||
|
conn = krpc.connect(name='auto_land_predictive_retry', address=host, rpc_port=port)
|
||||||
|
sc = conn.space_center
|
||||||
|
vessel = sc.active_vessel
|
||||||
|
else:
|
||||||
|
log_msg = ''
|
||||||
|
|
||||||
if verbose:
|
if verbose:
|
||||||
msg = (
|
msg = (
|
||||||
@@ -321,13 +354,24 @@ def auto_land_predictive(
|
|||||||
f'v_down={v_down:.2f} vf_down={vf_down:.2f} '
|
f'v_down={v_down:.2f} vf_down={vf_down:.2f} '
|
||||||
f'a_req_up={a_req_up:.2f} throttle={throttle:.2f} '
|
f'a_req_up={a_req_up:.2f} throttle={throttle:.2f} '
|
||||||
f'landed={int(is_landed)} '
|
f'landed={int(is_landed)} '
|
||||||
f'current_thrust={vessel.thrust:.1f}kN'
|
f'current_thrust={vessel.thrust:.1f}kN '
|
||||||
|
f"{log_msg}"
|
||||||
)
|
)
|
||||||
status['logs'].append(msg)
|
status['logs'].append(msg)
|
||||||
print(msg)
|
print(msg)
|
||||||
|
|
||||||
time.sleep(0.05)
|
time.sleep(0.05)
|
||||||
|
|
||||||
|
# BURN loop end
|
||||||
|
if break_burn_and_retry:
|
||||||
|
# 清理并回退到等待点火状态，继续外层 phase_loop
|
||||||
|
vessel.control.throttle = 0.0
|
||||||
|
time.sleep(0.05)
|
||||||
|
continue
|
||||||
|
else:
|
||||||
|
# 着陆完成或触地待定，结束 outer loop
|
||||||
|
break
|
||||||
|
|
||||||
finally:
|
finally:
|
||||||
try:
|
try:
|
||||||
if ap is not None and hasattr(ap, 'disengage'):
|
if ap is not None and hasattr(ap, 'disengage'):
|
||||||
@@ -346,7 +390,9 @@ def auto_land_predictive(
|
|||||||
|
|
||||||
if __name__ == "__main__":
|
if __name__ == "__main__":
|
||||||
xxx = auto_land_predictive(
|
xxx = auto_land_predictive(
|
||||||
bottom_clearance_margin=30,
|
bottom_clearance_margin=0,
|
||||||
|
thrust_discount_wait=1.0,
|
||||||
|
pre_ignite_seconds=1.5,
|
||||||
)
|
)
|
||||||
print(xxx)
|
print(xxx)
|
||||||
print('done')
|
print('done')
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
import requests
|
||||||
|
import bs4
|
||||||
|
import time
|
||||||
|
|
||||||
|
start_url = 'https://www.rouwenwu.in/book/239/14393.html'
|
||||||
|
|
||||||
|
total_content = ''
|
||||||
|
while True:
|
||||||
|
resp = requests.get(start_url)
|
||||||
|
resp.encoding = 'ansi'
|
||||||
|
soup = bs4.BeautifulSoup(resp.content, features='lxml')
|
||||||
|
title = soup.select_one('#content > div.page-header.text-center > h1').text
|
||||||
|
content = soup.select_one('#htmlContent').text.replace('\xa0\xa0\xa0\xa0', '\n')
|
||||||
|
|
||||||
|
total_content += title + '\n' + content + '\n'
|
||||||
|
print(title, 'completed')
|
||||||
|
time.sleep(1)
|
||||||
|
|
||||||
|
next_href = soup.select_one('#linkNext')['href']
|
||||||
|
if 'html' not in next_href:
|
||||||
|
break
|
||||||
|
start_url = 'https://www.rouwenwu.in/book/239/' + next_href
|
||||||
|
|
||||||
|
with open('AV拍摄指南.txt', 'w', encoding='utf-8') as f:
|
||||||
|
f.write(total_content)
|
||||||
Reference in New Issue
Block a user