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%复现，所以非常头疼，我需要你的帮助
|
||||
====================
|
||||
AI记录（2026-01-22）
|
||||
|
||||
已阅读当前文档内容：目前记录仅包含 2026-01-16 的一次人工描述与已尝试措施。现问题“刚刚又出现一次”，但文档尚未记录本次复现的时间点、当时电源状态（睡眠/休眠/仅息屏）、以及是否有新增的系统日志/症状。
|
||||
|
||||
====================
|
||||
Copilot 记录（2026-01-16）
|
||||
初步判断要点（基于已有描述）：
|
||||
1) “Caps Lock 无反应”通常意味着系统在更底层已失去调度（可能为内核/驱动级卡死），而不仅是图形界面假死；也可能是输入堆栈/中断被阻塞。
|
||||
2) 副屏无信号 + 主屏停在锁屏转圈，且 Win+Ctrl+Shift+B 无法恢复，提示可能涉及：显卡驱动/显示链路在唤醒路径失败、Modern Standby/睡眠唤醒路径中的设备电源状态切换异常、或某个内核驱动死锁。
|
||||
3) 远程桌面“正在配置远程电脑”卡住，说明网络握手可能建立，但目标机在登录/会话初始化阶段无响应（与系统级卡死一致）。
|
||||
|
||||
【我对现象的结构化归纳】
|
||||
- 设备：拯救者刃9000k 2023；RTX 4090 + i9-13900KF + Z690；双显示器。
|
||||
- 触发场景：从“睡眠/休眠/息屏”被键鼠唤醒时，有概率卡在锁屏“正在锁定/转圈”界面；副屏无信号。
|
||||
- 卡死特征：Caps Lock 指示无响应（倾向于系统/输入栈整体失去调度，而非单纯显示问题）；风扇/机械盘仍工作；只能硬关机。
|
||||
- 复现后：事件查看器几乎只有非正常关机；Win+Ctrl+Shift+B 无效；RDP 连接会卡在“正在配置远程电脑”。
|
||||
下一步目标：把“偶发”变成“可定位”，优先收集一次卡死前后 5~10 分钟的可关联证据。
|
||||
|
||||
【初步判断（先不下结论）】
|
||||
这更像“唤醒路径上的系统级挂起”：可能发生在 GPU/显示驱动恢复、PCIe/电源管理、或会话/锁屏相关组件恢复阶段。副屏掉信号 + Win 图形重置快捷键无效 + RDP 卡住，说明不只是显示器‘没亮’，而是系统在较早阶段就僵住了。
|
||||
A. 立刻补充的记录项（请在每次发生后追加到本文档）
|
||||
- 发生时间（精确到分钟）
|
||||
- 发生前状态：睡眠/休眠/仅关闭显示器/锁屏后待机（以及持续了多久）
|
||||
- 唤醒方式：键盘/鼠标/电源键/定时器/网络唤醒
|
||||
- 现象细节：主屏内容、分辨率是否变化、副屏是“无信号”还是黑屏有背光
|
||||
- 机器指示：键盘灯、NumLock/CapsLock、机箱电源灯、硬盘灯、风扇转速是否明显变化
|
||||
- 是否插拔过外设/USB扩展坞/VR设备/采集卡等
|
||||
|
||||
【下一步目标】
|
||||
因为问题偶发且当前日志不足，我们优先做两件事：
|
||||
1) 明确你机器当前到底在用哪种睡眠/待机模型（S3 vs 现代待机 S0），以及究竟是“睡眠/休眠/仅息屏”哪一种更相关；
|
||||
2) 配置并采集“下一次发生时/发生后”的证据（电源与唤醒报告、关键事件日志、GPU LiveKernelReports、可靠性历史），让我们能定位到具体链路。
|
||||
B. 建议立刻做的“取证型设置”（为下一次复现做准备）
|
||||
1) 启用/检查系统转储（用于驱动/内核死锁分析）
|
||||
- 系统属性 → 启动和故障恢复：写入调试信息建议至少“自动内存转储”（或“内核内存转储”）。
|
||||
- 确认页面文件存在且足够（通常需位于系统盘）。
|
||||
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 个关键信息（尽量精确）】
|
||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
||||
C. 下一次卡死时（在保证安全前提下）可尝试的操作（按优先级）
|
||||
1) 等待 60~120 秒观察是否自动恢复（某些驱动超时会自行回滚）。
|
||||
2) 若键盘仍有响应：尝试 Ctrl+Alt+Del（看是否能切到安全桌面）。
|
||||
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键没有反应，机箱电源灯常亮，硬盘灯持续闪烁，风扇转速没有明显变化
|
||||
- 没有插拔过任何外设
|
||||
|
||||
【采集原则】
|
||||
- 先做一次“基线采集”（现在电脑正常时做）；下次复现卡死并强制重启后，立刻再做一次“复现后采集”。
|
||||
- 复现后采集重点是：最后一次进入睡眠/唤醒、显示驱动恢复、内核电源事件、WHEA 硬件错误、以及是否生成 LiveKernelReports。
|
||||
B.
|
||||
1) 系统转储已经启用，设置为自动内存转储
|
||||
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。
|
||||
|
||||
【手动采集（你可以先不等脚本，直接跑这些命令）】
|
||||
请用“管理员 PowerShell”依次执行（每条单独一行）：
|
||||
注意：012226-17125-01.dmp文件我已经保存到同目录下了。
|
||||
4)
|
||||
- powercfg /systemsleepdiagnostics: 系统睡眠诊断报告已弃用且替换为系统电源报告。请改用命令 "powercfg /systempowerreport"。
|
||||
- powercfg /systempowerreport: 已生成报告，保存到了同目录下的sleepstudy-report.html
|
||||
- powercfg /sleepstudy: 已生成报告，保存到了同目录下的sleepstudy-report.html
|
||||
- powercfg /lastwake: 唤醒历史记录计数 - 0
|
||||
|
||||
1) 查看系统支持的睡眠模型（非常关键）
|
||||
- `powercfg /a`
|
||||
C.
|
||||
1) 这次卡死后我一直等待，系统自动重启了，然后正常进入了系统
|
||||
2) 键盘完全没有任何响应
|
||||
|
||||
2) 生成睡眠/唤醒诊断报告（适用于大多数机器）
|
||||
- `powercfg /systemsleepdiagnostics`
|
||||
D.
|
||||
1) 电脑处于休眠状态
|
||||
2) 没有使用HDR，G-Sync/VRR，多显示器不同刷新率
|
||||
3) 显示器连接方式是主显示器通过DP连接，副显示器通过HDMI连接，没有使用任何转接头
|
||||
4) BIOS版本是最新的，显卡驱动版本是581.57，开启了HAGS
|
||||
=====================
|
||||
|
||||
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，方便你每次复现后直接发我分析。
|
||||
====================
|
||||
AI记录（2026-01-22）
|
||||
我已读到你在文档里补充的 2026-01-22 这次复现细节与日志，关键信息很明确了：
|
||||
触发路径：休眠 24 小时 → 按电源键唤醒 → 卡在“正在锁定”转圈且转圈也停住；副屏短暂亮后变为无信号；键盘完全无响应（Caps/Num 都不行）。
|
||||
结果：你这次没硬重启，而是系统随后自动重启。
|
||||
事件里最重要的一条是：BugCheck 0x00000133，并且已生成小转储：C:\WINDOWS\Minidump\012226-17125-01.dmp（你已拷贝到工作目录同级）。
|
||||
同一时间段还出现：“已更正的硬件错误：PCI Express Root Port / AER”（这是非常有价值的线索）。
|
||||
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）。
|
||||
接下来我建议走“两条线并行”，但都尽量做“可回退、改动小”的验证：
|
||||
1) 先把转储分析出来（定性：到底卡在哪个驱动）
|
||||
你已经有 012226-17125-01.dmp，这是最关键证据。下一步我可以在你这个工作区里做自动化解析，但需要先确认你希望用哪种方式：
|
||||
如果你机器上已装 WinDbg（预览版/商店版），我们可以直接用它出 !analyze -v 结果；
|
||||
如果没装，我也可以帮你在文档里生成一套最短安装与分析流程（不需要你手动猜命令）。
|
||||
为了避免你来回复制粘贴，我建议：我来直接在工作区新增一个 “dump 分析脚本/README”，把步骤固化下来。你确认后我就做。
|
||||
2) 同时做 2 个最小化“排除项”（不改硬件、不大动系统）
|
||||
这两个改动的目的：验证是不是“GPU 调度/休眠恢复链路”导致的 0x133。
|
||||
A. 先关闭 HAGS（强烈建议先试） 你已确认 HAGS 开启；HAGS 在部分驱动版本+多显示器+休眠恢复组合下，确实更容易触发卡死/0x133（不是必现，但与你现象吻合）。
|
||||
验证方式：仅关闭、重启、观察下一次休眠唤醒。
|
||||
B. 暂时禁用休眠（只为验证链路），改用“睡眠/仅息屏”一段时间 因为这次明确发生在“休眠恢复”。如果禁用休眠后现象明显消失，就能把范围锁在“hiber + 驱动恢复路径”。
|
||||
这不一定是最终方案，但对定位很有用。
|
||||
你日志里另一条关键：PCIe Root Port AER “已更正”错误
|
||||
这类错误即使“已更正”，也常常意味着链路质量/省电策略/设备固件存在抖动。后续我们会重点看：
|
||||
错误对应的 设备实例路径/端口号（事件详情里能看到具体 Root Port，能映射到某个 PCIe 设备）
|
||||
Sleepstudy 报告里是否出现某个设备在进入/退出低功耗时异常（你给我的 html 目前只读到开头样式部分，还没读到数据段；需要我继续往下定位“设备/会话/错误”章节）
|
||||
我需要你补 2 个信息（都跟“PCIe/AER”和“dump 定位”强相关）
|
||||
事件查看器里那条“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）
|
||||
|
||||
我已在工作区新增脚本：
|
||||
- `Copilot_id_card\tools\collect-freeze-diag.ps1`
|
||||
用户提供的 WinDbg `!analyze -v` 关键结论：
|
||||
- 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`
|
||||
基于上述结论的优先排查顺序（从“改动最小、收益最大”开始）：
|
||||
|
||||
可选参数：
|
||||
- `-RecentDays 30`（默认 14，控制收集最近多少天的 LiveKernelReports 文件）
|
||||
1) 立即关闭 HAGS（硬件加速 GPU 调度）并复测
|
||||
- 你的环境此前已确认 HAGS=开启；0x133 + nvlddmkm ISR 的组合下，优先把 HAGS 作为第一可回退变量。
|
||||
- 目标：观察“休眠→唤醒”在相同使用场景下是否不再触发卡死/自动重启。
|
||||
|
||||
【产物】
|
||||
- 输出目录：`Copilot_id_card\diag_out\freeze-时间戳\`
|
||||
- 同目录会生成一个 zip：`freeze-时间戳.zip`
|
||||
2) 显卡驱动做一次“干净重装”或回退一个稳定版本
|
||||
- 当前版本：NVIDIA 581.57。
|
||||
- 建议路径：
|
||||
- A) 先尝试回退到一个你历史上稳定的 WHQL 版本（减少回归风险）。
|
||||
- B) 或使用 DDU（安全模式）做一次完全卸载后再安装（可排除升级残留/组件损坏）。
|
||||
- 同时建议暂时禁用：GeForce Experience Overlay / Xbox Game Bar / 第三方叠加层（只作为验证变量）。
|
||||
|
||||
【你需要给我的内容】
|
||||
- 直接把生成的 `freeze-*.zip` 发我（或把其中 `powercfg-a.txt`、`system-last600.txt`、以及 `LiveKernelReports` 里新增的文件信息贴出来）。
|
||||
3) 检查虚拟化相关功能（Hyper-V / VBS）对显示驱动路径的影响（仅做验证）
|
||||
- WinDbg 显示 Hypervisor.AnyHypervisorPresent=1。
|
||||
- 若你确实启用了 Hyper-V/WSL2/内存完整性(VBS/HVCI)：
|
||||
- 建议选择一个窗口期做 A/B Test：临时关闭其中一项（尤其是“内存完整性/核心隔离”）后复测“休眠→唤醒”。
|
||||
- 目的：排除虚拟化安全特性对 GPU 调度/中断路径的放大效应。
|
||||
|
||||
【注意】
|
||||
- 不用等复现，现在先跑一次当“基线”；下次卡死强制重启后再跑一次当“复现后样本”。两份 zip 对比非常关键。
|
||||
4) 结合此前事件中的 “PCIe Root Port / AER 已更正硬件错误” 做链路侧验证
|
||||
- 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）
|
||||
|
||||
【操作纪律】
|
||||
- 一次只改 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 驱动版本 回到这份文档里。
|
||||
AI记录（2026-02-14）- 本轮取证计划（等待用户提供日志分析结果）
|
||||
1) 先固化证据：
|
||||
- 新生成的 dmp 文件请复制/保存到工作区（建议放在：copilot_workspace/repair/ 目录），并记录原始路径（通常为：C:\Windows\Minidump\*.dmp 或 C:\Windows\MEMORY.DMP）。
|
||||
- 同步记录本次复现的关键信息：发生时间、触发前电源状态（睡眠/休眠/息屏）、唤醒方式、是否多显示器、是否出现 PCIe Root Port/AER 已更正硬件错误、是否出现 BugCheck 事件。
|
||||
2) 为避免“强制重启导致无 dmp”：
|
||||
- 若再次卡死且可以等待，尽量等待系统自动重启（或触发蓝屏）以生成转储。
|
||||
3) 待用户提供：
|
||||
- 新 dmp 的 WinDbg `!analyze -v` 结果（或把 dmp 放到工作区我来解析）。
|
||||
- 事件查看器中对应时间窗口（前后 10 分钟）的关键条目：BugCheck、WHEA-Logger、Display、Kernel-Power、PCIe/AER。
|
||||
====================
|
||||
|
||||
====================
|
||||
人工输入（2026-01-16）
|
||||
我现在没在我那台故障的机器跟前，我会尽可能先回答你的问题，但是暂时没办法做测试。我们先收集我已知的信息并尝试确定定位解决方向，等到我可以操作故障的机器了我会通知你。
|
||||
关于你需要我回答的三个问题：
|
||||
1) 你确认“最容易出问题”的是：睡眠、休眠、还是仅关闭显示器（息屏）？（三者机制不同）
|
||||
我无法确认这三者哪个更容易出问题，看起来三者都有可能故障。不过我最常用的状态是息屏和休眠。休眠是我通过powercfg -h on来开起来的，我也不知道是那种。
|
||||
2) 你的显示器连接方式：主/副屏分别是 DP 还是 HDMI？是否经过扩展坞/转接头/延长线？
|
||||
我的两台显示器分别通过HDMI和DP连接到4090上，没有经过任何扩展坞/转接头/延长线。我尝试把这两台显示器调换过，也没能解决息屏问题。
|
||||
3) 最近一次更新的：BIOS 版本、NVIDIA 驱动版本（Game Ready/Studio）、以及是否开启 HAGS（硬件加速 GPU 调度）。
|
||||
我暂时看不到这些信息，但我需要你提供如何查看这些信息的step-by-step指引。
|
||||
AI记录（2026-02-14）- WinDbg分析结论（021426-11890-01.dmp）
|
||||
用户提供的 WinDbg `!analyze -v` 关键结论：
|
||||
- FILE_IN_CAB：021426-11890-01.dmp
|
||||
- BugCheck：0x133 DPC_WATCHDOG_VIOLATION
|
||||
- P1=1（系统累计在 DISPATCH_LEVEL 或更高 IRQL 停留时间过长）
|
||||
- P2=0x1e00（watchdog 周期 tick）
|
||||
- DPC_TIMEOUT_TYPE：DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
|
||||
- Failure.Bucket：`0x133_ISR_nvlddmkm!unknown_function`
|
||||
- 堆栈：在时钟中断/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）- 补充：触发条件 & 事件日志
|
||||
- 本次复现前：从“休眠”状态唤醒。
|
||||
- 唤醒方式：电源键。
|
||||
|
||||
【本次回复目的】
|
||||
- 回答你当前不在故障机器旁时能做的规划；
|
||||
- 提供你回到故障机器后可直接执行的 step-by-step 检查步骤，并约定如何把结果写回这份记录。
|
||||
|
||||
【如何查看 BIOS 版本】
|
||||
1) 在故障机器上按 `Win + R`，输入 `msinfo32`，回车。
|
||||
2) 在弹出的“系统信息”窗口中，右侧找到：
|
||||
- “BIOS 版本/日期”：请记录品牌 + 版本号 + 日期；
|
||||
- “基板产品”、“基板制造商”：如果方便，可以一并记下或截图。
|
||||
3) 你可以把这一整页直接截图，或把上述几个字段原文抄到后续的“人工输入”段落中。
|
||||
|
||||
【如何查看 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、是否先更换为某个显卡驱动版本、以及是否调整电源/图形相关设置）。
|
||||
事件查看器摘要：
|
||||
1) 11:31:47 警告：发生了已更正的硬件错误（AER）
|
||||
- 组件：PCI Express Root Port
|
||||
- 错误源：Advanced Error Reporting (PCI Express)
|
||||
- 主总线:设备:函数：0x0:0x1C:0x4
|
||||
- 辅助总线:设备:函数：0x0:0x0:0x0
|
||||
- 主要设备名称：PCI\VEN_8086&DEV_7A3C&SUBSYS_376A17AA&REV_11
|
||||
2) 11:33:38 错误：nvlddmkm 事件 ID 153（本机缺少描述/消息表）
|
||||
- \Device\00000244
|
||||
- Resetting TDR occurred on GPUID:100
|
||||
3) 11:38:00 错误：系统意外关机（上一次 11:35:55）
|
||||
====================
|
||||
|
||||
====================
|
||||
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
Reference in New Issue
Block a user