TTimer zu schnell?

[TurboMagic]

Hallo,

in einem D12.1 basierten VCL Programm gibt's das komische von einem Anwender gemeldete
Phänomen, dass eine Fehlermeldung erscheint, die nur dann erscheinen soll, wenn jemand
die Systemzeit zurückstellt. Der Anwender hat das bestimmt nicht getan.

Hier meine Initialisierung des betreffenden Timers, extra auf 1 min. + 50ms, für den Fall
dass das System mal beschäftigt ist bzw. weil ja TTimer nicht so hoch präzise ist.

Delphi-Quellcode:

procedure TMyClass.InitTimeManipulationCheckTimer;
begin
  if not Assigned(FTimeManipulationCheck) then
  begin
    FTimeManipulationCheck          := TTimer.Create(nil);
    FTimeManipulationCheck.Interval := 60050; // 1 min. 50 ms
    FTimeManipulationCheck.OnTimer  := OnCheckTimeManipulation;
  end;

  FTimeManipulationCheck.Enabled := true;
  FLastCheckTime                 := now;
end;

FLastCheckTime ist natüprlich ein TDateTime Wert.

Hier das Timer Event:

Delphi-Quellcode:

procedure TMyClass.OnCheckTimeManipulation(Sender: TObject);
var
  Difference : Double;
begin
  Difference := Now-FLastCheckTime;

  // Wenn die Zeit nicht um mindestens 1 min. fortgeschritten ist wurde
  // sie manipuliert!
  if not (Difference >= System.DateUtils.OneMinute) then
  begin
    log.Send(LevelRed, cCategory,
             'Systemzeit wurde manipuliert (oder Zeitumstellung): ' +
             'Alt: ' + FLastCheckTime.ToString + ' Neu: ' + now.ToString);

    MessageDlg(rTimeManipulation, mtError, [mbOK], -1);
    Application.Terminate;
  end;

  FLastCheckTime := now;
end;

Ich verstehe nicht wie sonst die Meldung kommen kann. Das kann doch eigentlich
nur passieren, wenn der Timer nach < 1 min. das Event aufruft, was die 50 ms
zur 1 min. Interval Zeit eigentlich verhindern sollen. Kann denn der Timer so
unpräzise zu schnell werden?

[jaenicke]

Warum machst du das so ungenau und kompliziert? :?

Du kannst doch einfach einen eigenen Thread nutzen und diesen jeweils 60 Sekunden schlafen legen. Bei hoher Rechnerauslastung ist auch das nicht ganz genau.

Aber noch besser: Gleiche einfach den Wert von GetTickCount64 mit der eingestellten Zeit ab. GetTickCount64 zählt gleichmäßig weiter, auch wenn jemand die Systemzeit ändert. Wenn sich also die Differenz zur UTC-Zeit (sprich ohne Beachtung der eingestellten Zeitzone) ändert, hat jemand an der Uhr gedreht.

Nebenbei wurden beide Wege schon z.B. für Trial-Lösungen verwendet, sind aber beide kinderleicht auszutricksen. Es sollte also nichts wirklich Wichtiges auf diese Weise geschützt werden.

[himitsu]

Standby?

[TurboMagic]

Hallo,

danke schon mal für die Antworten.
Ich werde das mit dem GetTickCount64 mal probieren.

Regelmäßig prüfen muss ich dann trotzdem.
Ich baue das mal um und lasse es vom Anwender testen.

[HolgerX]

Hmmm...

wieso lässt Du dich nicht einfach informieren, wenn die SystemTime geändert wurde?

Mit dem GetTickCount64 musst Du dir ja die Zeit beim letzten Abfragen + die Counter merken und dann von beiden die Differenz prüfen...
Nur dass schon das Auslesen des Counters zu z.B. Now() zu minimalsten Differenzen führen kann und Du beim Vergleich mit Einer Tolleranz arbeiten musst.

Wenn Du dich jedoch seitens Windows informieren lässt, dann kannst Du das ganze Vergleichen ignorieren.

(google Suche:)
https://www.delphitips.net/2009/01/0...m-time-change/

[gubbe]

Zitat:

Zitat von TurboMagic (Beitrag 1538855)

Ich verstehe nicht wie sonst die Meldung kommen kann. Das kann doch eigentlich
nur passieren, wenn der Timer nach < 1 min. das Event aufruft, was die 50 ms
zur 1 min. Interval Zeit eigentlich verhindern sollen. Kann denn der Timer so
unpräzise zu schnell werden?

Was passiert denn, wenn Dein Programm beschäftigt ist und die Timer-Events nicht schnell genug abarbeiten kann?

Die Timer-Events werden über Windows-Messages generiert und reihen sich mit niedriger Priorität ein in alle anderen Messages vom Betriebsystem.
Wenn Dein Programm zu beschäftigt ist, um sie abzuarbeiten, stauen die sich in der Event-Queue. Dann können einzelne Timer auch mal ausfallen oder eben in Deinem Fall in kürzerer Zeit hintereinander abgearbeitet werden.

Hast Du berücksichtigt, dass die Differenz auch Negativ sein kann, wenn die Zeit zurückgestellt wurde? Da fehlt ein Abs() bei der Berechnung der Differenz.

Mir wäre das auch etwas zu heikel, Abweichungen von einer Sekunden erkennen zu wollen. Was ist denn, wenn z.B. die lokale Uhrzeit korrigiert wird durch einen Abgleich per NTP?
Welche Art von Manipulation willst Du denn erkennen? Reicht da nicht auch eine Prüfung nach deutlich größeren Abweichungen z.B. von über einer Stunde? Dann gibt es auch keine Probleme mit der Sommerzeit.

[Uwe Raabe]

Zitat:

Zitat von gubbe (Beitrag 1538867)

Die Timer-Events werden über Windows-Messages generiert und reihen sich mit niedriger Priorität ein in alle anderen Messages vom Betriebsystem.
Wenn Dein Programm zu beschäftigt ist, um sie abzuarbeiten, stauen die sich in der Event-Queue. Dann können einzelne Timer auch mal ausfallen oder eben in Deinem Fall in kürzerer Zeit hintereinander abgearbeitet werden.

Eigentlich werden WM_TIMER Messages erst auf Anfrage erzeugt, aber es gibt Fälle, wo diese dann ignoriert werden und sich in der Message-Queue stauen.
Raymond Chen hat da mal ausführlich was zu geschrieben: Why is my message queue full of WM_TIMER messages?

[Der schöne Günther]

Protipp: Die Windows-Zeitsynchronisierung stellt die Uhrzeit nicht auf einen Schlag richtig, wenn sie merkt, dass die Mainboard-Uhr etwas falsch läuft. Stattdessen stellt sie die Uhr, wen die Abweichung in einem bestimmten Rahmen liegt, immer etwas schneller oder langsamer, bis die richtige Uhrzeit wieder erreicht ist.

Vielleicht erklärt das auch etwas.

[gubbe]

Zitat:

Zitat von Uwe Raabe (Beitrag 1538873)

Eigentlich werden WM_TIMER Messages erst auf Anfrage erzeugt, aber es gibt Fälle, wo diese dann ignoriert werden und sich in der Message-Queue stauen.
Raymond Chen hat da mal ausführlich was zu geschrieben: Why is my message queue full of WM_TIMER messages?

Ok, ja, das war nur ein Sonderfall, dass die WM_Timer-Messages in kürzeren Abständen kommen.

Nur selbst wenn der Timer in mind. dem definierten Intervall aufgerufen wird, muss ich in der Ereignisroutine noch die aktuelle Zeit abfragen und speichern.
Sobald der Timer ausgelöst wird, läuft wieder die Zeitspanne zum Auslösen des nächsten Timers unabhängig davon wie lange es dauert, die Ereignisroutine abzuarbeiten.
Wenn also die Zeitspanne zum Auslesen und Speichern der Uhrzeit unterschiedlich lange dauert, könnte das auch zu der festgestellten Abweichung führen.

[Uwe Raabe]

Eventuell hilft ja auch, das Timer.Enabled innerhalb des Events temporär auf False zu stellen (man beachte das Exit im if-then):

Delphi-Quellcode:

procedure TMyClass.OnCheckTimeManipulation(Sender: TObject);
var
  Difference : Double;
begin
  (Sender as TTimer).Enabled := False;
  Difference := Now-FLastCheckTime;

  // Wenn die Zeit nicht um mindestens 1 min. fortgeschritten ist wurde
  // sie manipuliert!
  if not (Difference >= System.DateUtils.OneMinute) then
  begin
    log.Send(LevelRed, cCategory,
             'Systemzeit wurde manipuliert (oder Zeitumstellung): ' +
             'Alt: ' + FLastCheckTime.ToString + ' Neu: ' + now.ToString);

    MessageDlg(rTimeManipulation, mtError, [mbOK], -1);
    Application.Terminate;
    Exit;
  end;

  FLastCheckTime := now;
  (Sender as TTimer).Enabled := True;
end;