Windows 11 24H2 更新後變慢：用 LatencyMon 找出 DPC 延遲元凶
換句話說，當你覺得「24H2 之後電腦變慢」，第一步不是重灌，而是先確認你遇到的是哪一種。如果工作管理員顯示一切正常，但你就是覺得卡，那幾乎可以直接往 DPC 延遲的方向去查。
二、DPC 延遲是什麼？為什麼它會讓電腦卡頓
要理解 DPC，得先理解作業系統如何處理硬體中斷。這個機制不難，但它是整篇文章的理論基礎，值得花點時間搞清楚。
中斷、ISR 與 DPC 的三角關係
當你移動滑鼠、網路卡收到封包、SSD 完成一次讀取，硬體都會送出一个「中斷訊號」給 CPU。CPU 收到中斷後，會暫停目前正在執行的工作，跳去執行一段稱為 ISR（Interrupt Service Routine，中斷服務常式） 的程式碼。
問題是，中斷髮生時 CPU 處於非常高的優先級（IRQL），在這個層級下，系統幾乎不能做別的事。如果 ISR 寫得太長，整臺電腦就會被卡住。因此 Windows 的設計是：ISR 只做「最緊急、非做不可」的事（例如把資料從硬體搬到記憶體），剩下的後續處理，就排入一個佇列，等 CPU 降到較低優先級時再執行。這個「稍後處理」的機制，就是 DPC（Deferred Procedure Call，延遲程序呼叫）。
DPC 的執行優先級雖然比 ISR 低，但仍然高於一般使用者程式與大部分系統執行緒。也就是說，只要 DPC 還在跑，你的滑鼠輸入、音訊緩衝、遊戲執行緒就得排隊等。正常情況下，一個 DPC 只花幾十微秒（µs），使用者完全感受不到；但如果某個驅動的 DPC 動輒花上數百微秒甚至數毫秒，而且發生頻率很高，那就會累積成肉眼可見的卡頓。
LatencyMon 量測的核心，就是「從硬體中斷髮生，到使用者程式真正被排程執行」之間的這段時間差。這個數值越小越好，因為它代表系統的即時反應能力。
延遲多高才算有問題？判斷標準
網路上常有人問「我的數字是 800 µs，這樣正常嗎？」答案是：要看你的用途。以下提供一個實務上常用的參考表，這是社群與音訊工作者長期累積出來的經驗值，並非微軟官方標準，但相當實用：
指標
理想值
可接受
需要注意
明顯異常
最高中斷到程序延遲
< 500 µs
500～1000 µs
1000～2000 µs
> 2000 µs
單次 DPC 執行時間
< 250 µs
250～500 µs
500～1000 µs
> 1000 µs
單次 ISR 執行時間
< 100 µs
100～250 µs
250～500 µs
> 500 µs
硬分頁錯誤（Hard Pagefault）
偶發個位數
持續出現
大量且伴隨卡頓
特別提醒：如果你是音樂製作、直播、或對音訊延遲極度敏感的使用者，標準要更嚴格。專業音訊圈普遍認為，中斷到程序延遲應壓在 500 µs 以內，否則在低緩衝區設定下就容易出現爆音（dropout）。而一般文書與上網用途，只要沒有實際感受到卡頓，1000 µs 上下其實可以接受，不必過度焦慮。
DPC 延遲造成的典型症狀
以下這些症狀，如果同時出現兩項以上，就很值得用 LatencyMon 檢查：
播放 YouTube 或音樂時，偶爾出現「啪」一聲的爆音或斷音。
滑鼠指標移動時有輕微「黏滯感」或跳格，尤其在系統閒置後第一次移動時特別明顯。
遊戲中 FPS 數字不低，但體感不順，偶有瞬間凍結（stutter）。
打字時偶爾漏字，或輸入延遲明顯。
觀看影片時畫面與聲音輕微不同步，或畫面週期性微頓。
藍牙耳機連線時，聲音斷斷續續。
插拔 USB 裝置的瞬間，整臺電腦頓一下。
這些現象的共同點是：它們都與「時間」有關，而與「效能」無關。這也是為什麼加記憶體、換顯卡通常無法解決問題。
三、LatencyMon 是什麼？取得與安裝
LatencyMon 是由 Resplendence Software 開發的免費延遲監測工具，最早是為了協助專業音訊使用者排查爆音問題而誕生，後來因為判讀直覺、資訊完整，成為硬體玩家社群的標準工具之一。它會即時監測系統中所有驅動程式的 ISR 與 DPC 執行狀況，並統計出延遲最高的來源。
工具定位與適用範圍
LatencyMon 的強項是「快速定位」，而不是「深度追蹤」。它能在幾分鐘內告訴你「問題出在哪個驅動檔案」，但不會直接告訴你「該怎麼修」。修復仍然要靠你對硬體與驅動的理解，或參考本文第五節的對照表。
另外要釐清一個常見誤解：LatencyMon 不會幫你「優化」系統，也不會自動修復問題。它是一支診斷工具，功能類似醫生的聽診器。網路上有些文章把它說成「一鍵優化神器」，那是錯誤的期待。
取得與安裝方式
請務必從官方網站下載，避免來路不明的「整合版」或「免安裝破解版」，這類檔案有相當高的機率被捆綁惡意程式，反而讓系統更不穩定。官方提供的版本分為免費的 Home 版與付費的 Pro 版；對一般排查需求而言，Home 版的功能已經完全夠用。
安裝過程非常簡單，基本上就是「下一步、下一步、完成」。如果你不想在系統中留下任何東西，官方也提供可攜（免安裝）版本，解壓縮後直接執行主程式即可。建議放在一個固定的資料夾，方便日後重複使用。
第一次啟動的設定建議
安裝完成後，建議先做幾個小設定，讓後續的判讀更準確：
四、實戰：用 LatencyMon 測出你的 DPC 延遲
接下來進入實作。整個流程大約需要 20～30 分鐘，請預留足夠時間，因為短時間的測試很容易漏掉偶發性的延遲尖峰。
步驟一：建立乾淨的測試環境
先把所有非必要的程式關閉，包括瀏覽器分頁、通訊軟體、遊戲啟動器、雲端硬碟同步、以及任何會常駐在系統匣的小工具。接著，暫時拔掉不常用的 USB 周邊（例如外接硬碟、印表機、讀卡機），只保留鍵盤與滑鼠。
這一步的目的，是建立一個「基準線（baseline）」。當你之後一項一項把裝置接回去，就能清楚知道是哪個裝置拉高了延遲。這個方法雖然笨，但非常有效。
步驟二：開始監測並製造負載
開啟 LatencyMon，按下畫面上方的綠色「Start」按鈕，然後開始做以下幾件事，至少持續 10 到 15 分鐘：
播放一段 YouTube 影片或本機音樂（測試音訊路徑）。
移動滑鼠、滾動網頁、開啟資料夾（測試輸入與檔案系統）。
若有玩遊戲，執行一款你常玩的遊戲約 5 分鐘（測試顯示卡與儲存）。
若問題與網路有關，開啟幾個網頁或下載一個小檔案（測試網路驅動）。
重點是「模擬你平常的使用情境」，而不是刻意跑壓力測試。很多人用燒機軟體測，結果延遲一切正常，因為燒機的存取模式與日常使用完全不同。
步驟三：讀懂主畫面的四大指標
LatencyMon 主畫面會顯示幾個關鍵數字，分別是：
畫面下方還有一個長條圖，綠色代表目前狀態良好，黃色代表有輕微延遲，紅色則代表已經達到會影響使用的程度。如果長條圖在測試期間頻繁出現紅色，就代表你的系統確實有即時性問題。
步驟四：從 Drivers 頁籤鎖定元凶
主畫面只能告訴你「有問題」，真正的線索在「Drivers」頁籤。點進去之後，你會看到一份驅動程式清單，欄位包含驅動名稱、DPC 執行次數、ISR 執行次數、最長執行時間（ms）、以及檔案路徑。
判讀邏輯如下：
先按「Highest execution」欄位排序，看最上面幾個驅動是誰。
再看「DPC count」欄位。有時候某個驅動單次執行時間不長，但次數極多，累積起來一樣會造成卡頓。
點選驅動名稱，下方會顯示完整的檔案路徑與版本資訊，這對後續更新驅動非常關鍵。
請注意一個常見陷阱：清單上排名第一的不一定是「壞掉的驅動」，而是「受害者」。例如 Wdf01000.sys 是 Windows 驅動框架，很多廠商驅動都跑在它上面，它延遲高往往代表「某個底層驅動拖累了它」，而不是它本身有問題。這時候就要看它下方的呼叫堆疊，或搭配後續的進階工具來追。
步驟五：用報告與歷史紀錄交叉驗證
測試結束後，按下「Stop」，然後從選單產生一份 HTML 報告。這份報告會完整記錄測試期間的統計資料，方便你存檔、比對，或是在論壇求助時附上。
建議的作法是：每次調整前後都跑一次 15 分鐘測試，並把報告存成不同檔名。例如「調整前.html」「更新網卡驅動後.html」「關閉 C-State 後.html」。這樣你才能客觀判斷每一項調整到底有沒有效，而不是憑感覺。
五、常見 DPC 元凶排行榜與對應解法
以下整理出在 Windows 11 24H2 環境中，最常被 LatencyMon 點名的幾個驅動，以及實務上有效的處理方式。請注意，驅動名稱只是「症狀」，真正的根因可能是硬體韌體、BIOS 設定或驅動版本，因此每一項都要搭配實際測試。
ndis.sys 與網路驅動：24H2 的重災區
ndis.sys 是 Windows 的網路驅動介面規格（NDIS）框架，本身不是網卡驅動，但只要網卡驅動有問題，帳都會算在它頭上。24H2 更新後，Intel、Realtek、Killer 這三家網卡的問題回報特別多，其中 Intel Killer 系列（尤其是搭配智慧流量管理功能的型號）更是惡名昭彰。
處理順序建議如下：
另外，如果你用的是 USB 無線網卡，建議直接換成 PCIe 介面的網卡測試，USB 網卡的延遲天生就比較高，在 24H2 上更容易被放大。
nvlddmkm.sys 與顯示卡驅動
nvlddmkm.sys 是 NVIDIA 顯示卡驅動的核心檔案，也是 LatencyMon 排行榜上的常客。它延遲偏高的常見原因包括：驅動版本與 24H2 不相容、舊驅動殘留、GeForce Experience 背景服務干擾、以及顯示卡的電源管理模式設定不當。
建議的處理流程：
若你是創作者或辦公用戶，可優先考慮 Studio 版驅動，通常比 Game Ready 版穩定。
在 NVIDIA 控制面板中，把「電源管理模式」設為「最高效能優先」。
測試期間暫時關閉 G-Sync／可變更新率，排除顯示同步機制造成的延遲。
檢查是否有背景程式（例如 OBS、Discord、瀏覽器硬體加速）同時存取 GPU，導致驅動排隊。
AMD 顯示卡對應的檔案是 amdkmdag.sys，處理邏輯相同：乾淨移除、重裝、關閉不必要的疊加層與省電功能。
Wdf01000.sys：模糊但重要的線索
前面提過，Wdf01000.sys 是核心模式驅動框架（KMDF），很多周邊驅動都建立在它之上。當它出現在排行榜前段，通常代表「某個使用 KMDF 的驅動有問題」，而不是框架本身故障。
此時你可以：
在 LatencyMon 中點選該驅動，查看下方顯示的呼叫堆疊（如果版本支援）。
改用第五節後段介紹的 WPR／WPA 工具，直接追到最底層的驅動。
用「裝置管理員」逐一停用非必要周邊（藍牙、讀卡機、指紋辨識、RGB 控制器），每停用一項就重測一次。
實務上，RGB 燈效控制軟體、主機板廠的系統監控工具、以及部分電競周邊的虛擬驅動，是 Wdf01000.sys 延遲的常見來源。這類軟體雖然方便，但驅動品質參差不齊，測試時建議先全部移除。
storport.sys 與儲存控制器
storport.sys 是儲存埠驅動，牽涉到 SATA、NVMe、RAID 控制器。若它延遲偏高，常见原因包括 SSD 韌體過舊、使用廠商提供的 RAID 驅動而非 Windows 標準 NVMe 驅動、以及 PCIe 省電機制（ASPM）造成裝置進入低功耗狀態後反應變慢。
可以嘗試：
在裝置管理員中，把「標準 NVMe 控制器」的驅動換成 Microsoft 版本測試，或反之。
確認主機板晶片組驅動已更新到 24H2 相容版本。
HDAudBus.sys 與音訊爆音
如果你是「影片看著看著突然啪一聲」的苦主，那 HDAudBus.sys、portcls.sys 或 RTKVHD64.sys（Realtek 音效驅動）很可能就是元凶。24H2 與部分 Realtek 音效驅動的相容性問題，在國內外都被大量回報。
處理方式：
在音效控制台中關閉「音效增強」「等化器」「空間音效」等功能。
把取樣率與位元深度設為固定值（例如 24 位元／48000 Hz），避免應用程式頻繁切換格式。
若使用 USB DAC 或外接音效卡，測試時先拔除，確認是否是內建音效的問題。
USBXHCI、ACPI 與電源管理
USBXHCI.sys 是 USB 3.x 控制器驅動，若滑鼠鍵盤卡頓、外接裝置反應慢，可以往這個方向查。常見解法是關閉「USB 選擇性暫停」、更新晶片組驅動、以及避免把高速周邊與低速周邊插在同一個控制器上。
ACPI.sys 則與電源管理、C-State、散熱策略有關。筆電使用者若遇到「插電正常、用電池卡頓」，可檢查電源計劃中的「處理器電源管理 → 最小處理器狀態」是否被設為 0%，測試時可暫時調高到 50% 或 100% 觀察差異。部分主機板 BIOS 的 C-State 設定也會影響，建議更新 BIOS 後再測試。
六、進階排查：當 LatencyMon 只給你一個模糊答案
LatencyMon 很方便，但它有時候只會告訴你「Wdf01000.sys 很高」，卻不說是誰害的。這時候就需要更底層的工具。
用 Windows Performance Recorder 與 WPA 深入追蹤
Windows Performance Recorder（WPR）與 Windows Performance Analyzer（WPA）是微軟官方提供的效能分析工具，屬於 Windows ADK 的一部分。它們的學習曲線比 LatencyMon 陡，但能提供「逐筆事件」等級的細節。
基本流程是：先用 WPR 錄製一段包含 CPU 與延遲事件的追蹤檔（ETL），再用 WPA 開啟，切到「DPC／ISR」圖表，就能看到每一筆 DPC 是由哪個驅動、哪個函式觸發，以及花了多少時間。對於頑固的延遲問題，這是最後的殺手鐧。
如果你不想安裝整套 ADK，也可以在命令提示字元中以系統管理員身分執行 xperf 系列的指令來錄製延遲追蹤，效果類似，但同樣需要一點指令列基礎。
用事件檢視器與可靠性監視器交叉比對
有時候延遲不是驅動本身有問題，而是硬體正在出錯。打開「事件檢視器 → Windows 記錄 → 系統」，篩選來源為 Disk、storahci、nvlddmkm、WHEA-Logger 的錯誤或警告，看看測試期間是否有對應事件。若出現 WHEA 錯誤，那可能是硬體層面的問題（記憶體、PCIe 通道、電源供應），單靠驅動調整無法根治。
「可靠性監視器」則可以用時間軸的方式，快速看出最近是否有效能相關的重大事件，適合用來驗證「問題是不是從某次更新後才開始」。
BIOS、晶片組驅動與電源計劃的連帶影響
很多人會忽略一件事：DPC 延遲是軟硬體交界的問題。因此 BIOS 版本、晶片組驅動、以及電源計劃三者必須一起看。建議的順序是：先更新 BIOS 到最新穩定版，再安裝主機板官網提供的最新晶片組驅動，最後才調整 Windows 內的電源計劃。順序顛倒的話，常常會出現「怎麼調都沒效」的挫折感。
七、優化與驗證：把延遲壓回合理範圍
找到元凶之後，接下來就是有系統地優化。這裡提供一個「由外而內」的處理順序，避免東改西改卻不知道哪一項有效。
驅動程式的正確更新順序
建議依照以下順序更新，每次更新後都重跑一次 LatencyMon：
主機板 BIOS 與晶片組驅動。
儲存控制器驅動（含 SSD 韌體）。
網路驅動（有線優先，無線其次）。
顯示卡驅動。
音效驅動。
周邊裝置驅動（藍牙、讀卡機、印表機）。
這個順序的原則是「先處理與主機板最親近的底層，再處理周邊」。底層不穩，上層再怎麼更新都是白費。
電源管理與 C-State 的取捨
把處理器最小狀態設為 100%、關閉 PCIe ASPM、關閉 USB 選擇性暫停，確實可以明顯降低延遲。但代價是耗電增加、風扇轉速提高、筆電續航力下降。因此建議把這些設定當成「診斷手段」而非「永久解法」：先用來確認問題來源，確認後再針對單一裝置做精準調整，而不是全域關閉所有省電功能。
驗證改善成效的正確方法
驗證時請把握三個原則：
同樣的情境：同樣的測試時間長度、同樣的背景程式、同樣的負載類型。
八、常見問題 FAQ
LatencyMon 一定要付費嗎？
不用。免費的 Home 版已經包含延遲監測、驅動排行、報告輸出等核心功能，對一般排查來說完全足夠。Pro 版主要增加的是長期監控與部分進階功能，一般使用者不需要。
測到的最高值只出現一次，需要在意嗎？
要看你出現的是什麼。如果只是單一次 1500 µs 的尖峰，而且你平常完全沒有感覺，那可以忽略。但如果這個尖峰每次測試都出現在同一個驅動，而且伴隨實際卡頓，那就值得處理。判斷的關鍵是「頻率」與「是否可重現」，而不是單一數字。
安全模式下一切正常，代表什麼？
代表問題出在「安全模式沒有載入的協力廠商驅動或服務」。這時可以用「選擇性啟動」搭配「逐一停用服務」的方式，把範圍縮小到具體的軟體或驅動。這是經典的二分法排查，雖然耗時但非常可靠。
更新到 24H2 後問題才出現，可以直接退回 23H2 嗎？
技術上可以，但要注意退回期限（微軟通常提供一段時間的退回窗口），而且退回後仍可能因為驅動版本不同而遇到其他問題。比較建議的作法是先嘗試本文的排查流程，因為多數 24H2 延遲問題都能透過驅動更新解決；真的無解時，再考慮退回或等待後續累積更新修復。
遊戲玩家需要在意 DPC 延遲嗎？
需要，而且感受往往比辦公用戶更明顯。DPC 延遲會直接影響影格時間（frame time）的穩定性，即使平均 FPS 很高，只要出現週期性的延遲尖峰，體感就會是「不順」。如果你已經確認顯卡與 CPU 都不是瓶頸，卻仍有卡頓感，LatencyMon 是非常值得一試的工具。
九、結語：先量測，再動手
Windows 11 24H2 更新後的「變慢」，很少是單一原因造成的。它可能是網卡驅動與新框架的磨合、可能是音效驅動的相容性問題、也可能是電源管理設定在升級過程中被重置。面對這種複合型問題，最忌諱的就是「憑感覺亂調」——關一堆服務、改一堆登錄檔、裝一堆所謂的優化工具，結果問題沒解決，反而製造出新的不穩定。
LatencyMon 的價值，就在於它把「感覺」變成「數字」。它讓你在一開始就知道問題是不是出在即時性、是哪個驅動在拖後腿、以及每一次調整到底有沒有效。這種「先量測、再動手、後驗證」的流程，才是真正能解決問題的方法。
最後提醒幾個實務上的小原則：第一，一次只改一項，改了兩項以上就無法判斷是哪一項見效；第二，保留每次的測試報告，日後回顧會非常有幫助；第三，不要為了一次的尖峰就大動干戈，延遲問題要看趨勢與可重現性。只要按部就班，多數 24H2 的卡頓問題都能在一個下午之內找到方向，讓你的電腦重新回到該有的滑順手感。
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →