Windows 11 可靠性监视器怎么用？快速发现系统崩溃和程序错误

Windows 11 内置了一个非常适合故障初筛的工具，叫作“可靠性监视器”（Reliability Monitor）。它不像事件查看器那样把大量系统事件全部堆在日志中，而是按照日期整理系统故障、应用程序崩溃、Windows 错误、驱动或硬件相关问题以及软件安装和更新等信息。

对于经常遇到 Windows 11 随机崩溃、程序突然退出、蓝屏、系统异常重启的技术人员来说，可靠性监视器最大的价值不是直接告诉你“哪个硬件坏了”，而是提供一条比较容易阅读的故障时间线。

例如一台电脑最近一周出现过三次浏览器崩溃、两次显卡驱动相关异常以及一次蓝屏。如果只打开事件查看器，很容易面对大量日志而不知道从哪里开始。可靠性监视器可以先把这些异常按照日期集中显示，然后再根据具体事件回到事件查看器、转储文件和硬件测试工具进行深入分析。

Windows 11怎么打开可靠性监视器

最直接的方法是按 Win + R，输入：

perfmon /rel

然后按 Enter。

也可以在 Windows 搜索中输入“可靠性监视器”或者“查看可靠性历史记录”。

这里需要区分 perfmon 和 perfmon /rel。perfmon 本身用于打开 Windows 性能监视器，而 perfmon /rel 用于打开可靠性监视器界面。

可靠性监视器实际上属于 Windows 管理工具的一部分，并不需要额外下载安装。

打开以后，可以看到按照日期排列的稳定性历史。系统会把不同类型的事件放在相应日期下面，例如应用程序失败、Windows 失败、其他失败、警告以及软件安装等。

不同 Windows 版本的界面细节可能有所区别，因此不应该把某一个版本的按钮名称当成所有 Windows 11 安装环境都完全一致的界面。

红色叉号不等于硬件坏了

可靠性监视器最容易被误解的地方，就是颜色和图标。

红色错误图标表示系统记录到了某类失败事件，但它并不意味着电脑硬件已经损坏。

例如一个普通桌面程序因为自身 Bug 崩溃，可靠性监视器可能记录一次应用程序失败。某个程序一天崩溃三次，可能意味着软件本身存在问题，也可能与插件、驱动、系统组件或者外部依赖有关。

同样，一次蓝屏也不能仅凭可靠性监视器就判断是内存、CPU、显卡还是电源故障。

因此可靠性监视器应该被理解成“故障时间线和初步分类工具”，而不是自动诊断系统。

不要迷信可靠性指数

可靠性监视器会显示一个稳定性指数，用于从历史角度反映系统近期的稳定性变化。

但这个数字不能简单理解成电脑的“健康百分比”。

例如把“低于80分”规定成必须维修，并没有通用的技术依据。不同电脑的软件数量、运行时间、应用类型和使用方式都不同，一台长期运行专业软件的工作站与一台只运行几个简单程序的办公电脑，本来就可能产生完全不同的事件数量。

因此，可靠性指数更适合观察趋势。

如果一台电脑过去长期保持稳定，最近几天指数突然明显下降，同时每天出现新的应用崩溃、驱动异常或者 Windows 故障，那么这个变化非常有调查价值。

反过来，如果系统长期存在少量无关紧要的第三方程序崩溃，但用户实际使用完全正常，也不能仅仅因为数字下降就开始大规模修改系统。

查看具体故障比看分数重要

点击某一天的故障事件，可以看到更加具体的信息。

应用程序崩溃通常可以看到发生时间、故障应用程序、故障模块以及部分错误信息。

如果是 Windows 错误或者系统故障，则可能提供更进一步的描述。

技术人员真正需要关注的是故障发生时间、故障类型、相关程序或组件，以及它与其他系统事件之间的时间关系。

例如某个应用在安装新版本显卡驱动十分钟后开始持续崩溃，这个时间关系比单独看到一个“应用程序错误”更有价值。

如果每次蓝屏之前都出现 WHEA 相关硬件错误，那么调查重点也应该从普通应用程序转向硬件稳定性、PCIe、CPU、内存、存储或者其他底层组件。

可靠性监视器提供的是入口，后面的判断必须依赖更多证据。

蓝屏不能只看可靠性监视器

Windows 11 出现蓝屏时，可靠性监视器可能帮助你确定蓝屏发生的时间和大致类型，但它不是分析蓝屏转储文件的主要工具。

如果系统配置了小型内存转储，通常可以在：

C:\Windows\Minidump

找到 .dmp 文件。

进一步分析时，WinDbg 的价值远高于单纯查看可靠性监视器。

例如蓝屏代码 0xA 对应 IRQL_NOT_LESS_OR_EQUAL，它可以帮助缩小调查范围，但并不能直接证明某一个驱动程序或者某一根内存条损坏。

如果不同时间出现多个不同蓝屏代码，尤其是同时出现 WHEA、内存异常、PCIe 错误或者随机程序崩溃，那么就应该考虑系统整体稳定性，而不是看到某一个代码以后马上卸载某个驱动。

可靠性监视器和事件查看器应该配合使用

事件查看器适合查看更加详细的系统事件，而可靠性监视器适合快速建立时间线。

例如可靠性监视器显示电脑在下午 3:15 发生一次系统故障，那么可以回到事件查看器的 System 日志，以相同时间点寻找 WHEA、存储、显示驱动、服务控制管理器以及其他相关事件。

这里尤其要正确理解 Kernel-Power 事件。

常见的 Event ID 41 表示系统没有正常完成关机过程，例如突然断电、系统重启、死机后被强制重启等。

它本身不能证明电源供应器存在故障。

如果 Event ID 41 每次都出现在高负载游戏或者 GPU 压力测试之后，那么 PSU、GPU、VRM、温度以及系统稳定性确实值得调查，但还需要更多证据。

同样，如果可靠性监视器记录蓝屏，事件查看器中的相关记录也只是辅助信息。真正深入的蓝屏分析通常应该结合 Minidump 和 WinDbg。

PowerShell可以帮助批量寻找系统事件

对于技术人员来说，不一定每次都要在事件查看器图形界面中翻日志。

例如可以使用 PowerShell 查询 System 日志中的 Kernel-Power：

Get-WinEvent -FilterHashtable @{
LogName='System'
ProviderName='Microsoft-Windows-Kernel-Power'
}

如果需要围绕具体故障时间分析，可以进一步结合时间范围、事件 ID 和 Provider 过滤。

这种方式尤其适合处理重复发生的问题。

例如电脑每天晚上 10 点左右发生一次异常重启，就可以围绕这个时间段同时检查系统事件、驱动事件、WHEA 和应用程序错误，而不是只盯着可靠性监视器上的一个红色图标。

应用程序反复崩溃应该先判断故障范围

如果可靠性监视器显示某个应用程序连续出现错误，不要第一时间就运行 sfc /scannow。

先判断故障是不是只发生在这个应用。

如果只有某一个程序崩溃，而其他程序运行正常，那么应该优先检查该程序版本、插件、配置文件、用户配置、相关运行库以及程序自己的日志。

如果多个完全无关的软件开始随机崩溃，情况就不同了。

例如浏览器、压缩软件、游戏和开发工具都出现随机退出，而且故障时间分散、错误模块不断变化，那么内存稳定性、CPU 稳定性、GPU、存储以及驱动环境都应该进入调查范围。

如果所有问题都发生在某个驱动更新之后，则驱动版本和系统变更历史的重要性会上升。

诊断应该根据故障模式变化，而不是看到一个错误就执行固定维修步骤。

SFC和DISM不是万能修复工具

可靠性监视器发现系统组件相关错误后，可以考虑使用：

sfc /scannow

以及：

DISM /Online /Cleanup-Image /RestoreHealth

它们主要用于检查和修复 Windows 系统文件以及组件存储相关问题。

但这两个命令不能解决所有崩溃。

如果故障原因是 defective RAM、GPU VRAM、显卡 VRM、CPU 不稳定、PCIe 链路异常或者 SSD 本身出现硬件问题，系统文件完整性检查不会把这些硬件修好。

因此，在硬件稳定性问题中，SFC 和 DISM 应该属于系统完整性检查手段，而不是通用“修电脑命令”。

内存问题需要独立测试

如果可靠性监视器显示不同应用程序随机崩溃，而且故障模式没有明显的软件共同点，内存稳定性值得优先检查。

Windows 自带的 Windows Memory Diagnostic 可以作为基础检查工具。

如果问题严重或者具有明显的随机性，技术人员通常还会使用更加专业的独立内存测试工具，例如 MemTest86。

同时应该检查 BIOS/UEFI 中的 XMP 或 EXPO 配置。

如果系统此前经过超频、降压或者内存参数调整，在诊断阶段最好先恢复到平台默认稳定配置。

特别是“Windows 可以正常启动”不能证明内存完全正常。

内存错误可能只在特定温度、地址范围、负载模式或者内存控制器状态下出现，因此轻度日常使用没有崩溃并不能排除硬件稳定性问题。

存储故障不要只看Windows磁盘检查

如果可靠性监视器和事件查看器同时出现存储相关错误，可以进一步检查 SSD 或 HDD 的健康状态。

SMART 或 NVMe Health 数据可以通过 CrystalDiskInfo、厂商工具以及其他专业工具查看。

但也不要只看到某一个 SMART 字段异常就直接判定 SSD 已经损坏。

不同厂商的 SMART 属性定义可能不同，NVMe 健康信息也应该结合具体设备型号、错误计数、介质错误、寿命指标、温度和实际 I/O 行为进行判断。

如果存储设备已经出现读写错误或者数据异常，第一优先级应该是备份重要数据，而不是马上进行大量破坏性测试。

Windows 的文件系统检查可以发现文件系统层面的错误，但它和 SSD NAND、控制器、固件以及实际介质健康检查不是一回事。

电源问题不能靠一次万用表测量下结论

如果电脑经常在高负载下突然黑屏、重启或者完全掉电，电源供应器当然需要进入调查范围。

但“用万用表测到 12V 正常，所以 PSU 没问题”同样不成立。

万用表非常适合检查静态或者低频变化的电压，但电源在 CPU、GPU 突然进入高负载时可能出现瞬态响应问题，普通万用表很难完整捕捉这些变化。

专业诊断还可能涉及示波器、负载测试以及对电源保护动作、纹波和瞬态响应的分析。

同时需要检查模块化电源线、GPU 辅助供电连接器、接头温升以及线材状态。

电源额定瓦数也不能单独作为判断依据。实际系统稳定性还与 12V 输出能力、瞬态响应、保护机制、连接器和 CPU 加 GPU 的联合负载有关。

GPU和PCIe问题也可能表现成软件崩溃

如果可靠性监视器记录大量应用程序崩溃，同时事件查看器出现显示驱动重置、WHEA 或 PCIe 相关错误，就不能只把问题归类为“Windows 软件故障”。

GPU 核心、VRAM、GPU VRM、PCIe 链路、主板插槽、CPU 的 PCIe Root Complex、供电以及驱动都可能产生类似症状。

这时可以使用 GPU-Z、HWiNFO 等工具观察 GPU 状态，并结合压力测试、不同 PCIe 链路状态以及已知正常的显卡进行交叉测试。

如果换一张正常显卡以后问题消失，而原显卡在另一台正常平台上继续出现相同故障，故障范围就明显缩小。

如果换显卡没有改善，而更换电源或者主板以后问题消失，那么调查方向又会发生变化。

这种交叉测试比单纯反复安装显卡驱动更加有诊断价值。

BIOS和驱动更新要结合故障时间判断

可靠性监视器的一大优势，是可以帮助技术人员把软件变更与故障时间放在一起观察。

例如某台电脑长期稳定，安装某个驱动版本之后开始频繁出现显示驱动崩溃，那么这个时间关系值得调查。

同样，如果更新 Windows、BIOS、芯片组驱动、显卡驱动或者某个安全软件之后开始出现异常，也应该记录具体版本和安装时间。

但“故障发生在更新之后”仍然不等于“更新一定是原因”。

更新可能只是改变了系统负载、驱动路径或者硬件功能启用状态，从而暴露原本已经存在的稳定性问题。

因此版本回退可以作为诊断实验，但不应该在没有记录原始状态的情况下盲目修改大量系统组件。

可靠性监视器不是所有日志的总入口

原稿中把可靠性监视器描述成可以查看“所有异常事件”，这个说法过于绝对。

Windows 系统产生的事件非常多，可靠性监视器只是从 Windows 的事件和诊断数据中整理出适合稳定性观察的一部分信息。

它不是 Event Viewer 的完整替代品，也不是 ETW、WPR/WPA、WinDbg、ProcDump 或硬件诊断工具的替代品。

如果问题属于程序崩溃，程序自己的日志和崩溃转储可能更加重要。

如果问题属于内核崩溃，Minidump 和 WinDbg 更有价值。

如果问题属于性能异常，Resource Monitor、Performance Monitor、WPR/WPA 等工具更加合适。

如果问题属于网络故障，则需要根据情况使用网络日志、连接信息甚至 Wireshark 等工具。

如果问题属于硬件稳定性，则应该结合内存测试、SMART/NVMe Health、GPU 压力测试、示波器以及其他硬件诊断手段。

不要为了“清理错误记录”而删除日志

可靠性监视器记录的是历史状态。发现红色错误并不意味着应该马上删除记录。

对于故障排查来说，历史记录本身就是证据。

尤其是随机蓝屏、偶发重启和间歇性程序崩溃，时间线非常重要。如果每次出现错误都先清理日志，反而可能让后续诊断失去重要的时间关联。

如果需要提供给其他技术人员分析，应该保存相关信息，包括故障时间、事件名称、应用程序版本、Windows 版本、驱动版本以及相关转储文件，而不是只截一张可靠性监视器的红色图标。

最有效的用法是建立故障时间线

可靠性监视器真正适合的工作方式，是先确定“什么时候开始出问题”。

例如一台 Windows 11 电脑过去三个月都很稳定，从 8 月 20 日开始出现随机程序崩溃。打开可靠性监视器后发现，从 8 月 20 日开始同时出现显卡驱动错误和多个应用程序失败。

接下来就可以检查当天是否发生 Windows Update、显卡驱动更新、BIOS 更新、硬件更换或者系统配置变化。

如果同时存在 WHEA，那么硬件稳定性调查优先级提高。

如果只有一个应用程序反复崩溃，而其他软件稳定运行，那么应用自身问题的可能性提高。

如果每天高负载运行一段时间后才发生异常，则 CPU、GPU、内存、供电和温度等因素需要结合负载条件进行测试。

这种从时间线开始，再根据故障模式逐步缩小范围的方法，比“看到红色错误就修复系统文件”更加可靠。

Windows 11 可靠性监视器最大的价值，就是把原本分散在大量系统事件中的稳定性变化整理成一条比较容易阅读的历史记录。它特别适合回答一个问题：电脑究竟从什么时候开始不稳定，以及不稳定之后发生了什么。

但它不会替技术人员完成最终诊断。应用程序崩溃需要看应用和崩溃模块，蓝屏需要看转储文件和 WinDbg，硬件稳定性需要结合 WHEA、内存测试、存储健康、GPU 和电源测试，性能问题则需要使用对应的性能分析工具。

把可靠性监视器当作故障时间线，而不是“电脑健康检测器”，才能发挥它在 Windows 11 故障排查中的实际价值。