onClose-Funktion auch bei Absturz ausgeführt?

[BAMatze]

Hallo an euch,

Hab da mal eine Frage zur onClose-Funktion. Möchte wärend meines Programmes eine Temporäre Datei laufen lassen, die überwacht, was der Bediener macht, wärend das Programm läuft. An alle die denken ich möchte die Daten aus dem Computer auslesen, Keylogger oder ähnliches, ich kann euch beruhigen, es geht rein um die Aktionen die der Bediener in meinem Programm ausführt. Ich möchte mit dieser Temporären Datei nachvollziehen, wenn das Programm abstürzt, woran das eventuell gelegen hat. Also soll bei problemlosem Ablauf die Tmp-Datei wieder gelöscht werden, damit der Rechner nicht vollgemüllt wird.
Hier jetzt meine Frage: Wenn eine Exception im Programm auftritt, wird die onClose-Funktion in meiner Hauptform trotzdem ausgeführt? Würde nämlich die Löschroutine gern dort reinschreiben, weil ich sonst mindestens 2 Beendungsroutinen überwachen müsste (Datei>Beenden und den X-Button der Form).

Wenn die OnClose-Funktion ausgeführt wird, wie kann ich überwachen, ob der X-Button meiner Hauptform gedrückt wurde?

Danke schon mal im Vorraus

BAMatze

[Bernhard Geyer]

Kommt auf den Absturz an. Bei einem Stack Overflow kickt Windows den Prozess aus dem Speicher ohne das noch irgendwelche Events ablaufen.

[BAMatze]

Ess sollen alle Möglichen Abstürze Überwacht werden. Aber aus deiner Aussage schließe ich, dass ich wohl um das Überwachen der Aktionen am X-Button nicht drum herum komme.

[nahpets]

Hallo,

bei einem Programmabsturz kannst Du grundsätzlich nicht davon ausgehen, irgendeine Information über den Absturz zu erhalten. Mit ein bisserl Glück erfährst Du eventuell noch etwas, aber darauf verlassen kannst Du Dich nicht.

Vor einiger Zeit hatte ich ein Programm, das ab und an vollkommen unnachvollziehbar herumzickte.
Bin dann, nachdem ich nicht mehr weiterwußte, hergegangen und habe am Anfang und am Ende jeder Funktion/Prozedure den Aufruf einer eigenen Loggingroutine eingebaut. Die bekommt als Parameter einen String mitgegeben und schreibt diesen zusammen mit 'nem Zeitstempel in eine Datei.
Am Anfang der Funktionen/Prozeduren wird einfach nur "Beginn Funktion-/Prozedurname" und am Ende "Ende Funktion-/Prozedurname" geschrieben.
In die eigenen Try-Except-Blöcke habe ich den Aufruf ebenfalls hineingeschrieben und dort wird neben dem Zeitstempel auch noch die von der Exception ausgegebene Fehlermeldung in die Datei geschrieben.

Hier ist dann Phantasie gefragt, es lassen sich die Inhalte der Aufrufparameter zu den Funktionen/Prozeduren protokollieren, irgendwelche Zustände von Komponenten, Inhalte von Eingabefeldern..., alles das, was bei der Fehlersuche hilfreich sein könnte.

Damit das Ganze nicht zuviel Logdatei ergibt, habe ich über eine Ini-Datei einen Schalter gesetzt, mit dem ich das Logging ein- und ausgeschalten kann. Man könnte auch noch einen Logginglevel einbauen, mit dem über einen Eintrag in der Ini-Datei gesteuert werden kann, wieviel protokolliert wird, indem man der Loggingroutine noch diesen Parameter übergibt und damit steuert, ob eine Ausgabe erfolgt oder nicht. So könnte man für Beginn und Ende einen anderen Level nehmen, als für Ausnahmen.

Lange Rede kurzer Sinn: Durch diese Verfahrensweise habe ich herausbekommen, dass das Programm immer dann anfing zu zicken, wenn auf einem Datenbankserver an einem anderen Standort Abends um 21.30 ein bestimmter Job startete und dadurch die Datenbankverbindung zu diesem Server "irgendwie" beeinträchtigt wurde. Hiermit kam eine Routine nicht zurecht und hat dann irgendwann für ein riesiges Speicherloch gesorgt, bis zum Spürbarwerden des Problemes konnten jedoch Stunden oder Tage vergehen.

Hoffe, Dir damit ein bisserl Anregung, zur hoffentlich erfolgreichen Fehlersuche, geben zu können.

[Luckie]

Man könnte es nochmadexcept probieren, etwas mehr Informationen zu bekommen.

[BAMatze]

Zitat von nahpets:

Hallo,

bei einem Programmabsturz kannst Du grundsätzlich nicht davon ausgehen, irgendeine Information über den Absturz zu erhalten. Mit ein bisserl Glück erfährst Du eventuell noch etwas, aber darauf verlassen kannst Du Dich nicht.

Vor einiger Zeit hatte ich ein Programm, das ab und an vollkommen unnachvollziehbar herumzickte.
Bin dann, nachdem ich nicht mehr weiterwußte, hergegangen und habe am Anfang und am Ende jeder Funktion/Prozedure den Aufruf einer eigenen Loggingroutine eingebaut. Die bekommt als Parameter einen String mitgegeben und schreibt diesen zusammen mit 'nem Zeitstempel in eine Datei.
Am Anfang der Funktionen/Prozeduren wird einfach nur "Beginn Funktion-/Prozedurname" und am Ende "Ende Funktion-/Prozedurname" geschrieben.
In die eigenen Try-Except-Blöcke habe ich den Aufruf ebenfalls hineingeschrieben und dort wird neben dem Zeitstempel auch noch die von der Exception ausgegebene Fehlermeldung in die Datei geschrieben.

Hier ist dann Phantasie gefragt, es lassen sich die Inhalte der Aufrufparameter zu den Funktionen/Prozeduren protokollieren, irgendwelche Zustände von Komponenten, Inhalte von Eingabefeldern..., alles das, was bei der Fehlersuche hilfreich sein könnte.

Damit das Ganze nicht zuviel Logdatei ergibt, habe ich über eine Ini-Datei einen Schalter gesetzt, mit dem ich das Logging ein- und ausgeschalten kann. Man könnte auch noch einen Logginglevel einbauen, mit dem über einen Eintrag in der Ini-Datei gesteuert werden kann, wieviel protokolliert wird, indem man der Loggingroutine noch diesen Parameter übergibt und damit steuert, ob eine Ausgabe erfolgt oder nicht. So könnte man für Beginn und Ende einen anderen Level nehmen, als für Ausnahmen.

Lange Rede kurzer Sinn: Durch diese Verfahrensweise habe ich herausbekommen, dass das Programm immer dann anfing zu zicken, wenn auf einem Datenbankserver an einem anderen Standort Abends um 21.30 ein bestimmter Job startete und dadurch die Datenbankverbindung zu diesem Server "irgendwie" beeinträchtigt wurde. Hiermit kam eine Routine nicht zurecht und hat dann irgendwann für ein riesiges Speicherloch gesorgt, bis zum Spürbarwerden des Problemes konnten jedoch Stunden oder Tage vergehen.

Hoffe, Dir damit ein bisserl Anregung, zur hoffentlich erfolgreichen Fehlersuche, geben zu können.

Hallo nahpets,

genau so hatte ich mir das gedacht, wobei ich bisher immer nur die Aktionen des Bedieners überwachen wollte. Dabei ist deine Idee einfach den Beginn und das Ende einer jeden Funktion natürlich wesentlich besser. Es geht mir nämlich auch einfach nur darum, Fehlersuche im Betrieb des Programmes einfacher und schneller zu finden. Bei einem anderen Projekt hier habe ich nämlich gesehen, dass dies sehr sinnvoll ist, da dort das Programm immer unterschiedlich abstürzt. Leider wurde aus kostengründen der Entwickler vor der inbetriebnahme entlassen und somit ist kein effektives Troubleshouting möglich gewesen. Also danke für die anregung, werde mir deinem Beispiel zu folge auch die Anfänge und Enden der Proceduren protokollieren lassen.
Jetzt ist aber nur noch eine Frage offen, wenn das Programm keinen Fehler hat, soll diese Tmp-Datei wieder gelöscht werden, da sie keine relevanten Daten für mich enthält, kann man dies in der Onclose machen oder wird diese Funktion doch ab und zu trotz exception ausgeführt, dann wäre es nämlich schlecht, wenn trotz Exceptions auch die Tmp-Datei gelöscht wird.

[Medium]

Ich würde da lieber pro Programmstart ein separates Log anlegen (z.B. mit Datum/Uhrzeit des Starts als Namen), und das Löschen manuell erledigen lassen. Wenn das Programm lange am Stück läuft, wäre auch noch denkbar das Log nach N Zeilen zu splitten um Riesen-txts vorzubeugen. Damit sollte es einigermaßen handhabar bleiben, und SO mörder-groß werden diese meist ja auch nicht, dass davon die landläufige Festplatte platzt.
Du solltest übrigens darauf achten, dass nach jedem kleinsten Logeintrag die Datei geflusht bzw. geschlossen wird, um die Wahrscheinlichkeit zu minimieren dass durch Caching Einträge flöten gehen wenn die Kiste mal z.B. spontan unsanft neugestartet wird. Daher sollte man evtl. auch nicht grad in längeren Schleifen jeden Durchlauf mitloggen o.ä., weil DANN wirds je nach dem schon wieder recht performancelastig. Das kann man dann bei begründetem Verdacht machen.

[nahpets]

Hallo,

lösche die Datei nicht beim Programmende, sondern beim Programmstart die noch vorhandene.
Damit kommst Du an einem versehentlichen Löschen zum Programmende vorbei.

Beim Programmstart halt so:

Delphi-Quellcode:

AssignFile(f,'log.txt');
ReWrite(f);
Writeln(f,DateTimeToStr(Now),'jetzt gehts los');
CloseFile(f);

Jeden einzelnen Logeintrag dann mit:

Delphi-Quellcode:

AssignFile(f,'log.txt');
Append(f);
Writeln(f,DateTimeToStr(Now),sProtokollparameter);
CloseFile(f);

Aus leidvoller Erfahrung: Datei immer schließen, damit Du auch den letzten Eintrag noch hast, es sei denn, dass das Schreiben dieses Eintrages scheitert.

Der Einwand von Medium, die Log's nicht zu löschen, ist nicht von der Hand zu weisen. Du kannst anhand mehrere Logdateien eventuell Systematiken erkennen, die Dir in einer Logdatei nie auffallen würden. Und auch der Hinweis auf das Logging in Schleifen ist zu beachten. Bei zuviel des Guten, merkt man's doch an der Laufzeit.
Zuerst, denk' ich, reicht es, Beginn und Ende der Funktionen und Prozeduren, sowie eigene Exceptions zu loggen. Wenn Du dann schonmal "Grundmaterial" hast, kannst Du das Logging an den neuralgischen Punkten "verschärfen".

[BAMatze]

Also die Idee die LogDatei am Anfang wieder zu löschen, muss ich leider verwerfen, da ich nicht selber das Programm bediene und nicht weiß, wie qualifiziert das Personal sein wird, die es nutzt, muss ich ausschließen, dass die Datei verloren geht, weil der Arbeiter denkt "Oh was war denn das? Lieber schnell neustraten und weiter machen". Das Argument es von Hand zu löschen hat was, wobei ich ja aber eigentlich verhindern wollte, dass zu viele eventuell sehr große Logdateien entstehen.
Das Argument mit dem Dateiensplitten würde mich aber interessieren. Hab es selber noch nicht gemacht und das scheint mir ein praktikables Mittel zu sein, die Dateien doch auf dem Rechner erstmal zu belassen und dannaber die Dateigröße zu minimieren.

[nahpets]

Hallo,

merk' Dir doch einfach, wann eine Logdatei erstellt wurde und wenn sie älter als 4 Wochen (oder so) ist, dann wird sie gelöscht. (Geht ja über das Dateidatum).
Um große Dateien zu verhindern, schreib' Dir für das Logging eine Klasse. Die erstellt Dir dann die Datei und setzt sich 'nen Zeitstempel in 'nem Attribut. Immer wenn ein Logeintrag geschrieben wird, schaut sie, von wann die Datei ist und wenn die Datei älter als 1 Stunde (oder so) ist, wird 'ne neue Datei erstellt und der interne Merker aktualisiert.
Das könnstest Du auch mit der Zahl der Logeinträge steuern, alle 1000 (oder so) Einträge neue Datei anfangen.
Beim Programmende könntest Du dann auch noch eine "werfallesweg"-Routine aufrufen, die die Logdateien des fehlerfreien Programmlaufes wegwirft. Die Dateinamen hast Du Dir in der Klasse in 'ner Stringliste gemerkt.
Du könntest das auch noch soweit ausbauen, dass Du nur die Logdateien überlässt, in denen Fehler protokolliert wurden. Da ist jetzt Deine Phantasie gefordert, wie Du der Loggingfunktion mitteilts, ob's nur zum "wosindwir"-Loggen gehört oder zum Loggen von abgefangenen Exceptions...
Denke, dass Du Dir hier mit recht wenig Aufwand ein brauchbares Werkzeug schaffen kannst.