Exception ''access violation ' beim beenden des Programms

[Kostas]

Hallo Zusammen,

grundsätzlich die Frage, gibt es ein Tool welches auch Exceptions direkt beim beenden der Anwendung erkennt um die Ursache zu finden?

Code:

Im Projekt XY.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x09e6cad2: read of address 0x0622cc48' aufgetreten.

Ich verwende in ein Projekt ein Hardware (SignPad) um eine Unterschrift zu digitalisieren.
Die Hardware liefert ein ActiveX Control um die Unterschrift anzuzeigen. Auf einer VCL-Form wird das ActiveX-Control abgelegt
zum anzeigen der Unterschrift beim Digitalisieren. Rufe ich die Form aus einer neuen normale VCL-Form Anwendung auf,
unterschriebe und beende die Anwendung wird keine Exception ausgelöst.
Erzeuge ich nun eine neue MDI-Form Anwendung und rufe die gleiche Form auf, unterschriebe und beende die Anwendung, kommt die Exception.

EurekaLog (aktuelle Testversion) merkt die Exception nicht!

Ich habe es jetzt vorübergehend so gelöst dass ich die VCL-Form Anwendung mit der Unterschrift-Form eine eigene Exe erzeuge und die Exe
aus der MDI-Anwendung aufrufe. Das funktioniert scheinbar immer. Langzeittests habe ich noch nicht durchgeführt.

Kennt jemand so ein Tool? Ich habe AQTime noch nicht verwendet. Kann es möglicherweise so etwas aufspüren?

Gruß Kostas

[Sir Rufo]

Ja, das Tool heißt Debugger und Stacktrace

[Kostas]

Hallo Sir Rufo,

bei jeder exception bekomme ich eine neune Adresse. Ich kann also nicht nach dem Compilieren auf eine Adresse springen.
Hast du mir bitte ein Hinweis wie ich vorgehen muss?

Gruß Kostas

[Sir Rufo]

Starte dass Programm mit dem Debugger und wenn die Exception geworfen wird, dann poppt erst ein Fenster von der IDE auf, da dann auf abbrechen und man befindet sich im Quelltext- oder CPU-Fenster.

Links oben befindet sich idR der Stacktrace, den man dann mal Schritt für Schritt zuruckgeht, bis man an die Stelle im eigenen Code kommt. Dort befindet sich dann die Stelle, die für das Auslösen mittelbar verantwortlich ist.

Meine Vermutung

Der Fehler tritt bei einer MDI Anwendung auf. Kann es sein, dass du das Fenster extra erzeugst, aber zusätzlich auch schon im Hintergrund eine Form-Instanz erstellt wurde (in der .dpr nachschauen).

Diese automatisch erzeugte Instanz wird beim Beenden natürlich entsorgt, aber dabei wird auf etwas zugegriffen, was du mit der manuell erzeugten Form-Instanz schon abgeräumt hast. ;)

Das ist natürlich nur ein Blick durch die Glaskugel, dein geposteter Quellcode war mir einfach zu lang

[Furtbichler]

Obwohl das von Sir Rufo beschriebene Verfahren vermutlich zum Ziel führt, versagt klassisches Debuggen häufig, vorzugsweise beim Beenden eines Programms. Wenn der Fehler nicht im eigenen Code liegt, dann wird es schwierig. Wir treffen hier auf Seiteneffekte, d.h. Probleme, die deshalb auftreten, obwohl man eigentlich nichts Falsches gemacht hat. Wer hätte z.B. gedacht, das man Probleme beim Beenden bekommt, wenn man Threads mit 'FreeOnTerminate=True' startet?

Andere Fallstricke sind die `Finaliziation` Abschnitte eigener oder fremder Units. Oder irgendein Destruktor, der falsch aufräumt.

[mjustin]

Zitat:

Zitat von Kostas (Beitrag 1253171)

Kennt jemand so ein Tool?

madExcept - http://madshi.net - würde ich auch ausprobieren (es arbeitet ähnlich wie Eurekalog)

[Kostas]

Zitat:

Zitat von Sir Rufo (Beitrag 1253174)

...
Meine Vermutung

Der Fehler tritt bei einer MDI Anwendung auf. Kann es sein, dass du das Fenster extra erzeugst, aber zusätzlich auch schon im Hintergrund eine Form-Instanz erstellt wurde (in der .dpr nachschauen).
...

Darauf habe ich geachtet. Das ist definitiv nicht der Fall. Ich hätte erwähnen müssen, wenn ich die Form mit dem ActiveX Control öffne
also das ActiveX Control wird erzeugt, kann ich beenden und erneut aufrufen ohne Probleme. Wenn ich jedoch nach dem öffnen des Forms
auf die Idee komme, das SignPad zu aktivieren zum unterschrieben, und danach die App beenden bei einer MDI-App dann knallts.
Das ActiveX Control macht über die importierte TLB irgend welche DLL aufrufe und die Hardware zu steuern. Doch warum nur beim beenden
einer MDI-App der Fehler auftritt und nicht bei einer VCL-Forms App ist mir sehr schleierhaft.

Im Stacktrace zu suchen ist nicht so einfach denn ich habe keinen Hinweis was es für ein Fehler ist.

Gruß Kostas

P.S. ich werde auch mal das Tool madExcept ausprobieren.

[Uwe Raabe]

Es gibt ein paar Unterschiede zwischen MDI- und Nicht-MDI-Forms. So wird bei einem MDI-Child beim Close kein Hide sondern nur ein Minimize ausgeführt. Je nachdem was deine Eventhandler so tun wird das im einen Fall ausgeführt und im anderen nicht.

[Kostas]

Hallo Uwe,

das ist es leider auch nicht. Die Form ist eine Modale Form. Dessen Unit hat eine Methode um die Form zu erzeugen und zeigt sie per ShowModal an.

Delphi-Quellcode:

function StartfrUnterschrift:TModalResult;
begin
  with frUnterschrift do
  begin
    frUnterschrift := TfrUnterschrift.create(Application);
    try
      result := ShowModal;
    finally
      release;
      frUnterschrift:=nil;
    end;
  end;
end;

Die Form beinhaltet also nur das ActiveX Control und zwei drei Buttons. Wenn die Form erzeugt wird und somit auch das ActiveX Control,
und die App wird beendet, passiert nichts. Wenn jedoch die Form erzeugt wird und man die Methode vom ActiveX Control ausführt, kommt
die exception jedoch nur bei MDI-Apps. Mittlerweile habe ich auch madExcept ausprobiert, auch dieses Tool merkt die exception nicht.
Die Exception wird vermutlich in der DLL vom SignPad ausgelöst. Vermutlich wird irgend ein Handle nicht mehr existieren.
Ich werde mal den Hersteller fragen. Ich gehe nicht davon aus der es den Fall kennt, aber fragen kann man ja mal.

Gruß Kostas

[Uwe Raabe]

Delphi-Quellcode:

  with frUnterschrift do
  begin
    frUnterschrift := TfrUnterschrift.create(Application);
    try
      result := ShowModal;
    finally
      release;
      frUnterschrift:=nil;
    end;
  end;

Das tut aber jetzt schon weh!
Ich habe jetzt auch keine Lust auszuprobieren, was da wirklich passiert, aber lös doch bitte mal das with auf...