MCEBuddy GUI locks up - Service Not Connected

Request Type:
BUG

MCEBuddy Version and Type (32bit or 64bit):
MCEBuddy 2.5.5 x64

Operating System and Type (32bit or 64bit):
Win10x64 20H2 and using HW encoding with an RTX2060.

Summary of the problem or suggestion:
MCEBuddy GUI locks up with the window title of “Service Not Connected” and all elements in the window greyed out. Only option is to close/exit the program and wait for the Windows “not responding” dialog to pop up and force ending the program. It says it sends diagnostic data to Microsoft, but I have no idea if you can engage Microsoft for any details.

I am running an instance of WSL Ubuntu or an occasional VirtualBox instance. I don’t know if that has any affect on MCEBuddy. Contention for CPU cores? e.g. on startup, MCEBuddy would see all cores (4), and perhaps VBox or WSL reserves cores exclusively for itself and MCEBuddy doesn’t know that changed?

Steps to replicate the bug:
Launch MCEBuddy GUI.

That’s Windows saying your CPU is out of resources and it breaks the connection between the GUI and the engine. Reduce the work load or increase the RAM/disk speed

I still think something is wonky. I’m running at 34% CPU and the “Not Responding” MCE Buddy GUI process is taking up 27% of that. So my load without the GUI is 7%. That doesn’t make sense since things have been fine before.

I also do use HW (GPU) transcoding and I do run other applications that are GPU-bound. Is there a test or contention in MCE Buddy for exclusive access to the GPU and that is the conflict? Does Windows manage that exclusive use policy for CUDA applications? CUDA is nVidia’s GPU API SDK, FYI.

I also run Plex and Plex is using HW transcoding for doing its thing as well. Is there anything in the MCE Buddy logs or the Windows activity logs I can look for to help find the culprit?

I also run the SiliconDust HD Homerun DVR software on the same box, but AFAIK, it is a CPU-only application and I’ve never had a conflict before in all the years of using all three on the same box (SD HDHR DVR, Plex, and MCEBuddy).

TIA, @Goose.

Here’s the thread stack (via SysInternals Process Explorer) for the thread that is sucking up all the CPU:

ntdll.dll!NtQueryKey+0x14
KERNELBASE.dll!MapPredefinedHandleInternal+0xe54
KERNELBASE.dll!MapPredefinedHandleInternal+0xa80
KERNELBASE.dll!RegOpenKeyExInternalW+0x141
KERNELBASE.dll!RegOpenKeyExW+0x19
DNSAPI.dll!Reg_GetValueEx+0xed3
DNSAPI.dll!DnsApiFree+0xfba
DNSAPI.dll!NetInfo_Build+0x117
DNSAPI.dll!DnsUpdateMachinePresence+0x7ff
DNSAPI.dll!DnsDhcpRegisterInit+0x1f9b2
DNSAPI.dll!DnsDhcpRegisterInit+0x1fad3
DNSAPI.dll!DnsDhcpRegisterInit+0x1a68a
IPHLPAPI.DLL!GetOwnerModuleFromPidAndInfo+0x9cd
IPHLPAPI.DLL!GetPerAdapterInfo+0x30
[Native Frame: IL Method without Metadata]
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\
    System.dll!System.Net.NetworkInformation.SystemIPv4InterfaceProperties.GetPerAdapterInfo+0x93
    System.dll!System.Net.NetworkInformation.SystemIPInterfaceProperties..ctor+0x220
    System.dll!System.Net.NetworkInformation.SystemNetworkInterface..ctor+0xcd
    System.dll!System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces+0x19e
    System.dll!System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces+0x4b
C:\Program Files\MCEBuddy2x\MCEBuddy.Util.dll!MCEBuddy.Util.Net.isLocalMachine+0x9e
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.StatusForm.DisableControls+0x62d
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.StatusForm.backgroundUpdate_ProgressChanged+0x24d
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089
    System.dll!System.ComponentModel.BackgroundWorker.OnProgressChanged+0x9b
[Unmanaged to Managed Transition]
clr.dll!CoUninitializeEE+0x1b73
clr.dll!CoUninitializeEE+0x1a88
clr.dll!MetaDataGetDispenser+0x33602
clr.dll!MetaDataGetDispenser+0x33a75
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x84
C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll!System.Delegate.DynamicInvokeImpl+0xa0
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackDo+0x9d
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackHelper+0x69
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_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallback+0xbc
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbacks+0xe6
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc+0x509
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback+0xc2
[Unmanaged to Managed Transition]
[Native Frame: IL Method without Metadata]
clr.dll+0x221e
USER32.dll!CallWindowProcW+0x3f8
USER32.dll!DispatchMessageW+0x259
[Native Frame: IL Method without Metadata]
[Managed to Unmanaged Transition]
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop+0x341
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ThreadContext.RunMessageLoopInner+0x1c7
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll!ThreadContext.RunMessageLoop+0x52
C:\Program Files\MCEBuddy2x\MCEBuddy.GUI.exe!MCEBuddy.GUI.Program.Main+0x3a
[Unmanaged to Managed Transition]
clr.dll!CoUninitializeEE+0x1b73
clr.dll!CoUninitializeEE+0x1a88
clr.dll!CoUninitializeEE+0x2338
clr.dll!SetRuntimeInfo+0x8c2
clr.dll!SetRuntimeInfo+0x1287
clr.dll!SetRuntimeInfo+0x113b
clr.dll!SetRuntimeInfo+0xa87
clr.dll!SetRuntimeInfo+0xa05
clr.dll!CorExeMain+0x14
mscoreei.dll!CorExeMain+0x71
MSCOREE.DLL!CorExeMain+0x72
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

End.

Saw in another post from @Goose :

If the service has started then your firewall or antivirus is blocking the port (23332) used by the MCEBuddy service (engine) to communicate with the client (GUI).

So I’m looking into port 23332 in the windows firewall to see if that’s a problem.

I was going to suggest try disabling the automatic firewall exception and UPnP option in the System Settings page. It looks like windows is hung up trying to access the firewall and network adapter info

Cross connecting the issues:

The CPU issue has been fixed in today 2.5.6 BETA release

2 Likes

That seems to have fixed the GUI startup for me. I wasn’t able to get to any settings within the GUI since it was locking up before the main window finished painting.

However, the 2.5.6 2021-04-27 version installed and popped up out of the box. Even with 30% load (other apps - and with 4 cores, it really means one core is in use), and with another GPU app running, the MCEBuddy GUI loaded fast and ready to go.

So have a tasty beverage for finding the problem and fixing it so quickly.
Kudos and stay well, @Goose.

Did some more testing. Wow! A GPU job running, a KMTTG decrypting and downloading shows from my Tivo, downloading game updates, and CPU was maxed at 95%. GUI still came up snappy and like a rock star. Showed MCEBuddy was running a conversion on the GPU (in addition to my GPU task) on top of the 95% CPU utilization. The full GUI comes up and I can interact with it, so definitely whatever it was is fixed.

So job well done, @Goose!

1 Like