Visual Studio 2008 SP1 Laufzeitfehler Offset

[Johannes T. (johnsn)]

Hallo,

ich habe ein C++ Programm in Visual Studio 2008 geschrieben. Es wurde 
eine Release-Executable erstellt und das Programm aktuell auf einem 
anderen Rechner (kein VS, keine Debugumgebung) auf Windows XP 32-Bit 
ausgeführt.

Das Programm läuft nun ab und zu in einen fehlerhaften Zustand rein und 
Windows Error Reporting fängt den Prozess ab mit einer Fehlermeldung. 
Öffnet man anschließend die Ereignisanzeige (Systemsteuerung > 
Verwaltung) findet man auch einen entsprechenden Eintrag (siehe 
angehängten Screenshot) mit einer Fehleraddresse.

Meine Frage: Habe ich die Möglichkeit anhand dieser Fehleraddresse im 
Visual Studio herauszufinden, welche Codezeile den Fehler ausgelöst hat?

[Peter II (Gast)]

Johannes T. schrieb:
> Meine Frage: Habe ich die Möglichkeit anhand dieser Fehleraddresse im
> Visual Studio herauszufinden, welche Codezeile den Fehler ausgelöst hat?

ich denke nicht, weil es bei dieser Adresse nicht um eine Codezeile geht 
sondern um den zugriff auf den Heap/Stack.

Du schau mal nach ob die die dw.Watson protokolle findest, dort sind 
viel mehr infos vorhanden mit den man etwas anfangen kann.

[Johannes T. (johnsn)]

Dr. Watson und Dump-Files hab ich schon versucht. Problem hierbei ist, 
dass der Dump erstellt wird, nachdem der Fehler aufgetreten ist. Somit 
sehe ich dann nicht mehr wo der Fehler aufgetreten ist, wenn ich das 
Dumpfile lade.

Bei der Fehleradresse handelt es sich ja um einen Fehleroffset, der, 
soweit ich gesehen haben, beim selben Fehler immer gleich ist. Könnte 
man also theoretisch über das Map-File herausfinden, welche Variablen 
oder Objekte davon betroffen sind?

[Rufus Τ. F. (rufus)]

Johannes T. schrieb:
> Meine Frage: Habe ich die Möglichkeit anhand dieser Fehleraddresse im
> Visual Studio herauszufinden, welche Codezeile den Fehler ausgelöst hat?

Nicht direkt. Allerdings wird unter XP ein Tool namens DrWtsn32.exe 
aktiv, das eine Logdatei mit einem Stackdump des abstürzenden Programmes 
erzeugt - durchsuche Deine Platte nach drwtsn32.log

In dieser Datei musst Du nur nach "Fehler" suchen und hast den 
Stacktrace des abstürzenden Threads.

Im Visual Studio startest Du Dein Programm im Single-Step-Betrieb, gehst 
in die Assembler-Ansicht und mit "Goto" zu einer der im Stacktrace 
aufgelisteten Adressen (mit 0x davor eingeben).

Drwtsn32 kann auch dazu gebracht werden, einen Speicherabzug zu erzeugen 
werden, dazu einfach "drwtsn32.exe" aufrufen und ein Häkchen vor "Datei 
für Absturzspeicherabbild erzeugen" setzen.

Diese Datei kann vom Debugger geladen werden und erlaubt dann, den Stack 
nicht nur auf Adressen, sondern auch auf an Funktionen übergebene 
Argumente sowie lokale Variablen zu untersuchen -- und auch statische.

[Peter II (Gast)]

Johannes T. schrieb:
> Dr. Watson und Dump-Files hab ich schon versucht. Problem hierbei ist,
> dass der Dump erstellt wird, nachdem der Fehler aufgetreten ist. Somit
> sehe ich dann nicht mehr wo der Fehler aufgetreten ist, wenn ich das
> Dumpfile lade.

klar, man kann doch dort den callStack sehen. Damit sieht man in welchen 
codebreich man ist.

> Könnte
> man also theoretisch über das Map-File herausfinden, welche Variablen
> oder Objekte davon betroffen sind?
meist nein, weil man ja keine globalen oder static variabeln hat. Und 
von dem Rest weiss das Mapfile nichts.

[Rufus Τ. F. (rufus)]

Peter II schrieb:
>> man also theoretisch über das Map-File herausfinden, welche Variablen
>> oder Objekte davon betroffen sind?
> meist nein, weil man ja keine globalen oder static variabeln hat. Und
> von dem Rest weiss das Mapfile nichts.

Die stehen im "Absturzspeicherabbild", das dort gespeichert wird, wo 
DrWtsn32 seine Logdatei erzeugt.

Bei Windows ab Vista ist das natürlich alles ganz anders, dort wird das 
in einem Verzeichnis

C:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\WER\ReportArchive

versteckt.

[Johannes T. (johnsn)]

Peter II schrieb:
> klar, man kann doch dort den callStack sehen. Damit sieht man in welchen
> codebreich man ist.

Leider nein, weil es 1. ein Release Build (ohne Debuginfos) ist und 2. 
im Fehlerfall der Call Stack von Windows Error Reporting offenbar 
verändert wurde. So hab ich es zumindest bei meinen zahlreichen 
Versuchen vorgefunden.


Rufus Τ. Firefly schrieb:
> Bei Windows ab Vista ist das natürlich alles ganz anders, dort wird das
> in einem Verzeichnis
>
> C:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\WER\ReportArchive
>
> versteckt.

Ist das für Win7 der gleiche Pfad?

[Rufus Τ. F. (rufus)]

Johannes T. schrieb:
> Ist das für Win7 der gleiche Pfad?

Ja.

[Johannes T. (johnsn)]

Vielen Dank für eure Antworten!