數字一直往上爬先別買 RAM：Win11 記憶體洩漏排查的三段順序

10 月 6 日一篇流傳的教學文，把 Win11 記憶體用量偏高的排查流程整理成一條動線：先工作管理員，再效能監視器，最後才是 RAMMap。這套順序的核心邏輯只有一句話：記憶體洩漏看的是「同一個程序的用量在數小時內持續增加，工作結束後仍不回落」，而不是當下那一個百分比。

這也延續了先前 PTT 鄉民在吵的那幾個數字的基本功，與工作管理員該先看哪四個數字的討論是同一條線：先分清快取與壓力，再判斷異常。

先分清楚：三種畫面不能畫上等號

來源整理了三種常見情境，對應三種完全不同的處理方向：

• 開機後記憶體百分比偏高，但一整天大致平穩：可能是正常工作負載、快取或背景服務，先記錄基準。
• 同一程序的記憶體或已認可持續增加，關閉程序後才下降：有理由往應用程式或外掛的洩漏方向查。
• 非分頁集區長時間增加，程序清單找不到對應來源：可能涉及驅動程式或核心元件，交由 IT 或裝置支援處理。

Microsoft 的欄位對照把 Working Set（程序目前駐留在實體 RAM 的頁面）與 Commit Size（認可用量）列為不同指標，看曲線時不能混為一談。

第一步：工作管理員建基準

按 Ctrl + Shift + Esc 開工作管理員，進「處理程序」與「效能」的記憶體頁。先不要結束任何程序，記下幾件事：

• 卡頓前後的時間點，以及當時在跑的程式、瀏覽器分頁或遊戲。
• 程序的「記憶體」用量；介面允許的話，加入「已認可」「控制代碼」等欄位。
• 效能頁的「可用」、已認可與認可限制、分頁集區與非分頁集區。
• 工作結束後等 5 到 10 分鐘，再記一次同一程序的數值。

來源的判斷標準是三個訊號同時成立才值得列入可疑名單：相同工作負載下用量反覆升高、工作結束後不回落、重開程序才恢復。只看到一次高數字，先不要寫成記憶體洩漏。

第二步：效能監視器看長時間趨勢

按 Windows 鍵 + R 輸入 perfmon，在效能監視器加入三個計數器：Pool Nonpaged Bytes、Pool Paged Bytes、Paging File 的 % Usage。取樣間隔可設 600 秒（每 10 分鐘一次）；若問題一天才出現一次，觀察時間可拉到 24 小時。這兩個數字是 Microsoft 文件的範例，不是固定門檻。

觀察期間讓程式照平常流程運作，記下開檔、匯出、同步、編譯的時間。官方也提醒，洩漏可能要數小時才累積看得出來，剛開始的快速變動不能直接下結論；而 PerfMon 只能記錄變化，無法單獨確認來源是使用者模式還是核心模式。

第三步：RAMMap 比對實體記憶體

最後才用 RAMMap 比對實體記憶體的組成，看用量到底落在哪些頁面類型，再回頭對照前兩步的紀錄。之後才是處理背景程式、Clean Boot 等收斂手段。

整條動線說穿了就是慢功夫：先有基準，才有比較；先有時間軸，才有「不回落」這個證據。急著裝清理工具或加 RAM，往往只是把問題的曲線藏起來。