5% CPU 使用率於閒置且服務根本沒在跑
15–20% 於閒置且服務有在跑
這是一台 8 核心的第 9 代 i7，結果閒置就吃掉 20%？
版本是 2.5 Beta 5（是的，我可以更新，但如果這方面沒有任何改動，我目前看不出更新的意義）
我也看到同樣的情況。使用 Sysinternals 的 Process Explorer 對 MCE Buddy 中出問題的執行緒進行執行緒傾印，似乎顯示它被鎖在某種網路連線或 DNS 查詢中（查詢的東西在 DNS 中不存在，像是 localhost 上的另一個行程，或是內部網路上的另一台主機？）。除了「無法連線到伺服器」之外，我還遇到這種無法解釋的高 CPU 使用率，並已在另一個討論串中記錄了細節。
現在要是有人能分享一些對這件事的見解就好了。
感謝您回報此問題。我已經複製了這個問題並找出了根本原因。當 GUI 用戶端嘗試判斷它是在本地還是遠端機器上執行時，就會發生這種情況（Windows 最終會對其主機名稱進行 DNS 查詢，導致 CPU 使用率過高）。我們正在努力修復。
CPU 問題已在今日 2.5.6 BETA 版本中修復
謝了兄弟，我來試試看。
可確認已在 2021-04-27 的 2.5.6 BETA 版中修復。
尝试运行 SysInternals Process Explorer（直接从 Microsoft.com 下载），然后复制/粘贴占用 CPU 的线程的线程堆栈。
可以，如果需要我會幫忙。希望這些症狀能幫他們釐清問題。
我想现在我只能先关掉服务，等有积压时再启动。这有点违背初衷，但当它这样消耗使用量时，也只能如此。
我没有看到该服务在空闲时使用任何 CPU。您是否尝试过禁用 UPnP 和防火墙设置？
它們從來沒有啟用過，老兄。你傳截圖給我的時候我檢查過了，那時它們就已經是未勾選的狀態。
我這邊無法重現問題，請問您是否有監控任何網路資料夾？
使用 @mike808 提到的工具來找出 CPU 時間的確切花費位置，可能有助於決定後續步驟。
clr.dll!LogHelp_NoGuiOnAssert+0x5e8c9
clr.dll!LogHelp_NoGuiOnAssert+0x5e206
clr.dll!LogHelp_NoGuiOnAssert+0x5e3e8
clr.dll!LogHelp_NoGuiOnAssert+0x431a8
clr.dll!LogHelp_NoGuiOnAssert+0x43e06
clr.dll!LogHelp_NoGuiOnAssert+0x5b71c
clr.dll!LogHelp_NoGuiOnAssert+0x5c25f
clr.dll!LogHelp_NoGuiOnAssert+0x5c173
clr.dll!LogHelp_NoGuiOnAssert+0x5dfb7
clr.dll!LogHelp_NoGuiOnAssert+0x60207
clr.dll!LogHelp_NoGuiOnAssert+0x40108
[托管到非托管转换]
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.String.InternalSubString+0x24
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ParseSetting+0x102
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.Parse+0x1b6
C:\Program Files\MCEBuddy2x\SharpConfig.dll!SharpConfig.ConfigurationReader.ReadFromString+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Util.dll!MCEBuddy.Util.Ini..ctor+0x57
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.CheckAndAddFile+0xa3
C:\Program Files\MCEBuddy2x\MCEBuddy.Engine.dll!MCEBuddy.Engine.QueueManager.ScanForFiles+0xdf8
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.RunInternal+0x172
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x15
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ExecutionContext.Run+0x55
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Threading.ThreadHelper.ThreadStart+0x55
[非托管到托管转换]
clr.dll!LogHelp_TerminateOnAssert+0x1b93
clr.dll!LogHelp_TerminateOnAssert+0x1aa4
clr.dll!LogHelp_TerminateOnAssert+0x2358
clr.dll!MetaDataGetDispenser+0x12a2f
clr.dll!LogHelp_TerminateOnAssert+0x2f50
clr.dll!LogHelp_TerminateOnAssert+0x2ec3
clr.dll!LogHelp_TerminateOnAssert+0x2e02
clr.dll!LogHelp_TerminateOnAssert+0x2fe7
clr.dll!MetaDataGetDispenser+0x12919
clr.dll!LogHelp_TerminateOnAssert+0x6835
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
所以这是在资源管理器的“线程”选项卡中点击“堆栈”的结果，我想这就是你提到的。这是在空闲状态下占用约16%时抓取的。
它监控的路径位于Drivepool的一部分。D:/MCEBuddy，其中D是一个drivepool实例。然而池中的驱动器都连接到同一台机器，所以不，它不是通过网络进行监控的。
奇怪。看起來它正在解析設定檔中的某些內容，然後正在執行可能需要 UAC 或某種使用者輸入但無法完成的操作。
會不會是字元集或編碼問題？@AustinWBest 你是否使用國際鍵盤、檔案系統選項，或者檔案路徑中是否包含「智慧引號」或其他非美國字元？預設值是否已設定？只是為了排除它是否試圖取得無法取得的使用者選擇，因為 Windows 在某些情況下無法取得主控台輸入（主要是驅動程式，但這可能不是那種情況）。
這不會對我的 MCEBuddy 造成問題，但通常會顯示帶有撇號的名稱（例如「Cook’s Kitchen」或「Rory O’Connell」）會被解析為單右引號而非撇號（或相反），導致它們出現在不同的目錄和檔名中。這也會影響元資料，但那是小事。
也許你在 DrivePool 上的資料夾使用了與設定檔不同的字元集編碼，或發生了其他類似的奇怪情況。
@Goose 必須深入研究使用 DrivePool 是否會改變 MCEBuddy 需要使用的東西（API？），如果這就是問題根源的話。我沒用 DrivePool，所以無法提供相關回饋。
检查你的History文件、manual文件以及其他MCEBuddy配置文件。其中一个可能已损坏。先从清空历史和manual文件开始（直接删除它们），如果问题仍未解决，你可能需要全新安装。