Exception-Logging für ungefangene Exceptions aus DLLs

[Der schöne Günther]

Ein altes Delphi-Projekt schluckt viele Exceptions oder lässt sie auf die VCL durchbubbeln. Es soll nun so erweitert werden, dass diese Exceptions mit Callstack in eine Textdatei gelogged werden sollen.

Bis hierhin noch einfach. Jetzt das Problem: Das Projekt benutzt viele DLLs die ebenfalls in Delphi erstellt wurden. Es ist nicht garantiert dass alle von den DLLs exportierten Methoden keine Exceptions werfen. Die Aufruf-Direktive ist durchgehend

Delphi-Quellcode:

stdcall

.

Meine Frage: Ich kann für Exceptions aus der Anwendung ja einfach die Variable

Delphi-Quellcode:

Exception.GetExceptionStackInfoProc

auf eine Prozedur setzen die mir den Stacktrace ausliest (z.B. mit der JCL). Bei einer Exception direkt aus einer DLL wird das nie aufgerufen. Warum nicht? Was kann ich tun?

Ich habe keine Hoffnung, an den Stack aus der DLL zu kommen. Aber wenigstens die Stelle aus der Hauptanwendung werde ich doch wissen können?

Ich bin ganz ehrlich, mir fehlt das Lowlevel-Wissen, was da intern passiert. Ohne wirklich zu verstehen was da vor sich geht probierte ich mal mit der Aufruf-Direktive

Delphi-Quellcode:

safecall

. Hier wird

Delphi-Quellcode:

Exception.GetExceptionStackInfoProc

wieder ganz normal aufgerufen, aber Delphi scheint das ganze irgendwie komisch zu wrappen und wirft am Schluss lieber eine dumme OleException welche die eigentliche Exception nicht mehr beinhaltet.

Auf die Idee kam ich nur da Wikipedia spricht:

Zitat:

The safecall calling convention is the same as the stdcall calling convention, except that exceptions are passed back to the caller in EAX as a HResult (instead of in FS:[0]), [...]

Kann ich Hoffnung haben, in meinem Hauptprogramm einfach überall

Delphi-Quellcode:

stdcall

durch

Delphi-Quellcode:

safecall

zu ersetzen? Mann, sind das wilde Gedanken.

Anhang 43682

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1311467)

Ich habe keine Hoffnung, an den Stack aus der DLL zu kommen. Aber wenigstens die Stelle aus der Hauptanwendung werde ich doch wissen können?

Wir benutzen dafür Eurekalog. Sofern du auch die DLL mit Eurekalog und damit mit den nötigen Debuginformationen kompilierst, bekommst du auch den Stacktrace inkl. der Methoden, die in der DLL liegen. (Auch wenn es eigentlich keine gute Idee ist, dass Exceptions nicht alle in der DLL abgefangen werden...)
MadExcept sollte genauso funktionieren.

Bei Eurekalog sieht dass dann so aus:

Anhang 43683

Mehr Informationen hier:
https://www.eurekalog.com/help/eurek...ex.php?dll.php

Du kannst auch Standard-Debuginfos in Form von .dbg Dateien mitliefern, dann können sogar externe Tools wie der Process Explorer oder das Windows-Fehlerbehandlungstool problemlos Stacktraces erstellen.

[Luckie]

Sind die DLLs von dir?

[frankyboy1974]

Hallo,

vielleicht verstehe ich hier etwas nicht richtig, aber dennoch: Du rufst eine Funktion einer DLL auf, diese Prozedur ruft ihrerseits ggf. eine andere Funktion auf (und so weiter und so fort), irgendwo tritt jetzt ein Fehler auf, was würde dir jetzt ein StackTrace bringen????
Du weisst also, dass in der DLL beim Aufruf der Funktion "Wieauchimmerichheisse" ein Fehler auftritt (wobei natürlich ohne der Debug-Informationen, der Name grundsätlich hier nicht mehr steht), was bringt dies dass jetzt weiter.
Wie du in deiner eigenen Anwendung die Frage beantworten könntest

Zitat:

Aber wenigstens die Stelle aus der Hauptanwendung werde ich doch wissen können?

.

Delphi-Quellcode:

try

dll.tuewas
except
log.fehlerwarbeituewas
end

mfg

frank

[jaenicke]

Was aber ein deutlich höherer Aufwand ist als einfach EurekaLog oder MadExcept einzubinden und gar nichts weiter im Code zu ändern...

[Der schöne Günther]

Hallo-

Danke für die Antworten bislang. Eurekalog, madExcept und Konsorten kommen leider nicht in Frage: Es soll nichts kosten. Die JCL erfüllt das Kriterium. Etwas anderes kenne ich nicht.

Ich glaube, alle DLLs die Exceptions werfen KÖNNTEN sind Borland DLLs, also Delphi und C++ Builder. Und ich meine, zu allen liegt der Source vor. Anpassen würde ich das aber gerne NICHT.

Blöd, grade so etwas wie auf deinem "EurekaLog"-Bild würde ich gerne haben. Ich kenne mich hier nicht aus, würde es einen Unterschied machen, ob die DLL statisch oder dynamisch eingeladen wird?

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1311657)

Eurekalog, madExcept und Konsorten kommen leider nicht in Frage: Es soll nichts kosten.

madExcept ist kostenlos für nicht kommerzielle Nutzung.

Zitat:

Zitat von Der schöne Günther (Beitrag 1311657)

würde es einen Unterschied machen, ob die DLL statisch oder dynamisch eingeladen wird?

Nein

[Der schöne Günther]

Zitat:

Zitat von jaenicke (Beitrag 1311673)

madExcept ist kostenlos für nicht kommerzielle Nutzung.

Ich weiß, das ist aber kein Hobby-Projekt ;-)


Die JCL hat auch ein Demo dabei wo er auch genau kann, was Eurekalog da macht. Der Code ist aber für mein Gehirn zu verworren um ihn überhaupt extrahieren zu können. Deshalb nehme ich, wenn

Delphi-Quellcode:

meineException.StackTrace

leer ist (also der Automatismus nicht gegriffen hat), einfach den normalen Stacktrace (in einem ominösen "raw mode"). Das sieht dann ungefähr so aus:

Code:

Sender: TForm2
Exception: EProgrammerNotFound: 'The programmer has gone home'
[006107D9] Debug.StackTracer.TStacktracerJCL.getStack (Line 80, "Debug.StackTracer.pas")
[00610E4E] NewExceptionHandlingProject.TExceptionHandler.ObtainStackTrace (Line 145, "NewExceptionHandlingProject.dpr")
[00610C6C] NewExceptionHandlingProject.TExceptionHandler.HandleException (Line 121, "NewExceptionHandlingProject.dpr")
[005DB672] Vcl.Forms.TApplication.HandleException
[0052DDDF] Vcl.Controls.TWinControl.MainWndProc
[004084B3] System.TMonitor.Exit
[0052DDA4] Vcl.Controls.TWinControl.MainWndProc
[006104C0] Unit2.TForm2.Button2Click (Line 116, "Unit2.pas")
(ca 50 weitere Zeilen)

Ich glaube für meine Zwecke soll das reichen :-)

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1311688)

Ich weiß, das ist aber kein Hobby-Projekt ;-)

Dann dürfte es mehr kosten auf diese Tools zu verzichten als die Tools kosten, einerseits wegen des Aufwands das Exceptionhandling einzubauen, andererseits aufgrund der vermutlich schlechteren Ergebnisse. ;-)

Aber das musst du natürlich bezogen auf das Projekt selbst beurteilen...