Fehlersuche auf Basis von Ausnahmeadressen

Mein Problem ist dass ich die Ursache von Programmabstürzen ausfindig machen muß, die bei einer Ausführungsdatei auftreten, die ohne Symbole und mit Optimierungen kompiliert wurde.
Dass ich die Adresse des Ausnahmefehlers abfangen muß ist mir soweit schon klar, nur weiß ich nicht wie ich auf Basis dessen am besten den Ort im Quelltext zuordnen kann.

Ich habe bisher zwei Möglichkeiten ausfindig gemacht: mapfiles und Speicherabbilder, aber leider finde ich einfach keine übersichtliche Beschreibung dazu.

Zu den mapfiles finde ich nur eine Beschreibung wie man mit hohem Aufwand manuell die Adresse ausfindig macht. Gibt es dazu kein Programm was das erledigt?
Zum Thema Speicherabbildern kann ich noch weniger zusammenhängendes finden.

Es würde mir wirklich weiterhelfen wenn mir jemand einfach eine kurze Übersicht zu den derzeitigen Möglichkeiten geben könnte (oder zu der Information verweist).

PS.: Ich nutze Visual Studio 2008 Pro.

Jochen Kalmbach

Du schreibst einfach in SetUnhandledExceptionFilter einen MiniDump (MiniDumpWriteDump) und lässt Dir diesen zukommen. Dieser kannst Du dann in VS208 per doppel-click öffnen und F5 drücken. Dann siehst Du den kompletten Callstack.
Du brauchst aber auf Deinem VS-Debug-Rechner die EXE und PDB-Datei des Builds, welches auf dem Kundenrechner lief.

Jochen Kalmbach schrieb:

Du schreibst einfach in SetUnhandledExceptionFilter einen MiniDump (MiniDumpWriteDump) und lässt Dir diesen zukommen. Dieser kannst Du dann in VS208 per doppel-click öffnen und F5 drücken. Dann siehst Du den kompletten Callstack.
Du brauchst aber auf Deinem VS-Debug-Rechner die EXE und PDB-Datei des Builds, welches auf dem Kundenrechner lief.

Leider kann ich keine Programmdatenbank für den Kunden generieren da ich mehrere Optimierungsoptionen von MSVC (und übrigens auch ICC 11) nutzen muß.

hustbaer

Atta schrieb:

Jochen Kalmbach schrieb:

Du schreibst einfach in SetUnhandledExceptionFilter einen MiniDump (MiniDumpWriteDump) und lässt Dir diesen zukommen. Dieser kannst Du dann in VS208 per doppel-click öffnen und F5 drücken. Dann siehst Du den kompletten Callstack.
Du brauchst aber auf Deinem VS-Debug-Rechner die EXE und PDB-Datei des Builds, welches auf dem Kundenrechner lief.

Leider kann ich keine Programmdatenbank für den Kunden generieren da ich mehrere Optimierungsoptionen von MSVC (und übrigens auch ICC 11) nutzen muß.

Und?
Man kann PDBs auch bei optimierten Builds erstellen lassen. Ich weiss das, weil ich jeden Tag Programme baue, wo das gemacht wird

Natürlich sind die Debug-Informationen dann nicht so "genau" wie bei Debug-Builds, aber grundsätzlich geht das wunderbar. Und ist auch trotzdem sehr sehr hilfreich wenn man Fehler sucht.

p.S.: relativ finster sieht es allerdings aus, wenn du das Programm nicht nochmal bauen kannst. In dem Fall kannst du nurmehr das Dump-File in den Debugger laden, und dir dann den Assembler-Code angucken. Was sehr mühsam ist, und oft erfolglos bleibt.

BTW: zum Erzeugen von Dumpfiles gibt's Tools, die man auf nen laufenden Prozess draufhängen kann, die dann ein Dumpfile schreiben sobald der crasht.
Tess Ferrandez beschreibt in ihrem Blog wie das geht:
http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx
(Im ihrem Blog geht's um .NET, aber das schreiben von Dumpfiles unterscheidet sich nicht, also kannst du das 1:1 wie dort beschrieben machen)

Dazu muss ich ja beim Linker \DEBUG einschalten.
Der schreibt dann die Symbole wirklich nur in die Programmdatenbank und nichts in die Binärdatei?

Wenn ich jetzt so recht überlege habe ich bisher (falsch) angenommen dass \DEBUG das Gegenteil von NDEBUG bedeutet. Hat aber natürlich nichts miteinander zu tun, da das eine für den Linker und das andere für den Compiler bestimmt ist.
Schön doof, was?

Vielen Dank für Eure Ratschläge!

hustbaer

Atta schrieb:

Dazu muss ich ja beim Linker \DEBUG einschalten.
Der schreibt dann die Symbole wirklich nur in die Programmdatenbank und nichts in die Binärdatei?

Soweit ich weiss schreibt er dadurch nicht mehr in die Programmdatei (.dll/.exe), als er ohne den /DEBUG Switch auch würde. Wobei garantieren kann ich es nicht. Die ganzen riesen Debug-Infos stehen auf jeden Fall dann in der .PDB Datei und nicht in der .exe/.dll -- das merkt man auch schon daran, dass die .exe/.dll nicht grösser wird wenn man mit /DEBUG linkt, das .PDB File aber vergleichsweise riesig ist.

Ahja, doch, eins schreibt er schon in die .exe/.dll: den Pfad zum .PDB File. Du solltest also nicht unbedingt in einem Verzeichnis compilieren, welches "C:\ScheissVerfickteDreckskunden\..." oder so heisst