5% CPU usage at idle with the service not even running
15-20 at idle with the service running
This is an 8 core 9th gen i7 and it is chewing up 20% at idle?
Version is 2.5 Beta 5 (yes i can update but if there was nothing changed in relation to this i dont see the point currently)
I’m seeing the same thing. A thread dump of the offending thread in MCE Buddy using Sysinternals’ Process Explorer seems to show it is locked in some kind of network connection or DNS lookup (for something that won’t exist in DNS, like another process on localhost or another host on the internal LAN?). I get this unexplainedly high CPU usage in addition to “cannot connect to server”, and noted the details in another thread.
Now if only someone with insight into this would share some of it.
Try disabling the UPnP and Remote access features. It’s the windows/third party firewall that causes the problem.
Thanks for reporting this. I’ve replicated the issue and isolated the root cause. It’s happening when the GUI client tries to determine of it’s running locally or on a remote machine (Windows ends up doing a DNS lookup for it’s hostname which is causing excessive CPU utilization). We’re working on a fix.
The CPU issue has been fixed in today 2.5.6 BETA release
Thanks bud, I’ll give it a go.
Can confirm fixed in 2.5.6 BETA from 2021-04-27.
Will have to disagree :\
I guess some improvement… Not averaging ~20 anymore but now 10-16 is where it fluxuates
Edit: After sitting there watching the process for a few minutes, there seems to be a pattern. It spikes and holds for a min or min/half and the falls off to nothing for about 10 seconds. Then repeats that over and over. So it seems it is trying to do something, times out, then retries a few seconds later?
Try running SysInternals Process Explorer (download direct from Microsoft.com) and copy/paste the thread stack from the thread eating CPU.
Yea I can if needed. Hoping the symptoms shine some light on the issue for em
I guess for now I’ll just kill the service & start it when there is a backlog. Kinda defeats the purpose but not when it’s eating usage like this.
I’m not seeing the service use any CPU when idle. Have you tried to disable the UPnP and firewall settings?
They where never enabled bud. I checked when you sent the screenshot and they where unchecked already.
I’m not able to replicate the issue here, are you monitoring any network folders?
It may help to use the tool mentioned by @mike808 to isolate where the exactly it’s spending it’s cpu time which may give pointers to the next steps
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
[Managed to Unmanaged Transition]
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
[Unmanaged to Managed Transition]
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
So that is clicking “Stack” in the “Threads” tab of the explorer which i assume is what you are referring to. This was from sitting idle and using ~16%
The path it monitors is located as part of Drivepool. D:/MCEBuddy where D is a drivepool instance. However the drives in the pool are all connected to the same machine so no, it isn’t across a network with monitoring.
Weird. Looks like it is parsing the config file for something, and then is doing something that maybe requires UAC or some sort of user input but can’t.
Could it be some sort of character set or encoding issue? @AustinWBest are you setup with an international keyboard, fileysystem options, or perhaps the file paths have “smart quote” characters in them or other non-US characters? Have the defaults been set? Just to rule out that it isn’t trying to get a selection from the user that can’t, since Windows can’t get console input in some cases (mainly drivers, but this may not be that situation).
It doesn’t cause a problem with my MCEBuddy, but often shows with apostrophes in them (“Cook’s Kitchen”, or “Rory O’Connell”) will get parsed with a single-close-quote rather than an apostophe (or vice versa), and they end up in different directories and filenames. It also affects the metadata too, but that’s minor.
Perhaps your folders on the drivepool are using a different character set encoding than the config file or something similarly weird is going on.
@Goose would have to dig into whether or not using DrivePool changes things (the APIs?) that MCEBuddy needs to use if that’s the source of the problem. I don’t use DrivePool, so no feedback there.
Check your History file, manual file and other MCEBuddy configuration files. One of them may be corrupted. Start with clearing the history and manual files (just delete them) and if that doesn’t fix it then you may need a clean install.