Ich entwickle eine C # -Anwendung (.Net 3.5, Win Forms), die auf einem Server ausgeführt wird und auf die Benutzer mit Remote-Desktop zugreifen. Die Anwendung friert scheinbar zufällig auf dem Remotecomputer ein (dh alle GUI-Komponenten werden weiß, der Task-Manager meldet, dass die Anwendung nicht reagiert), aber nicht bei lokaler Ausführung (ich bin nicht vollständig ) sicher, aber nicht das Einfrieren meiner Maschine reproduzieren).
Hat jemand in seinen Apps, auf die remote zugegriffen wird, ein solches Verhalten erlebt? Welche Debugging-Strategie würden Sie vorschlagen? Muss ich bei der Entwicklung von Win Forms-Anwendungen, auf die über Remote Desktop zugegriffen wird, etwas Besonderes in Betracht ziehen?
BEARBEITEN: einige Hinweise zur Anwendung und zum Einfrieren: Die Anwendung wird nicht vom Einfrieren wiederhergestellt. Außerdem tritt das Einfrieren während der Benutzerinteraktion nicht auf (oder trat noch nicht auf), sondern zwischen den Anmeldungen an den entfernten Rechner. Die Anwendung überwacht einen CFD-Solver, so dass er selbst dann Dinge tut, wenn niemand ihn benutzt.
UPDATE:
Wir haben tatsächlich eine detaillierte Protokollierung implementiert und jeden Funktionsaufruf in eine Datei mit einem Zeitstempel geschrieben. Leider waren die Ergebnisse nicht sehr schlüssig. I.e. Der zuletzt protokollierte Funktionsaufruf wurde immer korrekt zurückgegeben. Außerdem liefen noch einige Hintergrund-Timer, obwohl die Anwendung erst nach kurzer Zeit erschien (GUI komplett weiß usw.). Nach dem Problem konnten wir uns einen Absturz in WinDBG ansehen. Im Systemthread haben wir einen Aufruf von OnUserPreferenceChanged () und weiter bis Invoke.WaitOne () gefunden. Wir können es noch nicht sicher sagen, aber es scheint das Problem zu sein, das in diesen beschrieben wird > Artikel . Als schnelle Lösung habe ich einen Dummy-Handler für das genannte Ereignis installiert. Ich werde berichten, wie das funktioniert.
UPDATE 2:
Wie sich herausstellt, löst eine Anmeldung bei einem Remote-Computer mehrere OnUserPreferenceChanged () - Ereignisse aus. Es war also das vermutete Problem. Die Lösung erwies sich jedoch als nicht so einfach. Ich hätte erwartet, dass eine IllegalCrossReferenceException jedes Mal ausgelöst wird, wenn ein Hintergrundthread versucht, ein Steuerelement zu ändern, das im Systemthread erstellt wurde. Dies scheint nicht der Fall zu sein. Ich habe meinen Systemthread benannt und vor jedem Zugriff auf ein Steuerelement habe ich festgestellt, dass der aktuelle Threadname der Name des Systemthreads ist. An verschiedenen Stellen ist diese Behauptung fehlgeschlagen (z.B. in einem Rückruf von einem Zeitgeber), aber es wurde keine Ausnahme ausgelöst. Nach dem Verwenden der richtigen Delegierung an diesen Orten wurde das Einfrieren gestoppt. Die Anwendung läuft seit einigen Wochen nonstop und meine Benutzer sind wieder glücklich;)
Ich glaube nicht, dass das Einfrieren etwas mit dem Remote-Desktop zu tun hat. Hinzufügen von Protokollierung war ein guter Vorschlag. Ich habe ein paar Vorschläge, aber ohne die Details Ihrer Bewerbung zu kennen, kann ich nicht zu spezifisch werden.
Der einfachste Vorschlag, den ich habe, besteht darin, die Speicherauslastung und die CPU-Auslastung im Task-Manager zu überprüfen, wenn der Freeze auftritt.
Wenn das Hinzufügen einer detaillierten Protokollierung keine Option ist, fügen Sie gerade genug Protokollierung hinzu, um zu wissen, WENN die Anwendung einfriert. Dies könnte einfach ein Thread in der Anwendung sein, der einen Zeitstempel einmal pro Minute in eine Datei schreibt. Dann können Sie sehen, ob sich ein beliebiges Muster befindet, wenn es einfriert, z. B. nachdem sich ein Benutzer abgemeldet hat oder wenn sich einige der Daten, die Sie überwachen, oder zu einem bestimmten Zeitpunkt jeden Tag oder nach einem bestimmten Zeitpunkt im Internet ändern Menge an Zeit.
Eine letzte und sehr hacky Lösung ist, eine kleine Watchdog-Anwendung zu schreiben. Die einzige Aufgabe dieser Anwendung besteht darin, regelmäßig die Hauptanwendung zu überprüfen, um sicherzustellen, dass sie immer noch reagiert. Wie Sie diese verschiedenen drastisch basierend auf was Ihre Anwendung tut. Wenn der Watchdog sieht, dass die Hauptanwendung beendet wurde, kann der Thread für die Hauptanwendung beendet und von den Binärdateien neu gestartet werden.
Wenn Ihre Anwendung, die Ihren Server streamt, die Verbindung verlangsamt oder auf Pakete wartet, die diese fallen lassen, kann dies beim physischen Windows-Remote-Desktop Ihr Problem verursachen, dass intensive Anwendungen nicht über Remote-Desktop laufen sollen / p>
AFAIK, es gibt keinen Unterschied. Außerdem habe ich noch nie ein solches Problem erlebt. Ich schlage vor, Sie versuchen Folgendes:
Wenn das Einfrieren längere Zeit dauert, versuchen Sie Folgendes:
Tags und Links c# remote-desktop .net-3.5