首先确认本 skill 是否适用，以下是明确的三分类：
示例： "最近一周蓝屏了3次"、"电脑待机后黑屏打不开"、"WinDbg 显示 win32kfull.sys 崩溃"
示例： "帮我看下这个 dmp 文件" → 可以分析，但需要用户先提供 WinDbg 输出
如果你是第一次用，直接告诉 Claude 下面任意一句话即可开始：
诊断会自动进行，无需你手动操作。完成后会生成一份结构化的诊断报告。
重要约束：禁止凭空猜测。每一步的诊断结论必须引用具体的 Event ID、时间戳或数据作为证据。如果某一步没有查到数据，必须明确说明"未找到相关记录"，而不能编造。
按以下步骤顺序进行诊断。可在 bash 中执行 PowerShell 命令（Windows 环境），或运行 scripts/ 目录下的预置脚本。
运行 scripts/check_shutdown_events.ps1，或执行等价 PowerShell 命令，获取最近 30 次关机事件。
关键事件 ID：
| Event ID | 来源 | 含义 |
|---|---|---|
| ---------- | ------ | ------ |
| 41 | Kernel-Power | 非正常关机。BugcheckCode ≠ 0 = 蓝屏，= 0 = 强制断电 |
| 1074 | User32 | 用户/程序主动重启（正常） |
| 6006 | EventLog | 事件日志服务正常停止（正常） |
| 6008 | EventLog | 上一次关机是意外的 |
| 506 | Kernel-Power | 系统进入待机 |
| 507 | Kernel-Power | 系统从待机唤醒 |
从 Event 41 的 Properties 提取 BugcheckCode（十进制），转十六进制即可获得 Bugcheck 代码。
如果确认是蓝屏，运行 scripts/check_crash_detail.ps1。
2a. WER 系统错误报告（System Log, Event 1001）：
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001; StartTime=(Get-Date '<DATE>')} -MaxEvents 10
输出包含 Bugcheck 代码 + 4 参数、MEMORY.DMP 路径、Minidump 路径。
2b. Minidump 文件列表：
Get-ChildItem C:\Windows\Minidump\*.dmp | Sort-Object LastWriteTime -Descending
将 minidump 时间与 Event 41 时间对齐，确认每次蓝屏的对应文件。
2c. WHEA 硬件错误（关键遗漏项）：
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; StartTime=(Get-Date).AddDays(-14)} -MaxEvents 10
WHEA Event ID 1 表示硬件级错误，如果存在则强烈指向硬件不稳定。
2d. LiveKernelEvent 转储（关键遗漏项）：
Get-ChildItem C:\Windows\LiveKernelReports -Recurse -Filter *.dmp -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 10
LiveKernelEvent 0x124 代表 WHEA 不可纠正错误，0x144 代表 USB 故障，0x15E 代表网卡驱动请求重置。
针对最近一次蓝屏时间，查崩溃前的 System 日志：
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date '<START>'); EndTime=(Get-Date '<END>')} -MaxEvents 100 | Sort-Object TimeCreated
必查项：
Application 日志中的连锁反应（关键遗漏项）：
如果 WinDbg 或日志指向 win32kfull.sys 或 GDI 相关崩溃：
Get-WinEvent -LogName 'Application' -MaxEvents 2000 | Where-Object { $_.Id -eq 1001 -and $_.Message -match 'GDI|GDIObjectLeak' }
GDI 对象泄漏会导致 win32kfull 内核态资源耗尽，触发空指针崩溃。通常由终端模拟器（MoTTY/MobaXterm/ConEmu）等频繁渲染 GDI 的应用触发。
列出所有非 Microsoft 的内核驱动及其版本日期：
Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DriverProviderName -notmatch 'Microsoft' -and $_.DeviceName -match 'Non-Plug|System|Filter|Legacy' } | Select-Object DeviceName, DriverVersion, DriverDate, DriverProviderName | Sort-Object DriverDate
判断标准：
如果用户描述涉及待机异常，额外执行：
6a. 确认睡眠模式： powercfg /a — S0 现代待机 vs S3 传统睡眠
6b. 睡眠-唤醒时间线：
Get-WinEvent -FilterHashtable @{LogName='System'; Id=506,507; StartTime=(Get-Date).AddDays(-3)} | Sort-Object TimeCreated
6c. 资源耗尽检测：
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Resource-Exhaustion-Detector'; StartTime=(Get-Date).AddDays(-3)} | Sort-Object TimeCreated
该事件会列出内存占用 Top 3 进程。如果 explorer.exe 超过 500MB 或任意进程超过 1GB，说明存在内存泄漏。
6d. 唤醒源： powercfg /lastwake 和 powercfg /waketimers
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model, TotalPhysicalMemory
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, Name, Version, ReleaseDate
Get-CimInstance Win32_PhysicalMemory | Select-Object Manufacturer, PartNumber, Capacity, Speed, DeviceLocator
如果步骤 1-5 无法确定根因，引导用户使用 WinDbg。不要自行编造 WinDbg 结果。 详见 references/windbg_guide.md。
要求用户提供：IMAGE_NAME、PROCESS_NAME、FAILURE_BUCKET_ID、STACK_TEXT（前 10 行）。
解读规则：
.sys 驱动 → 该驱动存在 bugntoskrnl.exe → 第三方驱动导致内核崩溃，看 STACK_TEXT 定位真实驱动.exe + PROCESS_NAME 同名 → 应用程序通过 GDI/系统调用触发了内核 bugAV_ → 空指针/访问违例| 情况 | 处理方式 |
|---|---|
| ------ | ---------- |
| 事件日志为空/被清除 | 告知用户无法获取历史数据，建议等待下次崩溃后再诊断。检查是否有清理日志的定时任务 |
| 非 Windows 系统 | 提示本 skill 仅支持 Windows，建议用户说明实际系统 |
| 没有管理员权限 | 部分命令可能失败（如 powercfg /energy），说明哪些信息因权限不足无法获取 |
| 找不到 minidump | 检查系统是否配置了写入调试信息：wmic RECOVEROS get DebugInfoType。值为 0 表示未配置 |
| 用户描述模糊（如"电脑卡"） | 先问清是蓝屏死机还是性能卡顿。如果是后者，本 skill 不适用，建议用任务管理器排查 |
Q1: 为什么需要管理员权限？
A: 读取系统事件日志和 minidump 文件需要管理员权限。如果权限不足，部分命令会失败。
Q2: MEMORY.DMP 和 minidump 有什么区别？
A: MEMORY.DMP 是完整内存转储（可能 10-20GB），minidump 是精简版（通常 5-10MB）。日常诊断 minidump 足够，WinDbg 分析不受影响。
Q3: BugcheckCode=0 但系统确实崩溃了是怎么回事？
A: 说明是强制断电（长按电源键）或电源中断，Windows 来不及写入崩溃信息。
Q4: 为什么建议去制造商官网而非 Windows Update 下载驱动？
A: 制造商认证驱动经过了特定机型的兼容性测试，而 Windows Update 推送的通用版驱动可能在特定硬件组合上不稳定。
Q5: 单根内存条和两根有什么区别？
A: 单根内存无冗余，硬件错误直接导致蓝屏。两根组成双通道支持 ECC 或至少有关联校验，不容易出现随机 bit 错误。
Q6: Modern Standby (S0) 和传统睡眠 (S3) 哪个更好？
A: S0 唤醒更快但后台仍在活动（易导致待机中崩溃），S3 更稳定但唤醒较慢。如果频繁待机崩溃，改休眠是最稳妥的方案。
Q7: 诊断结果无法确定唯一根因怎么办？
A: 多种 Bugcheck 交替出现通常指向硬件问题（内存、CPU）。先跑 mdsched.exe 内存诊断，排除硬件后再排查驱动。
| 错误做法 | 问题 | 正确做法 |
|---|---|---|
| ---------- | ------ | ---------- |
| 只看 Event 41 不看 Event 1001 | 错过 Bugcheck 代码和参数 | 同时查 WER Event 1001 获取完整崩溃参数 |
| 发现 IMAGE_NAME=ntoskrnl.exe 就说是内核 bug | 99% 情况下是第三方驱动导致内核崩溃 | 看 STACK_TEXT 定位真正的第三方驱动 |
| 发现一个可疑驱动就下结论 | 多样 Bugcheck 类型通常不是单一驱动问题 | 综合模式分析 + WHEA 硬件错误 + 驱动年龄审计 |
| 漏查 LiveKernelReports | 错过 WHEA 0x124 等硬件错误证据 | 每次都检查 C:\Windows\LiveKernelReports |
| 忽略 DriverDate 只看 DriverVersion | 版本号格式不一致无法对比 | 用 DriverDate 判断驱动是否过时更可靠 |
每轮诊断完成后必须使用此模板，不要自定义格式：
## [最近一次关机/蓝屏/待机异常] 分析 — YYYY-MM-DD HH:MM
### 基本信息
| 项目 | 详情 |
|------|------|
| 电脑型号 | |
| 系统版本 | |
| 内存 | |
| 时间 | |
| 类型 | [正常关机/蓝屏崩溃/强制断电/待机卡死] |
| Event ID | |
| Minidump | |
### 蓝屏详情（如有）
| 参数 | 值 | 含义 |
|------|------|------|
| Bugcheck | **0x___** | |
| 故障驱动 | | |
| 故障进程 | | |
| 故障函数 | | |
### 时间线
| 时间 | 事件 ID | 说明 |
|------|---------|------|
### 历史异常汇总
| 日期 | Bugcheck | 驱动/进程 | 模式 |
|------|----------|-----------|------|
### 根因分析
[必须引用具体证据（Event ID + 数据），区分直接原因和深层原因]
### 建议
按优先级排列，每个建议都是可执行的具体操作
scripts/check_shutdown_events.ps1 — 关机事件快速扫描scripts/check_crash_detail.ps1 — 蓝屏详情（WER + minidump + LiveKernelEvent）references/windbg_guide.md — WinDbg 安装、配置符号、分析命令完整指南references/bugcheck_reference.md — 常见 Bugcheck 代码速查表共 1 个版本