Windows Form lässt sich nicht mehr schließen
Hallo, ich habe bei der Programmentwicklung auch mal das Problem, daß die Exe abstürtzt. Nun kommt es vor, das ich dann die Form nicht mehr schließen kann, muss dann Windows 10 neu starten.
Leider habe ich noch keine Lösung dafür gefunden, es ist echt nervig.
Kann da jemand helfen??
Danke und sommerliche Grüße
Wolfgang
Meine Glaskugel ist leider kaputt.
Finde raus, wo er sich auf hängt, der Debugger hilft dabei: [Artikel] Debugger: Wie verwende ich den von Visual Studio?
Mit etwas Code können wir dann auch weiterhelfen.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Hallo, danke für die Antwort. Leider war es nicht sehr hilfreich. Ich arbeite seit VS 2015 mit dem Programm, bin also auch mit dem Debugger vertraut. Breakpoint usw. nutzen mir gar nichts, weil die .EXE im Debug tagelang perfekt lauft und irgendwann aus welchem Grund auch immer, ohne jede Meldung stehen bleibt. Aber wie kann ich sehen, wo das Programm stehengeblieben ist? Ausserdem bleibt beim Beenden des Debuggers die Windows Form offen, sie läßt sich mit keiner Aktion schließen, nur duch Neustart Windows.
Vielleicht gibt es ja doch noch eine zündende Idee.
Gruß
Wolfgang
Das klingt nach Multithreading-Chaos, passt auch dazu, dass es beim Debuggen immer läuft.
Dass die Form nicht geschlossen werden kann, würde ich so erklären, dass der UI-Thread in einem Deadlock fest hängt, dann hilft nur noch Thread oder Prozess killen.
Und wo er stehen bleibt, wirst Du ohne Debugger nur mit entsprechendem Logging feststellen können.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Wenn die Anwendung mit dem VS-Debugger gestartet wurde, dann kannst du im VS diese pausieren (Break All) und über die Thread-Liste und den jeweiligen Stacktrace herausfinden, wo sie genau stehengeblieben ist.
Und als externe Anwendung kannst du per "Attach to Process" die Anwendung nachträglich debuggen (d.h. wie oben pausieren und nachschauen) - du mußt dann evtl. nur den Pfad zu dem Source-Code dazu angeben.
Sobald die Anwendung aber über den Debugger beendet wurde, d.h. der Prozess beendet wurde, dann werden auch alle damit geöffneten Fenster geschlossen - ansonsten schau in den Task-Manager, ob noch der Prozess dazu läuft (oder startest du aus deinem Programm heraus einen anderen Prozess?).
@Th69: Im Debugger bleibt die Anwendung ja nie hängen - zumindest habe ich das so verstanden.
Und als externe Anwendung kannst du per "Attach to Process" die Anwendung nachträglich debuggen
Das ist aber ein guter Punkt.
Du müsstest die Anwendung als Debug-Version bauen und damit den Fehler reproduzieren.
Wenn die Anwendung dann hängt, kannst Du ggf. Visual Studio an den Prozess attachen und so herausfinden, welche Threads/Tasks wo hängen.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Er hat aber geschrieben:
Zitat von WMenzel
...
Breakpoint usw. nutzen mir gar nichts, weil die .EXE im Debug tagelang perfekt lauft und irgendwann aus welchem Grund auch immer, ohne jede Meldung stehen bleibt. Aber wie kann ich sehen, wo das Programm stehengeblieben ist? Ausserdem bleibt beim Beenden des Debuggers die Windows Form offen, sie läßt sich mit keiner Aktion schließen, nur duch Neustart Windows.
...
Warum wurde kein Tracing / Monitoring in der Applikation umgesetzt, wie man es seit ca. 30 Jahren in allen möglichen Empfehlungen, Code Architecture Guides und auch in den .NET Basics nachlesen kann?
Dann würde man nun nicht um Dunkeln stochern.
Ergo: Zeit das nun nachzuholen. 😉
PS: in den aller meisten .NET SDKs und Bibliotheken ist sowas eingebaut - man muss es nur nutzen.
Ausserdem bleibt beim Beenden des Debuggers die Windows Form offen, sie läßt sich mit keiner Aktion schließen, nur duch Neustart Windows.
Ein potentieller Hinweis auf einen klassischen Programmierfehler, dass unmanaged resource nicht richtig behandelt werden.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hallo, danke für die Hinweise, leider komme ich überhaupt nicht weiter.
ich starte die Anwendung im Debugger. Die Anwendung läuft tagelang ohne Probleme, bleibt dann aber plötzlich stehen. Nur der Windows-Kreisel dreht sich noch. Wenn ich den Debugger stoppe, dann kommt die Meldung, dass es zu lange dauert, stoppt dann aber. Allerdings bleibt dir Form offen, kann nur durch Windows-Neustart beendet werden.
Vielleicht gibt es ja noch eine Lösund!!???
Danke und Gruß
Du sollst den Debugger (d.h. den Prozess) nicht stoppen, sondern unterbrechen (Break all) und dir dann über das Thread-Fenster den jeweiligen Stacktrace anschauen.
Wie Abt schon schrieb, vermute ich auch einen falschen Umgang mit unmanaged ressources (Bitmaps, Fonts, Pen - allgemein alles, was mit GDI zu tun hat führt gern zum beschriebenen Problem). Das führt dann dazu, dass die Anwendung irgendwann z.B. keine GDI-Handles mehr zur Verfügung hat.
Lade Dir mal den Process-Explorer aus den PSTools herunter und beobachte, ob bestimmte Speicher, Handles etc. sich permanent erhöhen.
Generell solltest Du auch mal überlegen, ob eine WinForms Anwendung das richtige Mittel ist, wenn das tagelang laufen soll. Eventuell kommst Du ja mit einem Dienst besser zurecht. Um ein zuverlässiges laufen zu garantieren sollte auch immer eine 'Überwachungsinstanz' prüfen, ob die Anwendung/der Dienst noch läuft und ggf. dafür sorgen, dass das wieder der Fall ist (man spricht hier oft von 'Watchdogs').