Windows 效能監視器 PerfMon 教學:長時間記錄 CPU、磁碟與記憶體異常

⚡ 站長快讀:核心重點

• 文章屬性:教學實戰(A5 電腦疑難雜症)
• 適用系統:Windows 11 / Windows 10
• 難易度 / 耗時:中等 / 初次設定約 20 分鐘
• 核心結論:效能監視器 PerfMon 的價值不在即時曲線,而在「資料收集器集合」能連續寫檔,讓你事後回查三天前的半夜。
• 適用對象:電腦偶發卡頓、發作當下來不及開工作管理員的人。

📌 快速答案

一句話答案:效能監視器 PerfMon 用「資料收集器集合」設定要記錄的效能計數器、取樣間隔與檔案輪替規則,就能長時間把 CPU、磁碟與記憶體數值寫成記錄檔,事後回放比對異常時段。

🧰 開始前的準備

• 系統需求:Windows 11 或 Windows 10。本文用到的 logman、typeperf、relog、lodctr 四支指令,Microsoft Learn 參考頁均標註適用 Windows 11、Windows 10 與 Windows Server 2016 至 2025。
• 權限需求:建立與啟動資料收集器集合需要系統管理員權限(以「系統管理員身分」開啟終端機或命令提示字元)。
• 需要工具:全部內建,不必安裝任何第三方軟體。開啟方式:Win + R 輸入 perfmon 後按 Enter。
• 磁碟空間:預留至少 1–2 GB。長時間記錄最容易翻車的地方就是檔案無限長大,本文步驟三會用官方參數把它鎖住。
• 預計耗時:第一次照著設定約 20 分鐘;之後複製同一行指令到別台電腦只要 10 秒。
• 難度門檻:看得懂「複製一行指令貼進命令提示字元」就夠了,不需要寫腳本。

🔍 為什麼你需要這個?

電腦卡頓最討厭的地方在於它不挑時間發作。你正在開會、正在算圖、或者根本人不在電腦前面,它卡了三十秒又自己好了;等你想起來要看工作管理員,畫面早就恢復平靜,CPU 掛在 3%,什麼線索都沒有。工作管理員與資源監視器都是「即時」工具——它們回答的是「現在誰在吃資源」,不是「上週四凌晨兩點誰在吃資源」。這中間的落差,就是效能監視器 PerfMon 存在的理由。

這篇文章跟一般「打開 perfmon 加幾條線」的教學不同,會多講四件事,而且都是實務上真的會害你白做工的地方:

1. 三個內建監控工具的分工地圖:什麼時候該用資源監視器、什麼時候該用可靠性監視器、什麼時候非用 PerfMon 的資料收集器集合不可。用錯工具,再認真也抓不到東西。
2. 記錄檔格式與磁碟成本的取捨:官方文件明確寫了「格式選 csv 時記錄檔大小上限為 2 GB」,而 bincirc(二進位循環)可以讓檔案自己覆蓋舊資料不再長大。多數教學跳過這段,結果讀者跑了三天回來一看,不是磁碟滿了就是記錄斷在中間。
3. 用一行 logman 取代精靈的十一個步驟:GUI 精靈適合第一次認識介面,但它不可複製、不可版控、也沒辦法一次部署到五台電腦。指令版可以直接存成文字檔傳給同事。
4. 判讀方法論:先找時段,再降維:不要一開始就盯著兩百條計數器看。正確順序是先錄一段「正常時段」當基準線,再用 relog 把異常時段切出來、抽稀取樣數,最後才進表格算平均值。

搞清楚這四件事,長時間記錄才會變成可以交差的證據,而不是一堆看不懂的曲線。

先確認你該用哪個工具

Windows 內建的三個監控工具,職責其實切得很乾淨:

如果你要的是「當場抓兇手」,先去看資源監視器完整教學那套流程,比較快。如果你只是想知道「這台機器最近是不是常出事」,可靠性監視器的穩定性圖表一眼就能看完。只有當你需要「連續數值 + 可回放 + 可量化」這三件事同時成立,才輪到本文的主角上場。

🛠️ 實戰步驟

整套流程可以拆成四個動作:選計數器 → 建立集合 → 排程與輪替 → 切窗判讀。先看一次全貌,再照步驟做。

步驟一:先決定要記錄哪些計數器

這一步決定整份記錄有沒有用。計數器路徑的格式是 \物件(執行個體)\計數器,例如 \Processor(_Total)\% Processor Time 就是「處理器物件、全部核心加總的執行個體、處理器時間百分比」。官方 logman 與 typeperf 參考頁的範例都用這條路徑,可以當成你的第一條。

要查系統上到底有哪些計數器可以抓,不必在 GUI 裡一層層展開。typeperf 的官方參數表列出 -q 是「列出已安裝的計數器(不含執行個體)」、-qx 是「列出已安裝的計數器並含執行個體」,兩者都可以只查單一物件:

:: 列出 PhysicalDisk 物件所有計數器(含執行個體),存成文字檔
typeperf -qx PhysicalDisk -o C:\PerfLogs\disk_counters.txt

這是官方範例的改寫版——官方原文的輸出檔寫成 counters.txt,本文改成完整路徑,參數用法完全相同。把輸出檔打開,你會看到一堆完整路徑,直接複製你要的那幾行就好——這比在 GUI 的「新增計數器」視窗裡捲來捲去可靠得多,也不會打錯字。

接著把選好的計數器一行一條,存成一個純文字檔(例如 C:\PerfLogs\counters.txt)。logman create counter 的 -cf 參數說明寫得很清楚:「指定列出要收集之效能計數器的檔案,檔案內每行一個效能計數器名稱」。

一份夠用的通用清單長這樣:

三點重點摘要:

• Avg. Disk sec/Read 的單位是「秒」不是毫秒。看到 0.015 要自己換算成 15 毫秒,這是最多人誤讀的一條。
• **(*) 萬用字元會展開成所有執行個體**。\Process(*) 在一台開了 200 個處理程序的機器上會產生 200 組數列,檔案大小會直接翻好幾倍——先想清楚要不要全抓。
• 不要一次塞五十條。計數器愈多、取樣愈密,檔案愈大、判讀愈痛苦;先從上表十條起步,不夠再加。

💡 為什麼要這樣做?

計數器清單存成檔案而不是寫死在指令裡,你之後換機器、換題目只要改那個文字檔,建立集合的指令一個字都不用動。這也是把設定「可版控化」的第一步。

步驟二:用 GUI 精靈建立第一個資料收集器集合

第一次做建議先走圖形介面,把名詞跟畫面對起來。Microsoft Learn 的官方步驟如下——原文出自 Dynamics 365 Business Central 的產品文件、共十一步,其中挑計數器那幾步是 Business Central 專屬內容,以下已改寫為與產品無關的通用版本:

1. 開啟效能監視器(開始 → 搜尋方塊輸入 perfmon → 選擇對應連結)。
2. 在左側導覽窗格展開 資料收集器集合,在 使用者定義 上按右鍵,選 新增 → 資料收集器集合。
3. 在建立精靈頁面輸入名稱,選 手動建立(進階),按 下一步。
4. 在「要包含哪種資料」頁面勾選 效能計數器,按 下一步。
5. 在 新增計數器 視窗選好計數器與執行個體,按 新增 再按 確定。
6. 在「希望將資料儲存在哪裡」頁面,把 根目錄 設成記錄檔要放的位置。
7. 按 完成 儲存並離開。

建好之後,在 資料收集器集合 → 使用者定義 底下對它按右鍵選 開始 就會立刻收資料,選 停止 就停。官方文件對這兩個動作的描述就是這麼單純。

真正要注意的是精靈沒有強迫你設定、但長時間記錄一定會踩到的兩件事:記錄檔會長到多大、什麼時候自動換新檔。這兩項在 GUI 裡藏在集合的內容對話框裡,而在指令列則是明確的參數——所以下一步我們換成指令版。

步驟三:用一行 logman 建立可重複部署的長時間記錄

logman 官方參考頁對這支指令的定位寫得很白:「建立與管理事件追蹤工作階段與效能記錄,並支援效能監視器的許多功能」。子指令有 create、query、start、stop、delete、update、import、export。

以下這段以系統管理員身分執行,用 ^ 折行,每行都在 80 字元以內:

logman create counter PerfWatch ^
  -cf C:\PerfLogs\counters.txt ^
  -f bincirc ^
  -si 15 ^
  -max 250 ^
  -o C:\PerfLogs\PerfWatch\watch ^
  -v mmddhhmm

逐一對照官方參數表,這幾個旗標各自在做什麼:

• -cf <filename>:指定列出要收集之效能計數器的檔案,每行一個計數器名稱。
• -f <bin|bincirc|csv|tsv|sql>:指定記錄格式。官方在同一格加註「格式指定為 csv 時,記錄檔大小上限會被限制在 2 GB」。長時間記錄選 bincirc(二進位循環)最省事,檔案寫滿設定上限後會回頭覆蓋最舊的資料,不會無限長大。
• -si <[[hh:]mm:]ss>:效能計數器資料收集器的取樣間隔。15 代表每 15 秒取一次樣。
• -max <value>:記錄檔大小上限(單位 MB;若是 SQL 記錄則是最大記錄筆數)。
• -o <path>:輸出記錄檔路徑。
• -v <nnnnnn|mmddhhmm>:在記錄檔名結尾附加版本資訊,mmddhhmm 會變成月日時分,一眼就知道哪個檔是哪個時段。

建好之後啟動與查詢:

logman start PerfWatch
logman query PerfWatch

想讓它只跑一段固定時間、或每天固定時段自動跑,官方參數表也都有對應旗標:

• -rf <[[hh:]mm:]ss>:讓資料收集器執行指定的一段時間。例如 -rf 08:00:00 就是跑滿八小時後自己停。
• -b、-e:分別指定開始與結束收集資料的時間點,格式為 M/d/yyyy h:mm:ss[AM|PM]。
• -r:在指定的開始與結束時間每日重複執行。
• -cnf <[[hh:]mm:]ss>:有指定時間時,經過該時間就建立新檔;未指定時間時,則在超過大小上限時建立新檔。
• -sc <value>:指定效能計數器資料收集器最多收集幾個取樣。

舉個實際情境:懷疑每天上班時段特別卡,就讓它每天早上九點開始、下午六點結束,並且每小時切一個新檔:

logman create counter WorkHours ^
  -cf C:\PerfLogs\counters.txt ^
  -f bin ^
  -si 30 ^
  -b 8/20/2026 9:00:00AM ^
  -e 8/20/2026 6:00:00PM ^
  -r ^
  -cnf 01:00:00 ^
  -o C:\PerfLogs\WorkHours\wh

💡 為什麼要這樣做?

取樣間隔跟記錄長度是一組取捨。抓 30 秒一次、連續三天,和抓 1 秒一次、只錄十分鐘,兩者的檔案大小可能差不多,但能回答的問題完全不同。查「偶發卡頓發生在哪個時段」用前者;查「這 30 秒內誰在搞鬼」用後者。長時間記錄請優先選長間隔,先把時段找出來再說。

把整組設定帶到別台電腦也不必重打:官方 logman 子指令表列有 import | export,說明是「從 XML 檔匯入資料收集器集合,或將資料收集器集合匯出成 XML 檔」。

步驟四:驗證記錄真的有在寫

三個確認動作,缺一不可:

1. 狀態確認:執行 logman query PerfWatch,看它回報的狀態是否為執行中(Running)。
2. 檔案確認:到 -o 指定的資料夾看有沒有產生檔案,以及檔案大小有沒有隨時間增加。-f bin 或 bincirc 產出的是 .blg 二進位記錄檔。
3. 內容確認:在效能監視器左側點 效能監視器 節點,按主控台窗格工具列的 檢視記錄資料 按鈕(官方文件的描述是:按下該按鈕後會開啟效能監視器內容頁並停在 來源 頁籤),在 來源 頁籤選 記錄檔 並加入你的 .blg,再回到 資料 頁籤把計數器加進來。如果曲線畫得出來,代表這份記錄是好的。

官方文件對此的描述是:資料收集器集合為效能計數器收集的資料會儲存到記錄檔(.blg),路徑就是建立時定義的位置;在效能監視器中可以檢視這些記錄檔,取得效能計數器資料的視覺化呈現。

步驟五:用 relog 把大檔切成能看的資料

錄了三天的 .blg 直接用眼睛看是折磨。relog 這支指令的官方定義是:「從效能計數器記錄中擷取效能計數器,轉存成其他格式,例如 text-TSV(定位字元分隔)、text-CSV(逗號分隔)、binary-BIN 或 SQL。」

先問它裡面有什麼。官方參數表寫 -q 是「顯示輸入檔中所指定記錄檔的效能計數器與時間範圍」:

relog C:\PerfLogs\PerfWatch\watch_08201430.blg -q

接著做兩件事——切時間窗、抽稀取樣:

relog C:\PerfLogs\PerfWatch\watch_08201430.blg ^
  -b 8/20/2026 14:00:00 ^
  -e 8/20/2026 15:00:00 ^
  -t 4 ^
  -f csv ^
  -o C:\PerfLogs\slice_1400_1500.csv

對應官方說明:-b 指定從輸入檔複製第一筆記錄的開始時間、-e 指定複製最後一筆記錄的結束時間;-t value 指定以 *n* 筆記錄為取樣間隔,也就是每第 n 個資料點才收進輸出檔,預設是每個資料點都收。

⚠️ 這裡有個官方文件自己就不一致的地方,值得先講清楚:-b/-e 的參數說明寫的是「日期與時間必須是 M/D/YYYYHH:MM:SS 這個確切格式」(中間不留空格),但同一頁上方的語法區塊卻寫成 /b <M/D/YYYY> [[<HH>:] <MM>:] <SS>(日期與時間分開)。上面的範例採用日期與時間中間留空格的寫法;如果你的環境不吃,就照參數說明那行改成不留空格再試一次。

只想留特定幾條計數器?官方 -cf 的說明是:指定列出要納入 relog 檔案之效能計數器的文字檔路徑,一行一條;預設行為則是把原記錄檔中所有計數器都重新記錄一次。

轉成 CSV 之後就好辦了,PowerShell 幾行就能算出某條計數器在該時段的平均值:

# 讀進切好的 CSV,計算指定計數器欄位的平均值
$rows = Import-Csv 'C:\PerfLogs\slice_1400_1500.csv'
$col  = ($rows[0].PSObject.Properties.Name -match 'Avg. Disk sec/Read')[0]
$vals = foreach ($r in $rows) { [double]$r.$col }
[math]::Round(($vals -as [double[]] | Measure-Object -Average).Average, 4)

步驟六:判讀——用基準線,不要用網路門檻

這是整篇最關鍵、也最常被跳過的一段。網路上到處都是「磁碟佇列超過 2 就是有問題」「Pages/sec 超過 1000 就是記憶體不足」這類門檻,但它們幾乎都來自二十年前的機械硬碟時代,套到今天的 NVMe SSD 上會得出荒謬結論。

可靠的做法是先錄一段自己機器的正常時段當基準線:

1. 在你確定「今天很順」的日子,用同一組計數器、同一個取樣間隔錄兩小時,存成 baseline.blg。
2. 出事的那天,再錄一份 incident.blg。
3. 兩份都用 relog 切成同樣長度、同樣抽稀比例的 CSV。
4. 比較同一條計數器的平均值與最大值——差幾倍才是重點,絕對值不是。

這個做法的好處是它自動吸收了硬體差異:你的 SSD 平常讀取延遲是 0.0002 秒,那 0.02 秒就是一百倍的異常;別人的機器是 0.005 秒,同樣的 0.02 秒可能只是正常波動。用自己的基準線比,結論才站得住腳。

判讀時的搭配原則也很簡單:不要單看一條線。CPU 高但佇列長度不高,通常是單一程式吃滿;可用記憶體掉但認可位元組沒動,可能只是快取正常運作;磁碟延遲拉高的同時處理程序的讀寫也拉高,才有辦法指向特定程式。如果比對到某個時間點確實有異常,接著就把那個時間戳拿去事件檢視器交叉比對系統事件,通常線索就浮出來了。

🔬 底層機制:這些數字到底從哪裡冒出來?

理解這一層,你才會知道哪些數字可以信、哪些不能。

第一層:計數器提供者。 Windows 的效能計數器不是一個集中式的監控程式在測量,而是由各個元件(核心、儲存堆疊、網路堆疊、以及各種應用程式)各自「登記」自己要對外公開哪些數值。這些登記資訊存在登錄檔的效能計數器設定裡——這也是為什麼計數器有可能「消失」:登記資料壞掉,數值就再也讀不到,這時要用的是後面回退段講的 lodctr。

第二層:PDH 與取樣。 上層工具(效能監視器、logman、typeperf、relog)透過效能資料輔助程式(PDH)去讀這些計數器。關鍵觀念是:大多數計數器不是「當下的瞬間值」,而是兩次取樣之間算出來的。像 % Processor Time 這種百分比,本質上是拿兩個時間點的累計計時器相減再除以間隔;Pages/sec、Bytes Total/sec 這種帶「/sec」的也是同理。

這件事有兩個直接後果,而且都會影響你的判讀:

• 取樣間隔決定你看得到什麼。 用 30 秒間隔去抓一個持續 3 秒的尖峰,結果會被平均掉成幾乎看不見的小凸起。長時間記錄天生會「磨平」短促尖峰——這是方法本身的限制,不是你設定錯。找到可疑時段後,務必用短間隔再錄一次確認。
• 第一筆資料通常沒有意義。 因為第一次取樣時沒有「上一次」可以相減,很多工具的第一筆值會是 0 或異常值。判讀時把開頭那筆丟掉是常規動作。

第三層:記錄檔格式。 .blg 是二進位格式,好處是同樣的資料量比文字格式省空間,而且保留完整的計數器中繼資料(名稱、單位、時間戳),所以能直接餵回效能監視器畫圖。CSV/TSV 則是把數值攤平成文字,好處是任何試算表或腳本都能讀,代價是檔案大;而且官方那句 2 GB 上限只針對 csv,同一句並未把 tsv 一起列進去。bincirc 是循環式二進位——這是長時間無人值守記錄的預設答案:設定 -max 250,它最多就佔 250 MB,寫滿之後從頭覆蓋,你永遠有「最近的那一段」,而且永遠不會把系統碟塞爆。

第四層:誰在跑這個排程。 資料收集器集合不是靠某個開著的視窗在收資料——你把效能監視器關掉,它照樣在背景跑。這也是為什麼你必須自己記得停:設定好的排程如果沒有結束時間,它會一直寫下去。

🔙 萬一翻車:回退步驟

長時間記錄本身是唯讀觀測,不會改動系統設定,但它會佔用磁碟空間,而修復計數器登記的動作會改寫登錄檔中的效能計數器設定。動手前先看停止條件。

⚠️ 停止條件清單(符合任一,請先停下)

• 不確定目前系統版本或這台是不是公司/學校管控設備,且沒有 IT 授權。
• 系統碟可用空間已低於 10 GB(先清空間,再談長時間記錄)。
• 你打算執行 lodctr 但還沒做步驟一的備份。
• 指令輸出與本文描述不符(例如 logman query 回報找不到指定的資料收集器)。

情境一:記錄檔把磁碟塞爆了

1. 先停掉收集:logman stop PerfWatch。
2. 確認狀態:logman query PerfWatch,確定它不在執行中。
3. 用檔案總管到 -o 指定的資料夾,手動把不需要的 .blg 移到外接碟或刪除。建議用檔案總管操作、不要下批次刪除指令,避免打錯路徑波及其他資料。
4. 重建時把 -f 改成 bincirc 並加上 -max,讓它自己封頂。

情境二:想完全移除這個集合

logman stop PerfWatch
logman delete PerfWatch

logman delete 的官方定義就是「刪除既有的資料收集器」。這個動作只移除設定,已經寫出來的 .blg 檔案不會跟著消失,要另外自己清。

情境三:計數器整組不見了 / 效能監視器抓不到數值

這代表效能計數器的登錄設定損毀。先備份、再修復,順序不能顛倒:

:: 步驟一:先把目前的計數器登錄設定與說明文字存成備份檔
lodctr /s:"C:\PerfLogs\perf backup1.txt"

:: 步驟二:從目前登錄設定與相關快取效能檔重建計數器登錄設定
lodctr /r

官方 lodctr 參考頁對 /s:<filename> 的說明是「指定要儲存效能計數器登錄設定與說明文字的檔案名稱」,對 /r 的說明是「從目前登錄設定與登錄相關的快取效能檔還原計數器登錄設定與說明文字」;上面第一段指令就是官方頁面自己給的範例寫法。

⚠️ 官方另有一個帶檔名的形式 lodctr /r:<filename>,參考頁在該列標了警告:使用這個指令會覆寫所有效能計數器登錄設定與說明文字,以指定檔案中定義的設定取代之。也就是說,/r(不帶檔名)與 /r:<filename>(帶檔名)是兩個不同的動作,不要混用——除非你很清楚那個檔案的內容是什麼。

另外要注意官方在備註裡點出的陷阱:lodctr 結束代碼 0 只代表指令列語法正確,不代表操作成功,務必回頭看指令輸出有沒有錯誤訊息。

如果修復後仍然抓不到數值,問題可能已經不在計數器本身,而在更底層的 WMI 管理服務——那條線請接著往 WMI Repository 的驗證與修復查(見文末延伸閱讀)。

💡 總結:進階玩法與底層邏輯

站長我在 2026-08-19 逐頁核對了 Microsoft Learn 的 logman create counter、typeperf、relog、lodctr 四份官方參考頁,四頁的「適用於」欄位都同時列出 Windows 11、Windows 10 與 Windows Server 2016 到 2025——這件事的意義是:你在自己的 Windows 11 桌機上練熟的這套流程,原封不動就能拿去處理公司那台伺服器,參數一個字都不用改。這是為數不多、桌機與伺服器完全共用的除錯技能。本文為官方文件查證與整理,非站長第一手實機實測,文中未給出任何自行量測的數值。

三個進階方向,值得你自己往下挖:

• 把設定變成資產。 用 logman export 把調校好的集合匯出成 XML,連同 counters.txt 一起放進你的維修工具包。下次遇到同型別的案子,匯入就能開錄,不必重想要抓哪些計數器。
• 短間隔與長間隔搭配使用。 先用 30 秒間隔、bincirc 封頂錄一整週找時段;鎖定時段之後,改用 1 秒間隔、-rf 限時的第二個集合,在那個時段前後精準補錄。用一個集合想同時做到兩件事,只會兩邊都做不好。
• 把 CSV 交給你熟悉的工具。 relog 轉出的 CSV 沒有任何專有格式,丟給試算表、Python、PowerShell 都行。判讀效能資料的瓶頸從來不是工具,是有沒有基準線可以比。

最後提醒一句實務上的老問題:長時間記錄本身也會消耗資源。取樣間隔設到 1 秒、又把 \Process(*) 全展開,在老機器上是有可能自己造成可觀察負載的。長時間監控請把間隔拉開,別讓量測工具變成被量測的問題。

❓ 常見問題

Q:效能監視器 PerfMon 跟工作管理員的數字對不起來,是誰壞了?

兩邊多半都沒壞,是取樣方式不同。工作管理員刷新頻率與計算口徑跟你在 logman 設定的取樣間隔不一樣,間隔愈長、尖峰被平均掉得愈多,看起來就會比工作管理員「溫和」。比對數字時請用同一個工具的前後兩份記錄比,不要跨工具比絕對值。

Q:一定要用系統管理員權限嗎?一般帳號不能錄?

建立與啟動資料收集器集合屬於系統管理操作,請用系統管理員身分執行。如果你在企業環境沒有本機管理員權限,正確做法是請 IT 協助設定,而不是自己想辦法繞過管控。

Q:記錄檔可以放在網路磁碟或外接碟嗎?

-o 參數接受路徑,技術上可以指定其他磁碟。但長時間記錄寫在網路磁碟上,連線一斷就可能整段資料泡湯;外接碟也一樣,睡眠喚醒後掉盤的機率不低。穩妥做法是寫在本機固定磁碟,結束後再搬走。

Q:我只想錄十分鐘看一下,有沒有更快的方法?

有,用 typeperf 直接把數值印在視窗或寫成檔案就好,不必建立集合。官方範例是:把 counters.txt 裡列的計數器以 5 秒間隔寫進定位字元分隔檔,收滿 50 筆為止——typeperf -cf counters.txt -si 5 -sc 50 -f TSV -o domain2.tsv。官方也註明按 CTRL+C 可以停止 typeperf。

Q:這套方法在舊版 Windows 也適用嗎?

本文用到的四支指令,官方參考頁的「適用於」都同時列出 Windows 10 與 Windows 11,Windows Server 則涵蓋 2016 到 2025。更舊的版本(例如 Windows 8.1 以前)已不在官方參考頁的支援標註範圍內,參數可能有差異,請以該版本自己的 logman /? 輸出為準。

Q:bincirc 的檔案寫滿之後,舊資料是真的被蓋掉嗎?

是。循環式記錄的行為就是寫到上限之後回頭覆蓋最舊的內容,所以它適合「我要的是最近這一段」的長期監看情境。如果你需要保留完整歷史,請改用 bin 搭配 -cnf 定期切新檔,並自己安排搬移與封存。

🔗 延伸閱讀

• DPC_WATCHDOG_VIOLATION 完整除錯教學
• Windows WMI 壞掉怎麼修?Repository 驗證、修復與重建完整教學
• 檔案總管一直閃退或重啟?Explorer.exe 當機完整排查方法
• Win10/Win11 如何檢查 CPU 溫度?這幾款免費工具都可以做到

📎 參考資料來源

📖 第一級|廠商官方:

• logman — 2026-08-19 查證
• logman create counter — 2026-08-19 查證
• typeperf — 2026-08-19 查證
• relog — 2026-08-19 查證
• lodctr — 2026-08-19 查證
• Creating a Data Collector for Business Central Performance Counters — 2026-08-19 查證
• Working with Data Collector sets — 2026-08-19 查證
• View performance counter data for a Data Collector Set — 2026-08-19 查證

⚠️ 本文核心事實以第一級為準。文中所有指令參數說明均引自 Microsoft Learn 對應參考頁,判讀方法論部分為整理自公開文件的操作建議,不含站長第一手實測數據。

📅 本文查證戳記:2026-08-19 依 Microsoft Learn 官方參考頁撰寫。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。