Nach Timer.Enable killt sich das Programm

[jaenicke]

Du kannst dir in FastMM auch live anzeigen was so im Speicher passiert. Dazu findest du im FastMM4 Ordner auch eine Demo, deren Formular du einfach einbinden kannst. Die liegt unter: FastMM\Demos\Usage Tracker

Das hilft in solchen Fällen oft mehr als nur die Leckanzeige beim Beenden des Prozesses.

[Rupert]

Heute um 5:56 passierte zum Zeitpunkt TimerEx1.Enable:=true folgendes:

Zitat:

Ereignistyp: Fehler
Ereignisquelle: Application Error
Ereigniskategorie: Keine
Ereigniskennung: 1000
Datum: 07.09.2021
Zeit: 05:55:31
Benutzer: Nicht zutreffend
Computer: HEIZ-PC
Beschreibung:
Fehlgeschlagene Anwendung heizung2020.exe, Version 11.0.1.1, fehlgeschlagenes Modul kernel32.dll, Version 5.1.2600.5512, Fehleradresse 0x00012aeb.

Daten:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 68 65 69 ure hei
0018: 7a 75 6e 67 32 30 32 30 zung2020
0020: 2e 65 78 65 20 31 31 2e .exe 11.
0028: 30 2e 31 2e 31 20 69 6e 0.1.1 in
0030: 20 6b 65 72 6e 65 6c 33 kernel3
0038: 32 2e 64 6c 6c 20 35 2e 2.dll 5.
0040: 31 2e 32 36 30 30 2e 35 1.2600.5
0048: 35 31 32 20 61 74 20 6f 512 at o
0050: 66 66 73 65 74 20 30 30 ffset 00
0058: 30 31 32 61 65 62 0d 0a 012aeb..

und

Zitat:

Ereignistyp: Warnung
Ereignisquelle: W32Time
Ereigniskategorie: Keine
Ereigniskennung: 36
Datum: 07.09.2021
Zeit: 05:36:06
Benutzer: Nicht zutreffend
Computer: HEIZ-PC
Beschreibung:
Der Zeitdienst konnte die Systemzeit seit 49152 Sekunden nicht synchronisieren,
da kein Zeitanbieter einen gültigen Zeitstempel anbieten konnte. Die Systemuhr ist nicht synchronisiert.

Der Sync beeindruckt mich nicht wirklich, aber der Fehler im kernel32.dll.
Es ist aber absolut sicher, dass durch das Starten des Timers der Fehler ausgelöst wird (siehe Bild).
Die Fragen sind:
- Gibt es eine andere Möglichkeit - ohne Timer - dei Hauptschleife zyklisch durchlaufen zu lassen
- Wie findet man einen kernel32-Fehler, der praktisch alles sein kann

Das habe ich in einem US-Forum gefunden und werde es probieren:

Zitat:

the problem is something that *particular* program is doing, not something all Delphi programs do.
There's simply no way to even make a wild guess at the problem without debugging it.

My best guesses are either DLL hell or permissions/privileges.

https://www.delphipraxis.net/attachm...1&d=1630997000

[Klaus01]

.. hast Du madExcept zur Verfügung?
Mit den madExcept Daten ist oftmals einfacher den Grund einer Exception zu ergründen.

Grüße
Klaus

[venice2]

Zitat:

Ich habe schon andere Timerkomponenten ausprobiert

Dann mach es doch ganz ohne..

SetTimer, KillTimer

Zitat:

Gibt es eine andere Möglichkeit - ohne Timer - dei Hauptschleife zyklisch durchlaufen zu lassen

repeat.. until in Kombination mit

Thread, CreateWaitableTimer, WaitForSingleObject, PostThreadMessage usw..

[Blup]

Wenn ich tief in meine Glaskugel schau, hab ich diese Hypothese:
Direkte Fehlerursache ist ein Überlauf des Aufrufstapels.
Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen.
So dass Hauptschleife() sich indirekt selbst rekursiv aufruft, immer wieder, bis der Stapel überläuft.
Ein Tool wie madExcept könnte da Klarheit schaffen.

Alternative zum Ab- und Anschalten des Timers hab ich weiter oben gepostet.
Du müsstest halt mal probieren ob das hilft.

[Rupert]

Zitat von Klaus01:

.. hast Du madExcept zur Verfügung?
Mit den madExcept Daten ist oftmals einfacher den Grund einer Exception zu ergründen.

Grüße
Klaus

Habe MadCollection implementiert - danke für den Tipp
Die Schleife dauert halt nun 30 sec., aber wenn's hilft

[Uwe Raabe]

Zitat von Blup:

Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen..

Das kann nicht sein. Das Disablen des Timers ruft intern ein KillTimer auf, was dafür sorgt, dass keine Messages dieses Timers mehr in der Message-Queue landen (da WM_TIMER eine Low-Priority Message ist, sollten auch keine mehr drin sein). Mit dem nachfolgenden Enable wird im Wesentlichen dann ein SetTimer aufgerufen, was den Start des Timer-Intervalls darstellt. Daher kann erst frühestens nach Ablauf dieses Intervalls nach dem Enablen des Timers der Event ausgelöst werden. (Side-Note: Die Zykluszeit ist also mindestens so lang wie das Timer-Intervall plus die Dauer der Routine zwischen Ab- und Anschalten des Timers!)

Ich vermute, der Fehler ist unabhängig von dem Timer.

[Rupert]

Zitat von Uwe Raabe:

Ich vermute, der Fehler ist unabhängig von dem Timer.

Nach Enable wird aber das Ereignis OnTimer nicht mehr ausgeführt - sollte ich in meiner Ereignistabelle sehen.

Zitat:

--- TimerEx1.Enabled:=True ist der letzte Eintrag

Delphi-Quellcode:

procedure THauptformular.Hauptschleife(Owner: TObject);
var zaehler: shortint;
Begin
 begin
  inc (Hauptschleifencounter,1);
  Ereignis_notieren('HS 1. Start Hauptschleife - '+inttostr(Hauptschleifencounter));
  SchleifenBar.position:=11-Hauptschleifencounter;
  ....
  Display_aktualisieren(nil);
  CounterStart(nil);
  end; //if Hauptschleifencounter > 10
end;

// **** **** **** **** **** **** **** **** **** ****

procedure THauptformular.CounterStart(Owner: TObject);
Begin
  Ereignis_notieren('--- TimerEx1.Enabled:=True');
  TimerEx1.Enabled:=True;
end;

[Rupert]

Zitat von Blup:

Wenn ich tief in meine Glaskugel schau, hab ich diese Hypothese:
Direkte Fehlerursache ist ein Überlauf des Aufrufstapels.
Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen.
So dass Hauptschleife() sich indirekt selbst rekursiv aufruft, immer wieder, bis der Stapel überläuft.
Ein Tool wie madExcept könnte da Klarheit schaffen.

Alternative zum Ab- und Anschalten des Timers hab ich weiter oben gepostet.
Du müsstest halt mal probieren ob das hilft.

Das passiert nicht, denn das würde ich anhand der Aufzeichnungen in meiner Ereignisdatenbank sehen!
madExcept ist seit heute implementiert
https://www.delphipraxis.net/attachm...1&d=1631034734

[Rupert]

Keine Mitteilung von madExcept. Nichts...

Auffällig ist, dass die letzte Eintragung immer der Timerist und der Crash stets um 5:56 bzw. 5:58 passiert.

https://www.delphipraxis.net/attachm...1&d=1631078722

https://www.delphipraxis.net/attachm...1&d=1631078722

https://www.delphipraxis.net/attachm...1&d=1631078722