MCEBuddy GUI friert ein – Dienst nicht verbunden

Anfragetyp:
FEHLER

MCEBuddy-Version und -Typ (32-Bit oder 64-Bit):
MCEBuddy 2.5.5 x64

Betriebssystem und -Typ (32-Bit oder 64-Bit):
Win10x64 20H2 und HW-Encoding mit einer RTX2060.

Zusammenfassung des Problems oder Vorschlags:
Die MCEBuddy-GUI friert ein; das Fenster trägt den Titel „Service Not Connected“ und alle Elemente im Fenster sind ausgegraut. Die einzige Option ist, das Programm zu schließen/beenden und zu warten, bis der Windows-Dialog „reagiert nicht“ erscheint, um das Programm zu beenden. Es heißt, es würden Diagnosedaten an Microsoft gesendet, aber ich habe keine Ahnung, ob Sie Microsoft um Details bitten können.

Ich betreibe eine Instanz von WSL Ubuntu oder gelegentlich eine VirtualBox-Instanz. Ich weiß nicht, ob das Auswirkungen auf MCEBuddy hat. Konkurrenz um CPU-Kerne? z. B. beim Start würde MCEBuddy alle Kerne (4) sehen, und vielleicht reserviert VBox oder WSL Kerne exklusiv für sich selbst und MCEBuddy merkt nicht, dass sich das geändert hat?

Schritte zur Reproduktion des Fehlers:
MCEBuddy-GUI starten.

Das sagt Windows, dass deine CPU keine Ressourcen mehr hat und es die Verbindung zwischen der GUI und der Engine unterbricht. Reduziere die Arbeitslast oder erhöhe den RAM/die Festplattengeschwindigkeit

Ich denke immer noch, dass irgendetwas merkwürdig ist. Ich habe eine CPU-Auslastung von 34 %, und der „Nicht antwortende“ MCE-Buddy-GUI-Prozess beansprucht davon 27 %. Meine Last ohne die GUI liegt also bei 7 %. Das ergibt keinen Sinn, da bisher alles in Ordnung war.

Ich nutze ebenfalls HW-(GPU-)Transkodierung und betreibe weitere GPU-intensive Anwendungen. Gibt es in MCE Buddy einen Test oder eine Konkurrenzsituation um exklusiven GPU-Zugriff, die zu diesem Konflikt führt? Verwaltet Windows diese exklusive Nutzungsrichtlinie für CUDA-Anwendungen? CUDA ist nVidias GPU-API-SDK, FYI.

Ich betreibe auch Plex, und Plex nutzt HW-Transkodierung für seine Aufgaben. Gibt es in den MCE-Buddy-Logs oder den Windows-Aktivitätslogs etwas, wonach ich suchen kann, um den Übeltäter zu finden?

Auf derselben Maschine läuft außerdem die SiliconDust HDHomeRun-DVR-Software, aber soweit ich weiß, ist das eine reine CPU-Anwendung, und ich hatte noch nie einen Konflikt, obwohl ich alle drei Programme jahrelang auf derselben Box betreibe (SD-HDHR-DVR, Plex und MCEBuddy).

Danke im Voraus, @Goose.

Hier ist der Thread-Stack (über SysInternals Process Explorer) für den Thread, der die gesamte CPU beansprucht:

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

Ende.

Sah in einem anderen Beitrag von @Goose:

Wenn der Dienst gestartet wurde, blockiert Ihre Firewall oder Ihr Antivirusprogramm den Port (23332), den der MCEBuddy-Dienst (Engine) zur Kommunikation mit dem Client (GUI) verwendet.

Ich untersuche also Port 23332 in der Windows-Firewall, um zu sehen, ob das ein Problem ist.

Ich wollte vorschlagen, die automatische Firewall-Ausnahme und die UPnP-Option auf der Systemeinstellungen-Seite zu deaktivieren. Es sieht so aus, als würde Windows hängen bleiben, wenn es versucht, auf die Firewall- und Netzwerkadapter-Informationen zuzugreifen.

Verbindung der Themen:

Das CPU-Problem wurde im heutigen 2.5.6-BETA-Release behoben

Das scheint das GUI-Startproblem bei mir behoben zu haben. Ich konnte keine Einstellungen im GUI vornehmen, da es sich aufhing, bevor das Hauptfenster vollständig angezeigt wurde.

Die Version 2.5.6 vom 27.04.2021 installierte sich jedoch und funktionierte sofort. Selbst bei 30% Auslastung (andere Anwendungen – und bei 4 Kernen bedeutet das wirklich, dass ein Kern genutzt wird) und mit einer weiteren GPU-Anwendung im Hintergrund lud das MCEBuddy-GUI schnell und war einsatzbereit.

Also gönn dir ein kühles Getränk für das so schnelle Finden und Beheben des Problems.
Meinen Respekt und bleib gesund, @Goose.

Habe noch etwas getestet. Wow! Ein GPU-Job läuft, ein KMTTG entschlüsselt und lädt Sendungen von meinem Tivo herunter, Spiele-Updates werden heruntergeladen, und die CPU war bei 95 % ausgelastet. Die GUI war trotzdem flott und wie ein Rockstar. MCEBuddy zeigte, dass eine Konvertierung auf der GPU läuft (zusätzlich zu meinem GPU-Task) bei gleichzeitig 95 % CPU-Auslastung. Die gesamte GUI erscheint und ich kann mit ihr interagieren, also ist definitiv alles behoben.

Also gute Arbeit, @Goose!