Prüfen ob Programm abgestürzt ist

[Luckie]

Zitat von taveuni:

Prüfen ob ein fremdes Programm abgestürzt ist - ist absolut unmöglich.

Und der Link den ich verlinkt habe? Scheint also doch möglich zu sein. Habe es mir aber noch nicht so genau angeguckt, ob da nicht doch ein haken bei ist.

[Furtbichler]

"Abstürzen" ist natürlich so eine Sache.
Eine Anwendung kann den Dienst versagen, aber ganz brav auf sämtliche Messages reagieren. Trotzdem ist sie aus Sicht des Anwenders (andere App oder Benutzer) 'abgeschmiert'.
Ich finde die Aussage von taveuni auch etwas voreilig, zumal die Begründung

Zitat von taveuni:

Diesbezüglich haben wir schon Mannmonate investiert und schlussendlich aufgegeben.

etwas dürftig ist.
Die imho einzige Möglichkeit, einen Absturz zu erkennen, wäre ein periodischer Integrationstest, d.h. die Anwendung prüft selbst, ob die relevanten Komponenten noch funktionstüchtig sind und meldet das Ergebnis an einen Wächter. Bleibt die Meldung aus (oder ist eben negativ), wird entsprechend reagiert.

[p80286]

Es wäre vllt. günstig erst einmal "abgeschmiert","Hängt",... zu definieren?
Aus meiner Erfahrung gibt es für "hängende" Anwendungen meist folgende Gründe:
a) Datenmenge einer Abfrage ist groß. Besonders Access schafft es gut sich tot zu stellen. Ebenso bei Abfragen wie

Code:

select irgendwas from table1,table2

brauchen Server einige Zeit um zu bemerken, daß die Datenmenge zu groß ist.
b) Ein Programm läßt ein Fenster aufpoppen, nur leider nicht "onTop" sondern "onBottom"
c) Eine Endlosschleife weil diese Datenkonstellation ja "nie" auftreten kann.

In allen diesen Fällen arbeitet das Programm "as designed", nur erwartet der Benutzer dies eigentlich nicht.

Gruß
K-H

[EWeiss]

Man muss doch nur herausfinden wie Windows das selbst macht wenn ein Process hängt.
Dafür braucht man keinen Nobelpreis.

Denke das ist der Ansatz den auch Furtbichler verfolgt mit seinem Schnipsel.

gruss

[BUG]

Zitat von EWeiss:

Man muss doch nur herausfinden wie Windows das selbst macht wenn ein Process hängt.
Dafür braucht man keinen Nobelpreis.

Aber es ist wichtig zu wissen, dass all diese Ansätze nur Heuristiken und bei Weitem nicht perfekt sind.
(Es gibt keine praktikable Möglichkeit festzustellen, ob ein Programm in einer (nicht gewollten) Endlosschleife hängt. Man kann aber zum Beispiel feststellen, ob es noch auf Nachrichten reagiert.)

Wenn man jetzt stark in einander integrierte hochverfügbare Anwendungen schreibt, kann man sicher noch andere Fortschritts-/Lebendigkeitseigenschaften überwachen.
Wenn iDope das wollen würde, hätte er vermutlich andere Fragen gestellt.

[Olli73]

Zitat von EWeiss:

Man muss doch nur herausfinden wie Windows das selbst macht wenn ein Process hängt.

Gar nicht bzw. nicht korrekt. Ich weiß nicht wie oft Kunden schon ein Programm abgeschossen haben, nur weil Windows meldet "keine Rückmeldung".

Winodws meldet das aber nur aufgrund der Tatsache, ob das Programm seine Messages abarbeitet. Bei single threaded passiert das eben nicht, obwohl das Programm z.B. nur auf die Antwort eines DB-Servers wartet oder selbst noch am Rechnen ist. Bei multithreaded ist es dann genau umgekehrt.

Code:

loop
  TuWas;
until IrgendEineBedingung;

Wie entscheidest du ("von außen"), ob die Bedingung irgendwann erfüllt sein wird?

[Furtbichler]

Der Umkehrschluss ist natürlich der, das man anfängt, diese Dinge in einen Thread auszulagern, eben damit Windows nicht mehr meckert,übrigens zu Recht: Es kommt von der Anwendung ja wirklich keine Rückmeldung.

Wenn man auf eine Datenbankabfrage wartet, dann muss man die eben auch abbrechen können. Wenn die Komponente das nicht hergibt, muss man eben eine andere nehmen.

[Medium]

Nur hilft das überhaupt nicht, wenn man auf das zu überwachende Programm keinen Einfluss hat. Also im Sinne von selbst daran rumprogrammieren.

Fazit ist doch: Man kann gewisse Anzeichen von aussen als Hinweis interpretieren, dass ein Programm nicht mehr so läuft, wie es gedacht ist. Man kann damit allerdings auch sehr daneben liegen. Ob das so ist, ist von der Art und Weise abhängig, wie das zu überwachende Programm geschrieben ist. Eine allgemeingültige Lösung gibt es schlicht und ergreifend nicht. Und selbst wenn man das zu überwachende Programm selbst in der Hand hat, ist es noch immer recht schwierig. (Was bringt einem ein Life-Beat-Thread der einem Überwacher über z.B. TCP sein Vorhandensein mitteilt, wenn der eigentliche Arbeitsthread in einer Endlosschleife hängt z.B.? Solche Dinge müssten sehr gut durchdacht werden.)

Die Lösung des Problems ist hier daher davon abhängig, wie (und ob) man dem zu überwachenden Programm anerkennen kann, dass es gegen eine Wand gelaufen ist. Und zudem, ob dies aus einem fremden Prozess mit API Mitteln überhaupt ersichtlich werden kann. Ohne sehr genaue Kenntnis des Programms kann man daher imho nur ähnlich naive Methoden nutzen wie es Windows selbst macht, ohne jegliche Garantien auf Korrektheit der Absturzerkennung.