MCEBuddy GUI se bloquea - Servicio no conectado

Tipo de solicitud:
BUG

Versión y tipo de MCEBuddy (32 o 64 bits):
MCEBuddy 2.5.5 x64

Sistema operativo y tipo (32 o 64 bits):
Win10x64 20H2 y uso de codificación por hardware con una RTX2060.

Resumen del problema o sugerencia:
La interfaz gráfica de MCEBuddy se bloquea con el título de ventana «Service Not Connected» y todos los elementos dentro de la ventana aparecen deshabilitados. La única opción es cerrar/salir del programa y esperar a que aparezca el diálogo de Windows «no responde» para forzar su cierre. Indica que envía datos de diagnóstico a Microsoft, pero no tengo idea de si pueden obtenerse detalles.

Estoy ejecutando una instancia de WSL Ubuntu u ocasionalmente una instancia de VirtualBox. No sé si esto afecta a MCEBuddy. ¿Contención de núcleos de CPU? p. ej., al iniciarse, MCEBuddy vería todos los núcleos (4) y quizá VBox o WSL reserva núcleos exclusivamente para sí mismo y MCEBuddy no detecta ese cambio.

Pasos para replicar el error:
Lanzar la interfaz gráfica de MCEBuddy.

Eso es Windows diciendo que tu CPU se quedó sin recursos y rompe la conexión entre la interfaz gráfica y el motor. Reduce la carga de trabajo o aumenta la RAM/velocidad del disco.

Todavía me parece que algo va mal. Estoy al 34 % de CPU y el proceso de la GUI de MCE Buddy que aparece como «No responde» consume el 27 % de ese total. Así que mi carga sin la GUI es del 7 %. No tiene sentido, porque antes todo funcionaba bien.

También uso transcodificación por HW (GPU) y ejecuto otras aplicaciones que dependen de la GPU. ¿Existe alguna prueba o contención en MCE Buddy por acceso exclusivo a la GPU que pueda estar causando el conflicto? ¿Gestiona Windows esa política de uso exclusivo para aplicaciones CUDA? CUDA es el SDK de la API de GPU de nVidia, por si no lo sabías.

También ejecuto Plex y Plex usa transcodificación por HW para sus tareas. ¿Hay algo en los registros de MCE Buddy o en los registros de actividad de Windows que pueda buscar para ayudar a encontrar al culpable?

También ejecuto el software SiliconDust HD Homerun DVR en la misma máquina, pero que yo sepa es una aplicación solo de CPU y nunca antes he tenido conflictos en todos los años usando los tres en la misma caja (SD HDHR DVR, Plex y MCEBuddy).

Gracias de antemano, @Goose.

Aquí está la pila de hilos (a través de SysInternals Process Explorer) para el hilo que está consumiendo toda la 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

Fin.

Vi en otra publicación de @Goose:

Si el servicio se ha iniciado, entonces tu firewall o antivirus está bloqueando el puerto (23332) que utiliza el servicio de MCEBuddy (motor) para comunicarse con el cliente (GUI).

Así que estoy revisando el puerto 23332 en el firewall de Windows para ver si ese es el problema.

Iba a sugerir que intentes desactivar la excepción automática del firewall y la opción UPnP en la página de Configuración del Sistema. Parece que Windows se está quedado intentando acceder a la información del firewall y del adaptador de red.

Conexión cruzada de los problemas:

El problema de la CPU se ha solucionado en la versión BETA 2.5.6 de hoy

Parece que eso ha solucionado el inicio de la GUI para mí. No podía acceder a ninguna configuración dentro de la GUI ya que se bloqueaba antes de que terminara de pintarse la ventana principal.

Sin embargo, la versión 2.5.6 del 27-04-2021 se instaló y apareció de inmediato. Incluso con una carga del 30% (otras aplicaciones - y con 4 núcleos, realmente significa que un núcleo está en uso), y con otra aplicación de GPU ejecutándose, la GUI de MCEBuddy se cargó rápidamente y lista para usar.

Así que toma una sabrosa bebida por encontrar el problema y solucionarlo tan rápidamente.
Felicitaciones y mantente bien, @Goose.

Hice más pruebas. ¡Increíble! Un trabajo de GPU en ejecución, un KMTTG descifrando y descargando programas de mi Tivo, descargando actualizaciones de juegos, y el CPU estaba al 95%. La interfaz gráfica aún apareció rápida y como una estrella de rock. Mostró que MCEBuddy estaba ejecutando una conversión en la GPU (además de mi tarea de GPU) sobre el 95% de utilización del CPU. La interfaz gráfica completa aparece y puedo interactuar con ella, así que definitivamente lo que sea que fuera está arreglado.

Así que buen trabajo, @Goose!