Programmcrash & Drwatson32

[enricoffo]

Hallo,

ich weiß nicht, ob ich hier mit meiner Frage richtig bin, aber ich versuche es mal.

Ich habe eine kleines Programm geschrieben. Es läuft auf so ziemlich jeden PC, wo ich es getestet habe, nur auf einem, da wo es eigentlich benutzt werden soll, geht es nicht.

Dr Watson zeichnet mir ein tolles Speicherabbild auf (dump.dmp) und in der DrWats32.log steht, das ein Stapelüberlauf c00000fd stattgefunden hat. Und der Fehler bei 7c8024e0 aufgetreten ist (53 push ebx).

Jetzt meine Frage:

Da ja auf diesem PC kein Delphi installiert ist und ich dies auch nicht machen möchte kann ich ja nicht mit dem Delphi-Debugger im Einzelschritt durchlaufen.
Was kann ich dann tun.

Wie kann ich das Dr Watson32 Abbild auswerten und wie finde ich in Delphi die Absturzstelle ?? (7c8024e0)

Wo finde ich dazu hinweise und wonach muß ich da genau suchen???

Herzlichen Dank schon mal im vorraus.

[Bernhard Geyer]

In der Jedi gibt es Units (JclDebug) mit deren Hilfe + Debuginfos du den Aufrufstack bis zum Fehler dir holen kannst. Könnte aber sein das dies bei einem Stack overflow nicht hilft.

[Laufi]

Hallo

Schreib einfach in jede prozedur in try except end dann kommt der fehler nicht mehr!

Liebe Grüsse
Laufi

[Christian Seehase]

Moin enricoffo,

schau Dir doch mal madexcept an.
Das sollte Dir aufschlussreichere Informationen liefern, als DrWatson.

@Laufi:

Zitat:

Zitat von Laufi

Schreib einfach in jede prozedur in try except end dann kommt der fehler nicht mehr!

Das war jetzt aber nicht Dein Ernst, oder?

[fwsp]

immer mit dem holzhammer...

[Laufi]

Klar, er hat ja geschrieben dass es sonst auf allen Rechnern läuft also funktioniert das Program und der Fehler kann vernachlässigt werden, es würde nur stören

Liebe Grüsse
Laufi

[Bernhard Geyer]

Noch 'ne Alternative bei D7. Da gibt es doch den Remote-Debugger und solange der Absturz nicht gleich beim Starten kommt kann man damit auch schön debuggen ohne Delphi zu installieren.

[enricoffo]

Hi,

danke für die schnellen Antworten.
Ich habe schon versucht eine log-Datei zu erstellen. Diese wird im createteil geschrieben, leider
kommt mein Programm nicht soweit.

[Christian Seehase]

Moin Laufi,

ein Stapelüberlauf deutet auf eine rekursive Endlosschleife hin, und die wirst Du mit try/except auch nicht los ;-)
[EDIT]
(und kann auch mit Sicherheit nicht vernachlässigt werden)
[/EDIT]

[Luckie]

Es funktioniert eben nicht, sonst würde es ja auf allen Rechnern fehlerfrei laufen.

[enricoffo]

Guten Morgen,

ich wollte mal die Problemlösung posten, nur zur allgemeinen Information.

1. Danke für den Tipp mit den MAD-Tools.
2. Mein Programm kam ja nicht wirklich weit, Dr Watson war ja wesentlich schneller.

Dank der MAD-Tools ging es blitzschnell. Da mein Programm über DAO auf eine Access-DB zugreifen sollte braucht es ja ein installiertes DAO im System.
Es war auch installiert. Leider war aber die "DAO360.dll" nicht registriert(altes M$ Problem und auch gut erklärt in irgendeinem KBxxxx-Teil). Tja, eigene Dummheit.
Nachdem dann beim Datenbank öffnen eine EDatabaseException kam (no DAO), war die Lösung ziemlich easy. Regsrv32 DAO360.dll und siehe da, es geht...


Aber trotzdem würde es mich mal interessieren, wie man diesen Microsoft Dr Watson-Report auswerten kann und diese Hexadresse, wo der Fehler auftrat im Delphicode finden kann.
Wenn da jemand ne Idee hätte oder eine Anregung, wäre echt toll.


Herzlichen Dank nochmal für die schnelle Hilfe an Euch alle.

[Bernhard Geyer]

Zitat:

Zitat von enricoffo

Da mein Programm über DAO auf eine Access-DB zugreifen sollte braucht es ja ein installiertes DAO im System. ...

Und wieso nutzt Du noch DAO? AFAIK darf man das nur installieren (wenn es nicht aufgrund eines "Installationsfehlers" von MS nicht aktiv ist wenn man eine Anwendung mit einer MS-IDE mitverteilt. Wie wäre es mit einem Wechsel nach ADO (Auch wenn MS eh schon den Tod von ADO und Access als Datenbank vorranschreiten läßt).

Zitat:

Zitat von enricoffo

Aber trotzdem würde es mich mal interessieren, wie man diesen Microsoft Dr Watson-Report auswerten kann und diese Hexadresse, wo der Fehler auftrat im Delphicode finden kann.

Das bringt dir nur etwas wenn auf beiden Rechner dein Programm über die gleichen Speicheradressen geladen wird. Dann kannst Du dein Programm in der IDE starte und den Menüpunkt "Bearbeiten/Laufzeitfehler suchen" anwählen. Wenn Du glück hast landest Du auf Pascal-Code. Wenn nicht dann hast Du zu wenig Debug-Infos (Debug-DCU's) in deinem "Testprogramm" und must diese Aktivieren. Alternativ schau dir mal die Jedi an. Dieses bietet komprimierte TD32-Debug-Infos und eine Hilfsdialog der dir bei einer Exeption sogar 'ne E-Mail mit Aufrufstack liefern kann.

[Christian Seehase]

Moin Bernhard,

Zitat:

Zitat von Bernhard Geyer

Das bringt dir nur etwas wenn auf beiden Rechner dein Programm über die gleichen Speicheradressen geladen wird.

Was beim normalen Start einer Exe (also nicht, z.B., über LoadLibrary um nur die Resourcen auszulesen) immer der Fall sein.
Ansonsten dürften Programme, denen man die Relocation-Table entfernt hat, um sie kleiner zu machen, auch massiv Probleme bereiten.

[enricoffo]

Also ich benutze DAO, weil man damit sehr schnell und einfach auf dBase zugreifen kann. Und das muß ich oft in der Firma. ADO ist da einfach zu langsam und TDBF bietet mir keine SQL-Abfragen.
Und extra einen SQL-Server für 'n Mücke ist doch quatsch, oder?

Was habe ich denn für Alternativen???

[Bernhard Geyer]

Zitat:

Zitat von Christian Seehase

Was beim normalen Start einer Exe (also nicht, z.B., über LoadLibrary um nur die Resourcen auszulesen) immer der Fall sein.
Ansonsten dürften Programme, denen man die Relocation-Table entfernt hat, um sie kleiner zu machen, auch massiv Probleme bereiten.

Ok. Sagen wir lieber so das dieses Problem eher bei den noch zusätzlichen (Delphi-)DLL's auftritt da diese ja (wenn man nichts ändert) in der IDE die gleiche Startadresse bekommen.

Zitat:

Zitat von enricoffo

Also ich benutze DAO, weil man damit sehr schnell und einfach auf dBase zugreifen kann.

Kannst Du doch auch mit ADO wenn du dort die Jet-Engine benutzt.

Zitat:

Zitat von enricoffo

ADO ist da einfach zu langsam

Halte ich für ein Gerücht. Da bei beiden die Jet-Engine ist die verwendet wird kann es eigentlich nur an unpassenden Default-Einstellungen von ADO (Servercurser = UseClient, welche man bei Access auf UseServer umstellen sollte). Ansonsten sollten beide Zugriffe ähnlich schnell sein.

Zitat:

Zitat von enricoffo

Und extra einen SQL-Server für 'n Mücke ist doch quatsch, oder

Hab ich ja auch nicht gesagt: ADO != MS SQL-Server.