Visual Studio 2008 SP1 Laufzeitfehler Offset

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?

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 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.

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?

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

Ja.

Vielen Dank für eure Antworten!