電腦三天兩頭出毛病?Windows 隱藏神器 Reliability Monitor 把你 28 天的暗病全攤開 1

電腦三天兩頭出毛病?Windows 隱藏神器 Reliability Monitor 把你 28 天的暗病全攤開

約 9 分鐘閱讀
作者:
內容目錄 顯示

⚡ 站長快讀:核心重點

  • 文章屬性:教學實戰(A5 底層除錯)
  • 適用系統:Windows 11 25H2 build 26200.8457(KB5089549)、Windows 10、Windows Server 2019/2022/2025
  • 難易度 / 耗時:⭐⭐ / 約 15 分鐘上手
  • 核心結論:Reliability Monitor 是 Vista 時代就內建的穩定性圖表工具,把 28 天內的當機、Windows Update 失敗、驅動程式異常全部視覺化,比工作管理員更能抓出間歇性問題的根因
  • 適用對象:電腦不穩定但說不出哪裡怪、想自己抓問題不想重灌的人
  • 更新日期:2026-05-21

🧰 開始前的準備

  • 系統需求:Windows 7 SP1 以上(本文以 Windows 11 25H2 為主)
  • 權限需求:一般使用者即可,不需要系統管理員權限
  • 需要工具:Windows 內建,不必安裝任何軟體
  • 預計耗時:首次了解約 15 分鐘,日後排查問題每次約 3-5 分鐘

📌 快速答案

一句話答案:Reliability Monitor(可靠性監視器)是 Windows 內建的穩定性追蹤工具,執行 perfmon /rel 即可開啟,用 1 到 10 的 Stability Index 圖表呈現電腦最近 28 天的當機、應用程式失敗與 Windows Update 異常,適合抓出間歇性問題真兇。

🔍 為什麼你需要這個?

你有沒有遇過這種狀況:電腦平常用得好好的,但每隔幾天就會冒出一次莫名其妙的當機、瀏覽器突然關閉、或是某個應用程式無故跳出?你打開工作管理員看 CPU 跟記憶體都正常,事件檢視器點進去又是一坨密密麻麻的 log,翻半天還是不知道問題出在哪。

站長我在 ODM 實驗室待了三十年,看過太多「平常都沒事,demo 給客戶看就出包」的鬼故事。要抓這種間歇性問題,工作管理員的即時快照沒用——你要看的是過去這段時間到底發生了什麼。Windows 內建的 Reliability Monitor 就是專門幹這件事的工具,它幫你把雜亂的事件 log 過濾、加權、視覺化,變成一條 1 到 10 的穩定性曲線。哪天線往下掉,點下去就看到當天發生了哪些事——這比你瞎猜「會不會是上次裝的那個程式害的」要科學一百倍。

更扯的是,90% 的 Windows 使用者根本不知道有這個工具,連很多 IT 工程師也常常忘了它存在。在現在的 25H2 build 26200.8457 上,Reliability Monitor 不但還活著,功能也跟十年前一模一樣穩定。

🛠️ 實戰步驟

步驟一:三種方式開啟 Reliability Monitor

開啟方式有三種,挑最順手的用就好:

方式 1:Win + R 快速啟動(推薦)

按下鍵盤的 Win + R 開啟「執行」對話框,輸入 perfmon /rel 後按 Enter。這是站長最常用的方式,不必滑來滑去找選單。

方式 2:從開始功能表搜尋

按 Win 鍵 開啟「開始」功能表,輸入 可靠性,搜尋結果會顯示「檢視可靠性歷程記錄」,點下去就開了。

方式 3:從控制台進入

開啟「控制台」→「系統及安全性」→「安全性與維護」→ 展開「維護」區塊 → 點「檢視可靠性歷程記錄」。

電腦三天兩頭出毛病?Windows 隱藏神器 Reliability Monitor 把你 28 天的暗病全攤開 3

開啟後,Windows 會先花 5-10 秒讀取 RACAgent 累積的事件資料,然後跳出一個藍色折線圖介面。

步驟二:解讀 Stability Index 圖表

開啟後最上方那條藍色折線,就是 Stability Index(穩定性指數),範圍是 1 到 10——10 代表那一天電腦完全沒出包,數字越低代表問題越多。圖表預設以「日」為單位,可在左上角切換為「週」檢視。

圖表中央是事件圖示區,分成五排:

圖示類別顏色 / 符號意義
應用程式失敗紅圈白 XApp crash、未回應
Windows 失敗紅圈白 X藍白當機(BSOD)、開機失敗
其他失敗紅圈白 X服務異常、硬體錯誤
警告黃三角驚嘆號Windows Update 安裝失敗、驅動程式警告
資訊藍 i 圖示軟體安裝、Windows Update 成功

站長判讀心法:看到曲線往下掉,先看是「紅圈集中爆發」還是「黃三角持續出現」——前者通常是某個應用程式或驅動有狀況,後者多半是 Windows Update 卡關。

點任何一個圖示,下半部會出現「可靠性詳細資料」區塊,列出當天的所有事件。再點下方的「檢視技術詳細資料」連結,可以看到事件 ID、錯誤代碼、影響的模組路徑——這才是真兇所在。

電腦三天兩頭出毛病?Windows 隱藏神器 Reliability Monitor 把你 28 天的暗病全攤開 5

步驟三:進階用法 — 匯出可靠性報告

如果你要把這份資料寄給朋友或 IT 部門協助診斷,可以用內建的匯出功能。

在 Reliability Monitor 主畫面下方,點「儲存可靠性歷程記錄」連結,選一個位置存成 .xml 檔——這個 XML 包含所有事件的原始資料,可以用 Excel 或 PowerShell 進一步分析。

如果你想用 PowerShell 直接撈出原始事件,可以這樣下指令:

powershell

# 撈出最近 7 天的可靠性相關事件
Get-WinEvent -LogName "Application" -MaxEvents 200 |
    Where-Object { $_.LevelDisplayName -eq "Error" } |
    Select-Object TimeCreated, ProviderName, Id, Message |
    Format-Table -AutoSize

💡 為什麼要這樣做?:本指令只查詢系統狀態,不會修改任何設定。Reliability Monitor 圖形介面雖然漂亮,但抓 log 還是 PowerShell 快。

如果你想定期自動匯出可靠性報告,可以搭配 Windows 工作排程器設定每週自動執行。

🧪 硬體測試基準(Testbed Baseline)

項目規格
CPUIntel Core i7-13700H(ODM 工程樣機,stock)
主機板ODM 內部 NB 平台(BIOS 1.13.04,2026-04-22 update)
記憶體Micron DDR5-5200 32GB(2×16GB,SODIMM)
儲存WD SN770 1TB NVMe(韌體 731110WD)
作業系統Windows 11 25H2 build 26200.8457(2026-05-12 KB5089549)
環境條件室溫 25°C(實驗室空調控制)
量測工具Reliability Monitor(內建)、Event Viewer、PowerShell 7.4、Process Monitor v3.96

🔬 底層機制:Stability Index 到底怎麼算出來的?

很多人以為 Reliability Monitor 只是把事件檢視器的資料畫成圖,其實底層架構比這複雜。真正幹活的是一個叫 RACAgent(Reliability Analysis Component Agent) 的隱藏排程任務。

RACAgent 的工作週期

RACAgent 路徑在 C:\Windows\System32\RACAgent.exe,由工作排程器在 \Microsoft\Windows\RAC\RacTask 這個排程下管理。它的工作節奏是這樣:

  • 每小時執行一次:從 Application、System、Security 三個事件記錄中撈出可能影響穩定性的事件
  • 每 24 小時處理一次:把累積的事件丟進加權演算法,算出當天的 Stability Index 分數
  • 保留期 28 天:超過 28 天的舊資料會被滾動式覆蓋——這就是為什麼你看不到「兩個月前那次當機」的原因

Stability Index 的加權算法

依據 Microsoft 在 Windows Reliability and Performance Monitor 官方文件 揭露的概念,Stability Index 不是單純算事件次數,而是套用兩個權重:

  1. 時間衰減權重:越近期的事件權重越大,28 天前那次當機只剩很小的權重
  2. 嚴重度權重:BSOD > 應用程式 crash > 警告;「Windows 失敗」這類嚴重事件對曲線拉低的力道遠大於「應用程式失敗」

新安裝的系統一開始 Index 是滿分 10,每次出問題就往下掉,連續穩定運轉若干天後又會慢慢爬回 10。這個曲線形狀其實透露了你系統的「修復能力」——掉得快爬得也快代表問題是一次性的;持續低檔不回升就要懷疑是慢性硬體問題。

跟事件檢視器(Event Viewer)的差別

比較項Reliability MonitorEvent Viewer
介面視覺化折線圖表格 + 詳細欄位
資料來源已篩選過的穩定性事件全部系統事件(每天數千筆)
適用情境找趨勢、抓間歇性問題查特定錯誤的技術細節
保留期28 天可設定保留期(預設約 30-90 天)

簡單說,Reliability Monitor 是「抓兇手用的儀表板」,事件檢視器是「做筆錄用的卷宗」。先用前者鎖定可疑時間段,再用後者進去看細節,這是站長帶新人除錯時必教的標準流程。

💡 總結:站長的破壞性實驗與第一手經驗

站長我在實驗室做過一個破壞性實驗來驗證 Reliability Monitor 的可信度。實驗條件如上方 Testbed,具體操作如下:

實驗一:RACAgent 停用 72 小時的恢復行為

我把 \Microsoft\Windows\RAC\RacTask 排程任務手動停用 72 小時,期間正常使用電腦。72 小時後重新啟用 RACAgent,當下開啟 Reliability Monitor,結果如預期:圖表顯示「目前尚無可靠性資料可用」,因為 RACAgent 必須跑完一個 24 小時處理週期才會產出當天分數。等了大約 26 小時後再開,圖表才完整呈現。結論:Reliability Monitor 對 RACAgent 排程任務有強依賴性,如果你之前清理排程任務時不小心把 RAC 排程關掉,看到空白圖表別嚇到,重新啟用後等一天就好。

實驗二:連續注入 5 次應用程式 crash 的 Index 下降速率

在實驗機上,我用刻意寫的 unhandled exception 程式在 4 小時內連續觸發 5 次 application crash。隔天觀察 Stability Index,從原本穩定的 10.0 掉到約 4 到 5 之間(實際值會被當天其他事件加權影響,不是固定數字)。停止注入後,第 4 天開始回升到 7 左右,第 7 天回到 9 以上。結論:應用程式 crash 對 Stability Index 的拉低力道明顯,但恢復速度也快——這跟 BSOD 完全不同。BSOD 一次就能把 Index 砸到 3 以下,而且要花一週才慢慢爬回來。

進階玩法:站長我自己的習慣是每個月初看一眼 Reliability Monitor,如果曲線整體下移或出現週期性紅圈,通常就是某個應用程式自動更新後相容性有狀況——這是 ODM 工程師判斷送修 RMA 機是「真壞」還是「軟體吵架」的第一道關卡。一般 3C 部落格不會教這招,但這是省下重灌時間的關鍵心法。

設定完看一眼,你會發現原來電腦不是無緣無故當機的——所有的暗病,Windows 都默默幫你記了 28 天。

❓ 常見問題

Q:perfmon /rel 跟 perfmon 有什麼差別?

兩個都是同一個程式 perfmon.exe,差別在啟動參數。perfmon 不帶參數會開啟完整的「效能監視器」介面,包含計數器、資料蒐集器、報告等功能;perfmon /rel 帶 rel 參數則直接跳到 Reliability Monitor(可靠性監視器)子介面。兩者底層共用同一個 MMC 容器,但呈現的功能模組完全不同。

Q:Reliability Monitor 顯示空白圖表或「目前尚無資料」是怎麼回事?

最常見原因是 RACAgent 排程任務被停用或被某些最佳化軟體誤殺。請開啟工作排程器,進入 \Microsoft\Windows\RAC 路徑,確認 RacTask 是「就緒」狀態而非「已停用」。如果是剛重灌或還原系統,RACAgent 需要約 24 小時才會產生第一筆資料,這時看到空白圖表是正常的。

Q:資料只保留 28 天太短,可以延長嗎?

預設保留期 28 天是 RACAgent 演算法寫死的滾動視窗,沒有官方支援的設定可以延長。如果你需要更長期的可靠性追蹤,建議搭配 Windows 內建的 Event Viewer 自訂檢視(可保留 30-90 天),或用 PowerShell 的 Get-WinEvent 指令定期把資料匯出到外部 log 庫保存,這是站長在實驗室追蹤長期 RMA 機台穩定性時的標準作法。

Q:Reliability Monitor 跟事件檢視器(Event Viewer)我該用哪個?

兩個各有定位,建議混用。Reliability Monitor 適合「抓趨勢」——你電腦最近怪怪的但說不出哪天開始的,先看圖表鎖定時間段。事件檢視器適合「查細節」——已經知道是哪天哪個錯誤,要看具體的事件 ID、模組路徑、stack trace。兩個一起用,排查間歇性問題的效率會比單用任一個高很多。

Q:照著做開不起來,跳出「找不到 perfmon」或「存取被拒」怎麼辦?

perfmon.exe 位於 C:\Windows\System32 路徑,正常 Windows 安裝都有。如果跳出「找不到」,通常是系統檔案損毀,建議先跑一次 sfc /scannow 修復系統檔案。如果是「存取被拒」,代表你目前帳號不在本機系統管理員或 Performance Monitor Users 群組中,請改用其他有權限的帳號登入,或請管理員把你的帳號加入 Performance Monitor Users 群組。

📎 參考資料來源