Laden...

GUI "not respondig" ... lässt sich aber wiederbeleben

Erstellt von Christel vor 8 Jahren Letzter Beitrag vor 8 Jahren 2.091 Views
C
Christel Themenstarter:in
448 Beiträge seit 2007
vor 8 Jahren
GUI "not respondig" ... lässt sich aber wiederbeleben

Hallo,
die GUI meiner Anwendung (Windows 7, 32 bit, C#, -NET 4.5.1) klemmt von Zeit zu Zeit und geht in den Zustand "not responding". Dieser Zustand lässt sich beenden, indem man mit der rechten Maustaste auf irgendein Symbol in der Taskleiste klickt und dann die Maus in das sich öffnende Popup bewegt, ohne einen Click auszuführen.

Der Effekt tritt nur auf manchen SingleCore Prozessoren auf, bei MultiCore Prozessoren nie.

Es sieht aus, als würde der Windows Scheduler den Prozess ignorieren und bräuchte nur einen Anstoß ... höchst mysteriös.

Hat einer ne Idee?

Danke
Christel

Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.

25 Beiträge seit 2010
vor 8 Jahren

Das kommt mir irgendwie bekannt vor. Hatte vor langer Zeit mal etwas Ähnliches. Da fror allerdings sogar der Mauszeiger kurzzeitig ein. Da lag es am Grafiktreiber. Vielleicht kannst Du mal eine andere Version des Grafiktreibers ausprobieren. Ggf. eine ältere; neuer ist nicht immer besser...

Gruß
Mango

5.299 Beiträge seit 2008
vor 8 Jahren

könnte mir auch vorstellen, dasses was mit unabgesichertem Threading zu tun hat - da soll allerlei komisches Verhalten entstehen können - bis hin zu Deadlocks.

Der frühe Apfel fängt den Wurm.

C
Christel Themenstarter:in
448 Beiträge seit 2007
vor 8 Jahren

Danke Euch beiden.

Grafiktreiber ist so ne Sache. Der Computer ist ein Kunden PC und darf daher nicht manipuliert werden. Mal sehen, was ich da ausrichten kann.

Unabgesichertes Threading klingt interessant. Aber wie kann man das verhindern? Ich erzeuge keinerlei Threads explizit, alle entstehenden Threads kommen vom Framework und werden dynamisch zur Laufzeit angelegt. Was könnte ich da tun? Gibt es entsprechende Projektoptionen?

Was mich am meisten verwundert, ist die Art und Weise, wie man die Anwendung wieder reanimieren kann. Und das klappt zuverlässig.

Danke
Christel

Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.

5.299 Beiträge seit 2008
vor 8 Jahren

dann scheidet das wohl aus.
also wenn du gar nix mit Threads machst, kannste da auch wohl nix falsch gemacht haben.

Der frühe Apfel fängt den Wurm.

C
Christel Themenstarter:in
448 Beiträge seit 2007
vor 8 Jahren

Nee, ich selbst erzeuge keine Threads, aber im Taskmanager sehe ich, dass in der Anwendung regelmäßig 15-20 Threads laufen. Ich selbst arbeite komplett asynchron über Eventhandler (GUI-Aktionen des Bedieners, Callback-Handler während des Ladens eines XML Dokuments, Timer-Events und Events vom Server). An einer Stelle verwende ich einen Backgroundwoker, aber soweit komme ich leider gar nicht, das Phänomen tritt eher auf.

Danke
Christel

Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.

5.299 Beiträge seit 2008
vor 8 Jahren

Callback-Handler während des Ladens eines XML Dokuments, Timer-Events und Events vom Server). An einer Stelle verwende ich einen Backgroundwoker naja - das sind ja doch Threading-Aktionen.
Wenn du dabei unabgesichert ins Gui grabschst, dann entstehen die genannten instabilen Zustände.
Allerdings kann man normalerweise kaum unabgesichert ins Gui grabschen, es sei denn, man hat die "Sicherung rausgedreht" mit:

Control.CheckForIllegalCrossThreadCalls=False;

Diese Zeile ist gewissermassen der "Random-Suicide", weil man weiß dann nie, ob, wo und wanns knallt, stillesteht oder sonstwas für Überraschungen verbricht.

Mach mal Volltextsuche auf "CheckForIllegalCrossThreadCalls".

Der frühe Apfel fängt den Wurm.

C
Christel Themenstarter:in
448 Beiträge seit 2007
vor 8 Jahren

Ja klar, ich wollte damit nur sagen, dass ich selbst keine Threads über new Thread() erzeuge.

Nee, mit der Property CheckForIllegalCrossThreadCalls mache ich nix, habe den Code durchsucht. Wenn ich die Online-Hilfe richtig verstehe, wird diese Property sowieso nur im DEBUG-Modus aktiv und hilft, CrossThread-Zugriffe besser debuggen zu können.

In meinen Eventhandlern achte ich zudem auf die Verwendung von Invoke, falls notwendig.

Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.

1.378 Beiträge seit 2006
vor 8 Jahren

Hallo Christel,

  • kommt der Freeze immer zur selben Zeit/bei der selben Aktion?
  • kannst du das Verhalten beim Debuggen auch nachvollziehen?
  • wenn die App gerade eingefroren ist, sieht man dann im TaskManager ungewöhnliche CPU-Last und/oder Festplattennutzung?

Lg, XXX

C
Christel Themenstarter:in
448 Beiträge seit 2007
vor 8 Jahren

Nein, der Freeze kommt nicht reproduzierbar, aber immer bei programmtechnisch ähnlichen Aktionen.

Hm, Debuggen ist gerade nicht, da Kunden PC und es wäre eine Heidenarbeit, dort alle Quellen und das VisualStudio draufzuspielen. Wenn es sich gar nicht vermeiden läßt, muss ich RemoteDebugging ins Auge fassen.

Nein, die CPU ist nicht außergewöhnlich belastet, der Taskmanager zeigt keine Außergewöhnlichkeiten.

ABER ...

... ich habe jetzt ein Control in der Applikation ausgemacht, das biestig zu sein scheint. Nachdem ich es temporär ausgeschlossen habe, läuft alles recht stabil. Ich werde an der Stelle weitersuchen und wenn ich die Ursache gefunden haben sollte, meinen Sourcecode nach ähnlichen Schwachstellen durchsuchen.

Ich werde berichten.

Danke soweit
Christel

Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.