Wer von Euch kennt das Problem: Der Kunde hat ein Absturz oder einen Hänger Deines Programmes. Das einzige was Du bekommst ist ein Dump-File (z.B. entweder via WER oder durch eigenes schreiben von MiniDumpWriteDump).
Jetzt beginnt für Dich das Problem:
- Welche Version hat der Kunde?
- Welche Source-Files brauche ich für diese Version?
- Wo zum teu.. sind nochmals die passenden PDBs und EXEn für diese Version?
Mit diesem Fragen braucht man sich nicht beschäftigen, wenn man bei seinem Build Prozess noch zusätzlich zwei Dinge einbaut
- Source-Indexing
- Symbols-Store
Source-Indexing (mit dem TFS)
Source-Indexing sorgt dafür, dass in die Debug-Symole (PDB-Dateien) auch zusätzlich noch ein verweis auf die richtige TFS-Version eingefügt wird. Dadurch kann der Debugger (z.B. VS) man mit der PDB-Datei genau den passenden Source aus dem TFS holen, mit dem die DLL/EXE gebuildet wurde.
Um dies zu machen braucht man zwei Dinge: “Debugging Tools For Windows” und “ActivePerl“). Das Source-Indexing findet sich bei den Debugging Tools im Unterverzeichnis “srcsrv” (also z.B. C:\Program Files\Debugging Tools for Windows\srcsrv). Da die “Skripts” (leider) in Perl geschrieben sind, ist auch noch ActivePerl notwendig. Es reicht aber, wenn man die ZIP-Datei runterlädt und vor dem Aufruf einfach den Pfad auch noch auf das entpackte ActivePerl setzt.
Damit beim Source-Indexing auch der korrekte TFS-Server verwendet wird, muss man in der Datei “srcsrv.ini” die Zeile mit “MYSERVER” auf den richtigen TSF zeigen lassen.
MYSERVER=http://my-tfs-machine:8080
Jetzt muss man nach einen Build nur noch das Source-Indexing aufrufen und angeben, wo denn der Workstore und die PDBs liegen. Ich gebe der Einfachheithalber immer den Root aller Projekte an, welche ich gebuildet habe. Die Natchdatei sieht dann z.B. so aus (es kann auch direkt als eigenes Task in msbuild laufen):
rem Merke mit mal den aktuellen Pfad, was die Root meiner Projekte und Ausgabe ist
set srvOrgDir=%CD%
rem Setze den pfad auch zu dem Perl Zeugs...
path=%path%;"%CD%\Tools\srcsrv\ActivePerl-5.10.1.1006-MSWin32-x86-291086\perl\bin"
rem Wechsle in das Verzeichnis wo die Source-Indexing Tools liegen (liegt bei mir auch im TFS)
cd .\Tools\srcsrv
rem Rufe das Source-Indexing auf
call tfsindex.cmd -ALLROOT="%srvOrgDir%"
rem Setze wieder den ursprünglichen Pfad
cd /D %srvOrgDir%
Alternativ kann man natürlich auch das srcsrv-Verzeichnis im TFS ablegen (so hab ich es gemacht), dann muss man nicht sicherstellen, dass man auf dem Build-Rechner auch die Debugging-Tools installiert hat.
Jetzt sollten nach einem Build alle PDB-Dateien mit der korrekten TFS-Version indiziert worden sein (dies erkennt man daran, dass ziemlich weit hinten in der PDB-Datei Einträge mit “MYSERVER” kommen…; kann man z.B. in Notepad anschauen).
Symbol-Store
Oben haben wir jetzt die PDB-Dateien mit dem passenden Verweis auf den TFS ausgestattet. Jetzt müssen wir nur noch sicherstellen, dass wir zu einem beliebigen späteren Zeitpunkt nicht mehr nach dieser PDB-Datei (und den dazugehörigen EXEn) suchen müssen. Dies geschieht am einfachsten mit dem “symstore” aus den Debugging Tools for Windows. Dies speichert einfach alle PDBs/EXEn in ein Verzeichnis (am besten ein Netzwerkverzeichnis, wenn es später mehrere Verwenden wollen).
Das ablegen erfolgt dann ganz Simple durch:
.\Tools\SymStore\Symstore.exe add /r /f .\*.* /s G:\MyProject\SymbolStore\Files /t "Project Name"
Das war alles 😉
Einstellungen in VS
Ok, fast… denn man will das ganze ja auch noch verwenden… dazu muss man in VS noch ein paar Einstellungen machen, da per default der “Source-Server” deaktiviert ist. Dies muss aktiviert werden:
Jetzt muss man noch den Pfad zu den zuvor abgelegten Dateien eintragen:
Bekommt man jetzt ein Dump oder will in dieser EXE/DLL debuggen, so werden die Sourcen direkt vom TFS geholt (und in einem temporären Verzeichnis gespeichert) und man kann dies dann direkt debuggen.
Ich hoffe, dass hilft dem ein oder anderen.
PS: Beide Verfahren werden übrigens auch intern von Microsoft schon sehr lange eingesetzt (deswegen auch das Source-Indexing in Perl; PowerShell gab es damals noch nicht). Die gesamten Windows Sourcen sind so indiziert und (der wer darf 😉 ) können dann via CCP die passenden indizierten PDB-Dateien abgefragt werden, welche dann z.B: in VS/WinDbg die passenden Source runterlädt.
PPS: Wer das ganze noch für SubVersion haben will, kann es bei Stefan nachlesen:
Source Server und Symbol Server Setup mit Subversion
