eigener Debugger - Haltepunkte

[himitsu]

Tachchen,

hat hier schonmal jemand selbst einen Debugger gebastelt?

Bin noch in den Planungen/Überlegungen,
aber bezüglich Haltepunkte finde ich fast keine Infos.
https://learn.microsoft.com/de-de/wi...ging-functions

Im Grunde heißt es (Stackoverflow usw.),
* ich sollte die Stellen mit RAM/Code patchen (WriteProcessMemory) -> INT 3
* dann im Debugger warten (EXCEPTION_BREAKPOINT)
* die Stelle wieder zurück patchen
* den CodeZeiger um 1 zurückstellen
* und dann kann es weiter gehn
* (auch wenn es niemand sagte) am Ende muß ich die Stelle ja wieder neu patchen, damit der Haltepunkt erneut auslösen kann

* im Grunde müsste ich dann auch erst einen Einzelschritt machen, dann patchen und nun weiter (damit der Patch drin ist, bevor das Programm da wieder vorbei kommt)
* und natürlich immer schön FlushInstructionCache

Aber ich dachte man kann sich da auch irgendwo "registrieren" und die Haltepunkte beim OS quasi in eine Liste eintragen, ohne den Code patchen zu müssen.



Bei VirtualAlloc/VirtualProtect hatte ich auch schon nachgesehn, ob man da vieleicht ein Flag setzen kann, aber das Einzige (PAGE_GUARD) klingt nicht vielversprechend.




Ach ja, es wird nicht wirklich ein Debugger ... ich möchte nur dessen Funktionen nutzen, für einen kleinen Profiler/Tracer.

[Kas Ob.]

Hi,

This subject is deep, i mean really deep, yet it is not that hard once you got the idea, and it is not that straight forward, as you drawn it, i had built small debugger (-ish) for fun and learning and dropped it when felt i got what i need to know and the whole thing started to become boring.

See, if the break point happened by a simple trap like INT3 then the thread triggered it will change its execution and jump, hence losing and corrupting its own thread context at that moment.
To prevent that you need to set the debugging environment first, and that include using the CPU debug registers https://en.wikipedia.org/wiki/X86_debug_register , and this is the tricky part or the complicated part, yet it is pretty straight forward from here.

I suggest reading about the subject and i have very nice resources about that:
1) The Wikipedia page mentioned above is hard to interpret but can be used as reference.

2) There is great blog posts from an expert, an ex member of Microsoft Debugger Platform team:
https://www.timdbg.com/
Part 5 is about breakpoints https://www.timdbg.com/posts/writing...cratch-part-5/ and he is using https://wiki.osdev.org/CPU_Registers...ebug_Registers as reference instead of Wikipedia.

3) My favorite one ! and this one i am using in many places when i need to do runtime stuff.
https://github.com/x64dbg/TitanEngine
This engine is used in xdbg64 as main debugging engine, it is very powerful, also have unique capabilities for hooking, a Pascal header is here, but it might be out-dated
https://github.com/jsj2008/TitanEngi...ter/SDK/Delphi

4) The one that really might help you is CheatEngine, it is not for moding/patching games, but it can do many many things, i use it as debugging tool as it is one mighty debugger written in Pascal:
https://github.com/cheat-engine/cheat-engine

Hope that helps.

[Rollo62]

Willst Du Dir das wirklich antun? Das genzt schon an Masochismus :-D
Reicht nicht eventuell schon eine Scriptsprache?
https://www.delphitools.info/dwscript/

[dummzeuch]

Multithreading nicht vergessen! Das ist ja schon nicht einfach, ohne dass man einen Debugger schreiben will. Wie viele Jahre willst Du investieren?

[himitsu]

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.
In der Pipeline hab ich noch das Auslesen der TDS (in 'nem anderem Projekt) ... die DebugInfos von Windows/C++ bekomm ich problemlos über die API vom Windows (schon benutzt, um Stacktraces auszulesen, wobei ich da noch Programme wie tds2pdb dazwischen hab, wegen dem was Delphi fabriziert).

[Kas Ob.]

Zitat:

Zitat von himitsu (Beitrag 1537868)

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

With Titan Engine you can have your own prototype debugger in few hours, just build the UI.

[Kas Ob.]

One more thing about the Debugger Loop mentioned and recommended in https://learn.microsoft.com/en-gb/wi...er-s-main-loop

You can see that the full loop is already and fully taken care of in TitanEngine, including break points and threading
https://github.com/x64dbg/TitanEngin...gLoop.cpp#L513

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1537868)

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.

http://help.madshi.net/madStackTraceUnit.htm

[himitsu]

Nee nee, nicht im Programm, sondern in meinem "Debugger", von der anderen Anwendung :zwinker:
(wie im Delphi, da der Stacktrace, vom Programm)


* Grundstruktur der Grundfunktionen erstmal überlegt
* zwei "einfache" Testanwendungen gebastelt (um die Funktionen des Debuggers ausprobieren zu können)
* starten/stoppen der Testanwendung
* Prozesse auflisten (kommt heute dran)

[himitsu]

* Also, bezüglich Haltepunkten hab ich noch nichts angefangen.
* Ich kann sie empfangen, wenn sie im Zielprogramm explizit ausgelöst werden. (

Delphi-Quellcode:

BebugBreak;

oder

Delphi-Quellcode:

asm int 3 end;

)
* Haltepunkte sind "Exceptions".
* Die Detailbehandlung von Exceptions hab ich bisher nur rudimentär. (keine Detailinfos und Messages)
* beim Auslesen vom Stack bricht es immer vorher ab. (gleich nach 1 oder 3-6 Sprüngen ... mein Limit steht auf 10, aber vorher kommt schon als ReturnAddr eine 00000000 vorbei)
* Nein, es gibt noch keine Namensauflösungen im Stack, also nur die Adresse, um zu sehn, ob überhaupt was kommt. (WalkStack ... noch nicht WalkStack64 oder WalkStackEx oder ...)
* aktuell nur 32 Bit Debugger mit 32 Bit Testprogramm getestet (erstmal das zum Laufen bringen und dann weiter)

* DebugInfos auslesen und dann vielleicht Haltepunkte setzen gibt es noch nicht ... bin noch hart am Kämpfen, mit den Grundfunktionen

* Dokumentation (Microsoft) und Artikel/Tutorials sind teilweise sogar in sich schon wiedersprüclich.
* So weiß ich noch nicht welche Handles ich wann freigeben darf/soll/muß.
* Jedenfalls ist da garantiert bestimmt noch was falsch
. * wenn der Prozess endet, dann verschwindet er und teilweise sein Fenster nicht sofort (erst wenn mein DebugThread oder ganzer Debugger endet)
. * wenn ich im Debugger den Prozess oder das Debuggen auf verschiedenste Weisen beende, dann verschwindet es auch nicht
. . bin mir fast sicher, dass ich noch irgendwo ein Handle auf den Prozess/Thread offen habe und das alles festhält

* Delphi hat enorme Probleme mit dem Debuggen von Consolenanwendungen
. ich kann extrem leicht immer einen "schweren Ausnahmefehler" im Delphi-Debugger und der IDE auslösen (mit einem einfachen Programm, noch ohne selbst Debugger spielen zu wollen)
Anhang 56949
* zusammen mit Parnassus wird es noch viel extremer
* besonders auf Windows 11 mit dem Terminal knallt es am Besten ... im Gegensatz zu Windows 10 und ohne dass das neue Terminal installiert ist
> Debuggen der Konsolenanwendung starten
> in einen Haltepunkt laufen
> im angehaltenen Zustand das Konsolenfenster schließen
> nach einigen Sekunden beendet sich dann der ConsoleHost (manchmal nimmt er auch die eigene EXE mit)
> Delphi bekommt natürlich nichts mit
> wird danach dann Fortsetzen oder ein STOP im Debugger ausgeführt, war's das
. > der Debugger raucht ab und Delphi lässt sich fast nicht mehr beenden (will dabei immer den Debugger beenden, aber dabei knallt es)
. > mit viel Glück wird dann ach nichts gespeichert (der gespeicherte Desktop ist im Arsch) ... Haltepunkte und "geöffnete Dateien" werden vergessen
. > einmal war auch das ganze noch ungespeicherte Projekt weg (nichtmal __history und __recovery vorhanden) ... da die BDS aber auch garnicht mehr reagierte hatte ich noch genug Zeit für einen Snapshot (Taskmanager) und dann in den 2 GB RAM wichtige Teile geborgen ... vielen Dank an HxD (keine Lust nochmal alles zu suchen und neu machen zu müssen)



Quellcodes aktuell vielleicht auf liebe Nachfrage.



* So, hab hier auch gleich endlich mal mit dem neuen Streaming der Console gespielt, gegenüber der alten ConsoleAPI.
* das Terminal reagiert ja auch teilweise anders, gegenüber der alten Console (CMD)
. * Eingaben landen standardmäßig sofort im ECHO (Anzeige) ... mitten in der laufenden Ausgabe und nicht, wie früher, erst dann, wenn die Console/Anwendung in den Eingabemodus wechselt
. * der Curso blinkt standardmäßig immer, auch wenn nichts eingegeben werden soll
. * Markieren und Anhalten geht nicht mehr ... läuft im Hintergrund weiter und wenn Programm fertig, dann geht das Terminal auch sofort zu (egal ob noch was markiert/angehalten ist)

* wenn ich den Prozess selbst starte, inkl. Debuggen, dann erhalte ich teilweise andere Ergebnisse, als wenn ich mich an ein laufendes Programm angänge.
. * einmal immer nur EINE StackAdresse oder auch Mehrere (aber immernoch nicht genug)
. * die Namen der EXE/DLLs sind anders C:\... oder \Device\HarddiskVolume3\...

* Hier mal paar Test-Aufrufe aus dem Delphi-Projekt:
> SuperMiniDebugger.exe -process <ID>
> SuperMiniDebugger.exe -process <NAME>
> SuperMiniDebugger.exe -process <MASK>
> SuperMiniDebugger.exe -executable <FILENAME> -all
> SuperMiniDebugger.exe -executable <FILEMASK> -all
> SuperMiniDebugger.exe -demo-executable -all
> SuperMiniDebugger.exe -help
Da wird dann auch zusätzlicher DBBUG-Code in meinem Debugger genutzt. (TestApp starten und PID suchen, anstatt das jedesmal selbst machen/suchen/eingeben zu müssen)
Anhang 56947



https://github.com/microsoft/terminal
https://learn.microsoft.com/de-de/windows/terminal/
https://apps.microsoft.com/detail/9n...hl=de-de&gl=DE

Ups, ein Fehler in der Logausgabe (letzer Screenshot).
Das "-process" mit dem langen Dateiname, inkl. Pfad, müsste "-executable" heißen.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1537868)

Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Ich habe zwar immer noch nicht das große Ganze begriffen, worauf du hinaus willst, aber eine Meldung beim Durchlaufen eines Haltepunkts ohne dort wirklich anzuhalten bekommt man auch mit den Bordmitteln hin:

• Haltepunkt setzen
• Eigenschaften des Haltepunkts...
• Weitere...
• Anhalten abwählen
• Meldung protokollieren ausfüllen

Die Haltepunkte lassen sich auch in einem IDE-Plugin entsprechend setzen. Im DelphiCodeCoveragePlugin findest du ein Beispiel dazu.

[himitsu]

Funktional intern halt so, wie beim AQTime.

Allerdings (erstmal) keine Zeitmessung, sondern ein Tracing ... rückwirkend schauen was vorher und in welcher Reihenfolge gemacht wurde.
Oder einfach nur was innerhalb eines gewissen Zeitraums ausgeführt wurde, auch ohne Reihenfole.
Sowie ein Logging von Meldungen (Exceptions usw.)

Im Prinzip so, als wenn du im Delphi dauerhaft F7 drückst,
bis es irgendwo knallt oder anhält
und dann versuchst du dich zu erinnern, was vorher zuletzt für Zeilen ausgeführt wurden.
Funktionen rufen Funktionen auf -> im Stack zu sehn, aber

Code:

* Funktionsaufruf
  * weiterer Funktionsaufruf
    - usw.
      -
        - hier wird etwas Böses/Interessantes gemacht
      - end;
    - Code innerhalb gleicher Funktion/Ebene, wie das Nachfolgende
    * hier vielleicht das Except vom Try, oder einfach nur ein weiter Funktionsaufruf
      * hier bekomme ich vielleicht den Stacktrace aller/vieler * und sehe aber die - nicht mehr

Das Betrifft z.B. auch ausgelöste Events (PostMessage) aus, wo du im Event nicht wissen kannst, von wem das gekommen ist.
Beim SendMessage (innerhalb der eigenen Anwendung/Thread) müsste man es eigentlich erfahren können, aber da raucht das Auflösen vorher auch immer ab und du siehst nicht, wer das SendMessage aufgerufen hat.

[Uwe Raabe]

Damit sehe ich noch keine Anforderung, die mit den beschriebenen Bordmitteln nicht erfüllt werden kann.

Für Timing und Exceptions setze ich eher auf CodeSite anstatt Breakpoints - schon aus Performancegründen.

[Uwe Raabe]

Übrigens: Man kann im Eval-Ausdruck auch einfach einen Log-Call einsetzen.

[himitsu]

Leider knallt es gern "NUR" beim Kunden und dort hab'sch dann kein Delphi.

Auf der Todo-Liste steht aber mal, z.B. via TeamViwer ein VPN aufzubauen und dann via RemoteDebugging, aber auch das ist auch nicht immer möglich. (rechtliche und sicherheitstechnische Hindernisse)

Erstmal die besonders günstigen AQTime-Lizenzen und dann muß das Mistding
* installiert werden
* und als Admin starten



Ohne das Programm (Quellcode / EXE) selbst modifizieren zu müssen, da bietet sich ein Debugger halt an, um so von außen im Programm einiges mitbekommen zu können.

Der Debugger selbst ist "grundsätzlich" auch erstmal garnicht so das Problem.
https://learn.microsoft.com/de-de/wi...er-s-main-loop

Haltepunkte selbst sind schon möglich (durch Manipulieren des Speichers/Bytecodes) ... siehe #1
aber schön und effizient klingt das nicht und drum hatte ich hier gefragt, ob jemand mehr weiß (die Suche im Netz war halt nicht sehr ergiebig)


Im Moment hänge ich noch an ein paar Feinheiten und kämpfe mit 2-3 Problemchen / nervigen Stellchen
und bin noch nicht da hingekommen die Debuginfos zu lesen und Haltepunkte setzen zu können.

[dummzeuch]

Nur mal so am Rande bemerkt: Wenn ich mich recht erinnere, benutzt das Delphi Code Coverage Tool intern auch einen Debugger. Es setzt auf alle Codezeilen einen Breakpoint, sobald einer angesprungen wurde, wird das vermerkt (Unit + Zeilennummer) und anschließend der Breakpoint gelöscht. Das hört sich ziemlich nach dem an, was Du zu schreiben versuchst.

[Kas Ob.]

@dummzeuch, that is really nice project !
I am not familiar with it, but it looks right.

@himitsu, Well i didn't download the project yet, but i would suggest a new and novel approach for patching a process memory, myself will test it, yet can't find the time.
See, it is almost 6 PM, and a blackout is planned for 3 or 6 hours for my city, so no more Internet or PC for me today.

My suggestion is read and try this brilliant attack/approach instead of ReadProcessMemory/WriteProcessMemory
https://dtsec.us/2023-04-24-Sleep/
https://www.ired.team/offensive-secu...code-injection

I believe you can easily use NtCreateSection + NtMapViewOfSection this without the injection of course, they might yield way less overhead by simply patch the shared section, hence they might be faster than WriteProcessMemory, yet this need to be proved.

[himitsu]

Ach ja, hier im Assembler sich stundenlang durchzukämpfen
oder mit F9 und Pause zu versuchen zufällig an der "interessanten" Code stelle zu landen.
https://www.delphipraxis.net/215375-...ml#post1538125

Stattdessen könnte man auch ein Profiling oder Tracing starten und schauen wo und wie lange die meiste Zeit drauf geht, bzw. was wirklich alles gemacht wird.




Bin nochmal kurz im Baumarkt, mir bissl Holz und 'nen Kantenfräser besorgen.
Danach schau ich dann hier weiter.

Aber zuerst versuche ich mal single-threaded im ConsolenDebugger (SuperMiniDebugger) das Grundsätzliche störungsfrei zum Laufen zu bringen
und danach wird dann im VCL-basierenden Debugger (MiniDebugger) weiter gemacht und dort mit den Haltepunkten angefangen.

[himitsu]

32 Bit Debugger + 32 Bit Anwendung = joar, knallt nicht mehr so oft
64 Bit Debugger + 64 Bit Anwendung = pfffffffffff niiiijaaa
64 Bit Debugger + 32 Bit Anwendung = hier hängt noch bissl mehr (muß man an vielen Stellen bezüglich WOW64 biss was beachten ... und dann kennt Delphi hier unter 64 Bit viele der 32 Bit APIs und Records nicht)
32 Bit Debugger + 64 Bit Anwendung = das geht natürlich garnicht

Das Code Coverige nutzt die Lösung, wo überall INT 3 reingeschrieben wird
und dann wie in #1 beschrieben, wird das nach Auslösen zurückgepatcht, der InstuctionPointer -1 und dann weiter.
Das Wieder-Aktivieren des Haltepunktes sparen sie sich ... wird eh nur geloggt WAS aufgerufen wurde (nicht wie oft)

Mit dem SingleStepping hab ich Probleme.
Nach dem Auslösen müsste ich den ja wieder aktivieren,
aber leider klappt das irgendwie nicht.
-> Im ThreadContext das Trap-Flag setzen hat keine Wirkung.
* innerhalb des EXCEPTION_BREAKPOINT, bevor ContinueDebugEvent(DBG_CONTINUE)
* oder sonstwann zwischen SuspendThread und ResumeThread

EXCEPTION_BREAKPOINT wird ausgelöst,
aber egal wann und wie ich es versuche, es kommt niemals ein EXCEPTION_SINGLE_STEP.

Auch im DelphiDebugger versucht, also anhalten und dann in der CPU-Ansicht das TF-Flag aktivieren ... nach F7/F8/F9 ist keine Auswirkung zu erkennen
und in der nächsten Pause ist das TF auch wieder aus.

https://microsoft.public.win32.progr...ingle-stepping
https://www.lowlevel.eu/wiki/EFLAGS
...

Mal sehn, ob ich bei dem noch was finde.
https://www.timdbg.com/posts/symbol-indexing/

Das RIP_EVENT konnte ich auch noch nicht triggern ... also vermutlich ist es wohl wirklich tot.
https://reverseengineering.stackexch...gers-rip-event
https://learn.microsoft.com/de-de/wi...bugging-events

[Kas Ob.]

@himitsu ,

If your offer for the source still up, and the source is compilable on XE8 then i would like to have look.
Who knows, i might track and find the cause of triggering EXCEPTION_SINGLE_STEP failure, but i don't want to take from you the joy of writing/fixing it !

Away from that, please have a look here:
https://stackoverflow.com/questions/...p-all-the-time

For single step there is only two ways,
1) hardware break point approach with the debugging registers, it must handle INT1, or
2) software one with the usual trap INT3 each for each step/instruction.

In all cases, what are the values of bit 14 in DR6 and bit 12 in DR7, did you track them ?
https://en.wikipedia.org/wiki/X86_debug_register

The last answer here also is nice and detailed but it does assume single step should work out of box after INT3, but again here comes this part

Zitat:

...

Was going to paste some text above, then changed my mind, the answer is written just fine and brilliantly, need to be understood in full,

the only thing i can do, is to point where what i can guess the problem in your code:
1) You myst not confuse these

Zitat:

exceptions: vector 1 (debug exception, #DB) and vector 3 (breakpoint exception, #BP).

and their usage.
2) DB and BP mode are controlled by bit 12 in DR7
3) you can/must switch to DB after a BP, for single step so INT3 comes first then INT1 (this one is an event/signal not instruction), in other words : for single step, BP once then DB all the way afterward.

Hope that helps you with tracer.

Update : Sorry missed the link
https://stackoverflow.com/questions/...ruction-on-x86

[Kas Ob.]

Sorry !!

I missed the link :oops:
https://stackoverflow.com/questions/...ruction-on-x86

[himitsu]

Also, in den DR-Registern soll man wohl "je einen Haltepunkt" angeben können ... noch nicht probiert, aber das wären eh zu wenige

Das Trap-Flag einfach so zu setzen, hat keine Wirkung,

Delphi-Quellcode:

hMainThread := OpenThread(…, MainThreadID);
GetThreadContext(hThread, Context);
Context.EFlags := Context.EFlags or $0100;  // Trap-Flag (TF)
SetThreadContext(hThread, Context);
CloseHandle(HThread)

jedenfals nicht, wenn ich es in meinem Debugger mache (Taste [S] während des Debugging).

In der TestApp gesetzt, bzw. während eines Debug-Ereignisses, geht es,
aber bleibt dann auch irgendwann wieder aus und es stoppt. (siehe BreakPoint- oder SingeStep-Taste in der TestApp)

http://fnse.de/MiniDebugger.7z
SuperMiniDebugger.exe -demo-executable -all

PS: In der -help die DebugTasten nicht aktualisiert ... siehe Console, zu Beginn des Debuggens (hochscrollen)

[Kas Ob.]

Looks nice and working fine, though the source is not XE8 friendly due the inline variables and may be missing constants.

Question :
Why the overhead of keep opening the (a) thread and closing its handle ?!!

You have in the debugger loop an very useful events CREATE_THREAD_DEBUG_EVENT, and EXIT_THREAD_DEBUG_EVENT, so build a list or dictionary and do the open/close only once, this should help in speeding the trace.

As for the trap bit in the EFlags:
Single step is hardware generated interrupt same as hardware breakpoints, but for the single step to work these DR0-DR3 should be put to 0, in other words either you have enabled hardware breakpoints at specific addresses or single step, but not both at the same time.

May be just 0 to DR7 could be enough (zeroing all the bits) , but in my opinion the best is to clear DR0-DR3 and DR7, and think it will work every time.


ps: ran the binary and clicked on the buttons many times and couldn't see a failure.

ps2: i found this, it does confirm my recall about hardware breakpoints:
https://stackoverflow.com/questions/...p-all-the-time

[himitsu]

Zitat:

Zitat von Kas Ob. (Beitrag 1538354)

Why the overhead of keep opening the (a) thread and closing its handle ?!!

Weil WaitForDebugEventEx an diesen Stellen bloß die ThreadID liefert.

Ich finde es auch nicht wirklich schön, aber erstmal ist dieser Teil dort bloß zum Test drin
und dann abeitet hier alles noch sehr linear, ohne dass vieles zwischengespeichert wird.
* SuperMiniDebugger.dproj zum Test der Grundfunktionen
* und später im MiniDebugger.dproj dann inkl. erweitertem Handling

Ja, im Prinzip könnte man sich hier z.B. im CREATE_THREAD_DEBUG_EVENT das Handle klonen (DebugEvent.CreateThread.hThread) und bis zum EXIT_THREAD_DEBUG_EVENT aufheben.

Bzw. hier ist erstmal absichtlich noch nicht viel drin, um Dinge über längere Zeit zu behalten.
Primär wirklich erstmal nur die jeweiligen Events/Behandlungen für sich.
Daher kennen und logen die END-Events von DLL, Thread und Prozess auch keine Namen. (sie bekommen nur die ID, bzw. Adresse aus dem END-EventRecord)

[himitsu]

Weiß nicht, hab nun auch an den Debug-Registern rumgespielt, aber SingleStepping will nicht weiterlaufen.

Nja, hatte mich jetzt erstmal kurz abgelenkt und einen ersten Teil der Debuginfos erledigt.
Aus Microsoft-EXE/DLLs den Name und die GUID der PDB-Datei auslesen
und die PDB oder gewünschte Binaries von Microsofts DebugSymbol-Server downloaden.
(jetzt noch den halbangefangenen Code erledigen, um Dateinamen und Lines aus diesen Debuginfos auszulesen)

Hier gab es wenig mehr Infos und die auch noch verständlicher, auch wenn Microsoft das Format nie öffentlich dokumentiert hat ... aber bezüglich TDS dennoch einfacher.