Alle empfohlenen VC++-Einstellungen für eine bessere PDB-Analyse bei Release-Builds

Question

Gibt es irgendwelche VC++-Einstellungen, die ich kennen sollte, um bessere PDB-Dateien zu generieren, die mehr Informationen enthalten?

Ich habe ein Crash-Dump-Analysesystem basierend auf dem Projekt eingerichtet crashrpt.

Außerdem ist auf meinem Produktions-Build-Server der Quellcode auf D:\ installiert, aber auf meinem Entwicklungscomputer befindet sich der Quellcode auf C:\.Ich habe den Quellpfad in den VC++-Einstellungen eingegeben, aber wenn ich den Aufrufstapel eines Absturzes durchschaue, springt er nicht automatisch zu meinem Quellcode.Ich glaube, wenn ich den Quellcode meiner Entwicklungsmaschine auf D:\ hätte, würde es funktionieren.

Answer 1

„Gibt es irgendwelche VC++-Einstellungen, die ich kennen sollte?“

Stellen Sie sicher, dass Sie die Frame-Zeiger-Funktion deaktivieren.Larry Ostermans Blog hat die historischen Details über FPO und die Probleme, die es beim Debuggen verursacht.

Symbole wurden erfolgreich geladen.Es zeigt den Callstack, aber ein Doppelklick auf einen Eintrag bringt mich nicht zum Quellcode.

Welche VS-Version verwenden Sie?(Oder verwenden Sie Windbg?) ...In VS sollte es auf jeden Fall beim ersten Mal zur Eingabe der Quelle auffordern, wenn der Speicherort nicht gefunden wird.Es führt jedoch auch eine Liste der Quellen, die „nicht gefunden“ wurden, sodass Sie nicht jedes Mal danach gefragt werden.Manchmal ist die Nicht-Look-Liste eine Qual ...Um die Eingabeaufforderung wiederherzustellen, müssen Sie zu Lösungs-Explorer/Lösungsknoten/Eigenschaften/Debug-Eigenschaften gehen und die Dateiliste im unteren Bereich bearbeiten.

Schließlich verwenden Sie möglicherweise „entfernte Symbole“.Hierbei handelt es sich um PDB-Dateien, die generiert werden, um Debug-Informationen für das Durchlaufen des Callstacks über FPO hinaus bereitzustellen, wobei jedoch die Quellspeicherorte entfernt wurden (zusammen mit anderen Daten).Die öffentlichen Symbole für Windows-Betriebssystemkomponenten sind gestrippte PDBS.Für Ihren eigenen Code verursachen diese einfach Schmerzen und lohnen sich nicht, es sei denn, Sie stellen Ihre PDBs externen Benutzern zur Verfügung.Wie würden Sie eines dieser schrecklichen entkleideten PDBs haben?Möglicherweise erhalten Sie sie, wenn Sie „binplace“ mit dem Befehl -a verwenden.

Viel Glück!Eine richtige Mini-Dump-Story ist ein Glücksfall für das Produktions-Debugging.

Answer 2

Wenn Sie direkt aus Ihrem Quellcode-Verwaltungssystem erstellen, sollten Sie Ihre PDF-Dateien mit den Dateiursprüngen versehen.Dadurch können Sie beim Debuggen automatisch die genauen Quelldateien abrufen.(Dies ist derselbe Vorgang, der zum Abrufen des .Net-Framework-Quellcodes verwendet wird).

Sehen http://msdn.microsoft.com/en-us/magazine/cc163563.aspx für mehr Informationen.Wenn Sie Subversion als SCM verwenden, können Sie sich das SourceServerSharp-Projekt ansehen.

Answer 3

Sie könnten es mit MS-DOS versuchen subst Befehl zum Zuweisen Ihres Quellcodeverzeichnisses zum D:fahren.

Answer 4

Dies ist das Verfahren, das ich nach einigen ähnlichen Problemen wie Ihrem verwendet habe:

a) Alle erstellten EXE- und DLL-Dateien wurden auf den Produktionsserver kopiert, jeweils mit der entsprechenden PDB im selben Verzeichnis, das System gestartet und auf den Absturz gewartet.

b) Alle EXE-, DLL- und PDB-Dateien zusammen mit dem Minidump (im selben Ordner) auf den Entwicklungscomputer (in einen temporären Ordner) zurückkopiert.Habe Visual Studio verwendet, um den Minidump aus diesem Ordner zu laden.

Da VS die Quelldateien dort fand, wo sie ursprünglich kompiliert wurden, konnte es sie immer identifizieren und korrekt laden.Wie bei Ihnen war das verwendete Laufwerk in der Produktionsmaschine nicht C:, in der Entwicklungsmaschine jedoch schon.

Noch zwei Tipps:

• Eine Sache, die ich oft gemacht habe, war, eine neu erstellte EXE/DLL zu kopieren und zu vergessen, die neue PDB zu kopieren.Dadurch wurde der Debug-Zyklus ruiniert, VS konnte mir den Aufrufstapel nicht anzeigen.

• Manchmal bekam ich einen Aufrufstapel, der in VS keinen Sinn ergab.Nach einigem Kopfzerbrechen stellte ich fest, dass windbg mir immer den richtigen Stack anzeigte, VS jedoch oft nicht.Ich weiß nicht warum.

Answer 5

Falls es jemanden interessiert, ein Kollege hat mir per E-Mail auf diese Frage geantwortet:

Artem schrieb:

MinidumpwritedUpN () gibt es eine Flagge, die bessere Crash -Dumps durchführen kann, die es ermöglichen, den vollständigen Programmstatus mit allen globalen Variablen usw. zu sehen.Ich bezweifle, dass sie aufgrund von Optimierungen besser sein können ...Es sei denn, Sie schalten (vielleicht einige) Optimierungen aus.

Ich denke auch, dass die Deaktivierung von Inline -Funktionen und die gesamte Programmoptimierung viel helfen werden.

Tatsächlich gibt es viele Dump -Typen, vielleicht könnten Sie eine kleine genug wählen, aber immer noch mehr Informationen haben http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Diese Typen helfen jedoch nicht bei Call Stack, sie beeinflussen nur die Anzahl der Variablen, die Sie sehen können.

Ich habe festgestellt, dass einige dieser Dump -Typen in dbgHelp.dll Version 5.1, die wir verwenden, nicht unterstützt werden.Wir könnten es auf die neueste 6.9 -Version aktualisieren. Ich habe gerade die EULA für MS -Debugging -Tools überprüft - die neueste DBGHelp.dll ist immer noch in Ordnung, um neu zu verteilen.

Answer 6

Fordert Visual Studio Sie zur Eingabe des Pfads zur Quelldatei auf?Wenn dies nicht der Fall ist, geht es davon aus, dass es keine Symbole für den Callstack gibt.Das Festlegen des Quellpfads sollte funktionieren, ohne dass der genaue ursprüngliche Speicherort zugeordnet werden muss.

Sie können erkennen, ob Symbole geladen sind, indem Sie sich das Fenster „Module“ in Visual Studio ansehen.

Angenommen, Sie erstellen eine PDB, dann gibt es meines Erachtens keine Optionen, die die Informationsmenge in der PDB direkt steuern.Sie können die Art der vom Compiler durchgeführten Optimierungen ändern, um die Debug-Fähigkeit zu verbessern. Dies geht jedoch auf Kosten der Leistung. Wie Ihr Kollege betont, trägt die Deaktivierung von Inline dazu bei, die Dinge in der Absturzdatei deutlicher zu machen, verursacht jedoch zur Laufzeit Kosten.

Abhängig von der Art Ihrer Anwendung würde ich empfehlen, wenn möglich mit vollständigen Dump-Dateien zu arbeiten. Diese sind größer, geben Ihnen aber alle Informationen über den Prozess ...und wie oft stürzt es überhaupt ab :)

Answer 7

Veranlasst Visual Studio Sie für den Pfad zur Quelldatei?

NEIN.

Wenn dies nicht der Fall ist, glaubt es nicht, dass es Symbole für den CallStack hat.Das Festlegen des Quellpfads sollte funktionieren, ohne den genauen ursprünglichen Ort abzuordnen zu müssen.

Symbole wurden erfolgreich geladen.Es zeigt den Callstack, aber ein Doppelklick auf einen Eintrag bringt mich nicht zum Quellcode.Ich kann natürlich in Dateien nach der betreffenden Zeile suchen, aber das ist harte Arbeit :)