Debuggen mit Symbolen

  • Artikel

Dieser Artikel bietet eine allgemeine Übersicht über die optimale Verwendung von Symbolen in Ihrem Debuggingprozess. Es wird erläutert, wie Sie den Microsoft-Symbolserver verwenden und wie Sie Ihren eigenen privaten Symbolserver einrichten und verwenden. Diese bewährten Methoden können dazu beitragen, Ihre Effektivität zu erhöhen und Fehler zu debuggen (auch in Fällen, in denen sich alle Symbole und ausführbaren Dateien, die mit einem Problem in Zusammenhang stehen, nicht auf Ihrem Computer befinden).

Sonderzeichen

Für das Debuggen stehen verschiedene Arten von Symbolen zur Verfügung. Dazu gehören neben CodeView-Symbolen auch COFF-, DBG-, SYM- und PDB-Dateien und sogar Exportsymbole, die aus einer Exporttabelle für Binärdateien generiert werden. In diesem Whitepaper werden nur VS.NET- und die PDB-Formatsymbole erläutert, da sie dem neuesten bevorzugten Format entsprechen. Sie werden standardmäßig für Projekte generiert, die mithilfe von Visual Studio kompiliert werden.

Das Generieren von PDB-Dateien für ausführbare Releasedateien wirkt sich nicht auf Optimierungen aus, und auch die Größe der generierten Dateien wird nicht erheblich geändert. Normalerweise ist der einzige Unterschied der Pfad, und der Dateiname der PDB-Datei ist in die ausführbare Datei eingebettet. Aus diesem Grund sollten Sie immer PDB-Dateien erstellen, auch wenn Sie sie nicht mit der ausführbaren Datei bereitstellen möchten.

PDB-Dateien werden generiert, wenn ein Projekt mit der Compileroption /Zi bzw. /ZI (Generieren von PDB-Informationen) und der Linkeroption /DBEUG (Generieren von Debuginformationen) verwendet wird. Die vom Compiler generierten PDB-Dateien werden kombiniert und in eine einzelne PDB-Datei geschrieben, die in demselben Verzeichnis wie die ausführbare Datei abgelegt wird.

Standardmäßig enthalten PDB-Dateien die folgenden Informationen:

  • Öffentliche Symbole (in der Regel alle Funktionen, statische und globale Variablen)
  • Eine Liste der Objektdateien, die für Codeabschnitte in der ausführbaren Datei verantwortlich sind
  • Informationen zur Framezeigeroptimierung (Frame Pointer Optimization, FPO)
  • Name und Typinformationen für lokale Variablen und Datenstrukturen
  • Quelldatei- und Zeilennummerinformationen

Wenn Sie besorgt sind, dass Benutzer*innen die PDB-Dateiinformationen für das Reverse Engineering im Zusammenhang mit Ihrer ausführbaren Datei verwenden, können Sie mithilfe der Linkeroption /PDBSTRIPPED:filename auch gestrippte PDB-Dateien generieren. Wenn Sie über vorhandene PDB-Dateien verfügen, aus denen Sie persönliche Informationen entfernen möchten, können Sie ein Tool namens „pdbcopy“ verwenden, das Teil der Debugtools für Windows ist.

Gestrippte PDB-Dateien enthalten standardmäßig die folgenden Informationen:

  • Öffentliche Symbole (in der Regel nur nicht statische Funktionen und globale Variablen)
  • Eine Liste der Objektdateien, die für Codeabschnitte in der ausführbaren Datei verantwortlich sind
  • Informationen zur Framezeigeroptimierung (Frame Pointer Optimization, FPO)

Dies sind die Mindestinformationen, die für ein zuverlässiges Debuggen erforderlich sind. Die Mindestinformationen machen es auch schwierig, zusätzliche Informationen zu Ihrem ursprünglichen Quellcode zu erhalten. Da sowohl eine gestrippte als auch eine normale PDB-Datei generiert wird, können Sie die gestrippte Version für Benutzer*innen bereitstellen, die möglicherweise eingeschränkte Debugfunktionen benötigen. Die vollständigen PDBs bleiben vertraulich. Beachten Sie, dass /PDBSTRIPPED eine zweite, kleinere PDB-Datei generiert. Stellen Sie daher sicher, dass Sie beim Generieren von Builds für die breite Verteilung die richtige PDB-Datei verwenden. Bei einem typischen Projekt kann eine herkömmliche PDB-Datei ein paar Megabyte groß sein, aber die gestrippte Version der PDB-Datei kann nur ein paar Hundert Kilobyte umfassen.

Verwenden von Symbolen für das Debuggen

Wenn Sie eine abgestürzte Anwendung debuggen, versucht der Debugger, Ihnen die Funktionen im Stapel anzuzeigen, die zum Absturz geführt haben. Ohne eine PDB-Datei kann der Debugger die Funktionsnamen, deren Parameter oder die im Stapel gespeicherten lokalen Variablen nicht auflösen. Wenn Sie ausführbare 32-Bit-Dateien debuggen, gibt es Situationen, in denen keine zuverlässige Stapelüberwachung ohne Symbole möglich ist. Manchmal ist es möglich, die Rohwerte im Stapel zu überprüfen und zu ermitteln, welche Werte möglicherweise Absenderadressen sind. Diese können jedoch leicht mit Funktionsverweisen oder Daten verwechselt werden.

Wenn Funktionen im aktuellen Stapel mithilfe der /Oy-Optimierung zum Unterdrücken von Framezeigern kompiliert wurden und keine Symbole vorhanden sind, kann der Debugger nicht zuverlässig bestimmen, welche Funktion die aktuelle Funktion aufgerufen hat. Dies liegt daran, dass der Debugger ohne die in den PDBs enthaltenen Informationen für die Framezeigeroptimierung (Frame Pointer Optimization, FPO) nicht auf das Framezeigerregister (EBP) zurückgreifen kann, um auf den gespeicherten vorherigen Framezeiger und die Absenderadresse der übergeordneten Funktion zu zeigen. Stattdessen wird geraten. Manchmal wird das richtige Element ausgewählt. Oft wird jedoch ein falsches Element verwendet, was irreführend sein kann. Wenn wie im folgenden Beispiel eine Warnung zu fehlenden oder nicht geladenen Symbolen angezeigt wird, ist der Stapel ab diesem Punkt nicht mehr vertrauenswürdig.

SWPerfTest.exe!TextFunction(... ...)    Line 59    C++
d3dx9d.dll!008829b5()
[Frames below may be incorrect and/or missing, no symbols loaded for d3dx9d.dll]
SWPerfTest.exe!main(int argc=, const char * * argv=)  Line 328 + 0x12 bytes     C++
SWPerfTest.exe!__mainCRTStartup() Line 716 + 0x17 bytes    C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x27 bytes

In vielen Fällen ist es möglich, das Debuggen ohne Symbole fortzusetzen, da das Problem an einer Stelle auftritt, an der genaue Symbole vorhanden sind, und Sie müssen die Funktionen weiter unten im Aufrufstapel nicht überprüfen. Auch wenn eine Bibliothek in Ihrem Aufrufstapel keine PDBs umfasst, sollte der Debugger in der Lage sein, die übergeordneten Funktionen richtig zu erraten, solange die PDBs mit Framezeigern kompiliert wurden. Ab Windows XP Service Pack 2 werden alle Windows-DLL-Dateien und ausführbaren Dateien mit deaktivierter FPO kompiliert, da diese das Debuggen präziser macht. Durch das Deaktivieren der FPO können Samplingprofiler den Stapel während der Laufzeit mit minimalen Leistungseinbußen durchlaufen. Bei Windows-Versionen vor Windows XP SP2 benötigen alle Betriebssystem-Binärdateien übereinstimmende Symboldateien, die FPO-Informationen enthalten, um ein präzises Debuggen und eine genaue Profilerstellung zu ermöglichen.

Wenn Sie native ausführbare 64-Bit-Dateien debuggen, sind keine Symboldateien erforderlich, um eine gültige Stapelüberwachung zu ermöglichen, da x64-Betriebssysteme und Compiler so konzipiert sind, dass sie diese nicht benötigen. Sie benötigen jedoch weiterhin Symboldateien, um die Funktionsnamen, Aufrufparameter und lokale Variablen abzurufen.

In einigen Fällen kann es jedoch besonders schwierig sein, ohne Symbole zu debuggen. Wenn Sie beispielsweise ein Programm debuggen, für das Sie eine PDB-Datei erstellt haben, und das Programm bei einem Rückruf über eine Funktion in einer DLL abstürzt, für die Sie über keine Symbole verfügen, können Sie nicht anzeigen, welche Funktion den Rückruf verursacht hat, da Sie den Stapel nicht decodieren können. Dies geschieht häufig bei Drittanbieterbibliotheken, wenn PDBs nicht bereitgestellt werden, oder bei alten Betriebssystemkomponenten, wenn PDBs nicht verfügbar sind. Rückrufe treten häufig während der Nachrichtenübergabe, Enumeration, Speicherzuweisung oder Ausnahmebehandlung auf. Das Debuggen dieser Funktionen ohne einen bestimmten Stapel kann frustrierend sein.

Um Mini-Absturzabbilder zuverlässig zu debuggen, die auf einem anderen Computer generiert werden oder die im Zusammenhang mit Code abgestürzt sind, den Sie nicht besitzen, ist es wichtig, auf alle Symbole und Binärdateien für die ausführbaren Dateien zugreifen zu können, auf die im Mini-Absturzabbild verwiesen wird. Wenn die Symbole und Binärdateien über einen Symbolserver verfügbar sind, werden sie automatisch vom Debugger abgerufen. Weitere Informationen zu Mini-Absturzabbildern finden Sie im Whitepaper zur Absturzabbildanalyse.

Abrufen der benötigten Symbole

Visual Studio und andere Microsoft-Debugger (z. B. WinDbg) sind in der Regel so eingerichtet, dass sie nur funktionieren, wenn Sie eine Anwendung erstellen und auf Ihrem eigenen Computer debuggen. Wenn Sie Ihre ausführbare Datei für eine andere Person bereitstellen müssen, über mehrere Versionen einer DLL oder einer EXE-Datei auf Ihrem Computer verfügen oder eine Anwendung präzise debuggen möchten, die Windows oder andere Bibliotheken wie DirectX verwendet, müssen Sie verstehen, wie Debugger Symbole suchen und laden. Der Debugger verwendet entweder den von den Benutzer*innen angegebenen Symbolsuchpfad (befindet sich in Visual Studio unter „Options\Debugging\Symbols“) oder die Umgebungsvariable „_NT_SYMBOL_PATH“. In der Regel sucht der Debugger an den folgenden Speicherorten nach übereinstimmenden PDBs:

  • Der Speicherort, der in der DLL-Datei oder der ausführbaren Datei angegeben ist.

    Wenn Sie eine DLL oder eine ausführbare Datei auf Ihrem Computer erstellt haben, platziert der Linker standardmäßig den vollständigen Pfad und den Dateinamen der zugeordneten PDB-Datei in der DLL oder der ausführbaren Datei. Beim Debuggen überprüft der Debugger zunächst, ob die Symboldatei an dem Speicherort vorhanden ist, der innerhalb der DLL oder der ausführbaren Datei angegeben ist. Dies ist hilfreich, da immer Symbole für Code zur Verfügung stehen, den Sie auf Ihrem Computer kompiliert haben.

  • PDBs, die sich möglicherweise im selben Ordner befinden wie die DLL-Datei oder die ausführbare Datei

  • Alle lokalen Symbolcache-Ordner.

  • Alle Symbolserver für Dateifreigaben im lokalen Netzwerk

  • Alle Internetsymbolserver (z. B. der Microsoft-Symbolserver)

Um sicherzustellen, dass Sie über alle PDBs verfügen, die Sie für das präzise Debuggen benötigen, installieren Sie die Debugtools für Windows. Die 32- und 64-Bit-Versionen finden Sie unter Debugtools für Windows.

Ein nützliches Tool, das mit diesem Paket installiert wird, ist symchk.exe. Es kann dabei helfen, fehlende oder falsche Symbole zu identifizieren. Dieses Tool verfügt über eine große Anzahl potenzieller Befehlszeilenoptionen. Im Folgenden werden zwei der nützlicheren und häufig verwendeten Optionen erläutert.

Überprüfen, ob eine bestimmte DLL- oder EXE-Datei und eine PDB-Datei in demselben Ordner übereinstimmen

"c:\Program Files\Debugging Tools for Windows\symchk" testing.dll /s .

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

Die Option /s . weist symchk an, nur im aktuellen Ordner und nicht auf Symbolservern nach Symbolen zu suchen.

Überprüfen, ob alle DLLs und ausführbaren Dateien in den Ordnern übereinstimmende PDBs aufweisen

"c:\Program Files\Debugging Tools for Windows\symchk" *.* /r

Mit der Option /r wird symchk angewiesen, Ordner rekursiv zu durchlaufen, um zu überprüfen, ob alle ausführbaren Dateien übereinstimmende PDBs aufweisen. Ohne die Option /s verwendet symchk die aktuelle _NT_SYMBOL_PATH-Variable, um auf einem privaten oder lokalen Server oder auf den Microsoft-Symbolservern nach Symbolen zu suchen. Das symchk-Tool sucht nur nach Symbolen für ausführbare Dateien (z. B. EXE- und DLL-Dateien). Sie können keine Platzhaltersuchvorgänge für Symbole für nicht ausführbare Dateien verwenden.

Funktionsweise von symchk

Wenn der Linker DLL-Dateien, ausführbare Dateien und PDB-Dateien generiert, werden in jeder Datei identische GUIDs gespeichert. Die GUID wird von Tools verwendet, um festzustellen, ob eine bestimmte PDB-Datei mit einer DLL-Datei oder einer ausführbaren Datei übereinstimmt. Wenn Sie eine DLL-Datei oder eine ausführbare Datei ändern, indem Sie einen Ressourcen-Editor oder eine Kopierschutzcodierung verwenden oder die Versionsinformationen ändern, wird die GUID aktualisiert, und der Debugger kann die PDB-Datei nicht laden. Aus diesem Grund ist es sehr wichtig, eine Bearbeitung der DLL-Datei oder der ausführbaren Datei zu vermeiden, nachdem sie vom Linker erstellt wurde.

Sie können auch das im Lieferumfang von VS.NET enthaltene DUMPBIN-Hilfsprogramm verwenden, um die gesuchten Symbolpfade anzuzeigen und festzustellen, ob Symboldateien gefunden werden, die einer bestimmten DLL-Datei oder ausführbaren Datei entsprechen. Beispiel:

DUMPBIN /PDBPATH:VERBOSE filename.exe

Symbolserver

Ein Symbolserver ist ein Repository für mehrere Versionen von ausführbaren Dateien und Symboldateien. Es enthält entweder die Symboldateien selbst oder Zeiger auf die zugehörigen Symboldateien. Debugger wissen, wie sie Symbolserver nutzen können und verwenden sie, um nach fehlenden oder unbekannten Symbolen zu suchen.

DLL-Dateien und ausführbare Dateien sind auch über den Microsoft-Symbolserver verfügbar. Dies ermöglicht es, Abstürze zu debuggen und Code für Betriebssystemdateien zu untersuchen, die möglicherweise nicht auf Ihrem Computer vorhanden sind. Wenn ein Debugger auf eine ausführbare Datei oder eine DLL-Datei stößt, die nicht auf dem System vorhanden ist, das Sie zum Debuggen verwenden, fordert er automatisch sowohl die Symbole als auch eine Kopie der Binärdatei von den Microsoft-Symbolservern an. Dies ist hilfreich, wenn Sie eine Komponente debuggen, die viele Versionen aufweist (z. B. msvcrt.dll), und Sie den Code auf eine Version untersuchen müssen, die auf Ihrem Computer nicht vorhanden ist. Dies hilft auch beim Debuggen von Mini-Absturzabbildern, die auf einem Betriebssystem generiert werden, das sich von dem System unterscheidet, das Sie für das Debuggen verwenden.

Microsoft veröffentlicht alle PDB-Dateien für alle Betriebssysteme und andere weiterverteilte Komponenten (z. B. das DirectX-SDK) auf dem extern zugänglichen Symbolserver. Dies erleichtert das Debuggen einer Anwendung, die diese DLL-Dateien oder ausführbaren Dateien verwendet. Sie können den Microsoft-Symbolserver verwenden, um Symbole zusammen mit allen lokalen Symbolen für Komponenten aufzulösen, die auf Ihrem Computer erstellt wurden.

Sie können Ihren Computer so einrichten, dass er den Microsoft-Symbolserver verwendet, der Ihnen Zugriff auf alle Microsoft-Symboldateien gewährt. Sie können auch einen privaten Symbolserver für Ihr Unternehmen, Ihr Team oder Netzwerk einrichten, mit dem mehrere ältere Versionen eines Projekts gespeichert werden können, an dem Sie arbeiten. Zudem können Sie einen lokalen Cache für die Symbole bereitstellen, die Sie vom Microsoft-Symbolserver verwenden.

Um einen Symbolserver zu verwenden, geben Sie den Suchpfad in der Umgebungsvariablen „_NT_SYMBOL_PATH“ an. Debugger und moderne Tools wie WinDbg, NTSD oder Visual Studio verwenden diesen Pfad automatisch, um nach Symbolen zu suchen.

Wenn ein Debugger nach Symbolen sucht, sucht er zuerst lokal nach Symbolen. Anschließend sucht er auf Symbolservern nach Symbolen. Wenn ein übereinstimmende Symbol gefunden wird, überträgt er die Symboldatei in Ihren lokalen Cache. Die Symbole für eine typische DLL-Datei bzw. ausführbare Datei reichen hinsichtlich der Größe von 1 bis 100 MB. Wenn Sie einen Prozess debuggen, der viele DLLs enthält, kann es daher einige Zeit dauern, alle Symbole aufzulösen und in einen lokalen Cache zu übertragen.

Verwenden des Microsoft-Symbolservers

Mit dem Microsoft-Symbolserver können Sie die neuesten Symbole abrufen (einschließlich der Symbole für gepatchte oder aktualisierte Dateien). Der Microsoft-Symbolserver ist unter https://msdl.microsoft.com/download/symbols verfügbar.

Sie haben die folgenden Möglichkeiten, um auf den Symbolserver zuzugreifen:

  • Geben Sie die Serveradresse direkt ein. Klicken Sie in Visual Studio im Menü Extras zunächst auf Optionen, wählen Sie Debuggen aus, und klicken Sie dann auf Symbole.

  • Verwenden Sie die Umgebungsvariable „_NT_SYMBOL_PATH“. Diese Methode wird empfohlen.

    Diese wird von allen Debugtools verwendet. Sie wird auch von Visual Studio verwendet und beim Öffnen von Visual Studio gelesen und decodiert. Aus diesem Grund müssen Sie Visual Studio neu starten, wenn Sie Änderungen vorgenommen haben.

    Mit dieser Umgebungsvariablen können Sie mehrere Symbolserver angeben (z. B. einen internen privaten Symbolserver). Außerdem können Sie ein lokales Cacheverzeichnis angeben, um PDBs für alle Symbole zu speichern, die Sie über Symbolserver gesucht haben (sowohl intern als auch über das Internet).

Die Syntax für die _NT_SYMBOL_PATH-Variable lautet wie folgt:

srv*[local cache]*[private symbol server]*https://msdl.microsoft.com/download/symbols

Ersetzen Sie [local cache] durch den Namen eines Verzeichnisses auf Ihrem Computer, in dem Sie einen Cache aller verwendeten Symbole speichern möchten (z. B. „%SYSTEMROOT%\Symbols“ oder „c:\symbols“).

Die Angabe für [private symbol server] ist optional. Sie kann auf einen Symbolserver verweisen, der sich in Ihrem Netzwerk befindet. Es ist jedoch auch möglich, dass auf einen Symbolserver verwiesen wird, der von Ihrem Team, Ihrer Produktgruppe oder Ihrem Unternehmen gemeinsam genutzt wird.

Wenn Sie nur den Microsoft-Symbolserver zusammen mit einem lokalen Cache von Symbolen verwenden möchten, um den Zugriff über das Internet zu beschleunigen, verwenden Sie die folgende Einstellung für „_NT_SYMBOL_PATH“:

srv*c:\symbols*https://msdl.microsoft.com/download/symbols

Weitere Optionen für die _NT_SYMBOL_PATH-Variable finden Sie in der Hilfedatei, die mit dem Microsoft Debugging Tools-Paket für Windows installiert wird.

Ausführbare Dateien ohne Symbole können bei Verwendung eines Symbolservers dazu führen, dass das Starten eines Debuggers länger dauert. Dies liegt daran, dass der Debugger bei jedem Versuch, die ausführbare Datei zu laden, den Symbolserver abfragt. Aus diesem Grund empfiehlt es sich, immer Symbole für alle Komponenten anzufordern.

Es ist ggf. nicht möglich, Symbole für jede Komponente anzufordern. Beispielsweise verfügen Videotreiber möglicherweise über DLLs in Ihrem Prozessbereich, und die erforderlichen PDB-Dateien sind auf dem Microsoft-Symbolserver verfügbar. In diesem Fall gibt es eine kleine Verzögerung, wenn Sie eine Debugsitzung starten.

Wenn Sie selbst diese kleine Verzögerung vermeiden möchten, können Sie den Debugger einmal ausführen, um alle Symbole lokal vom Microsoft-Symbolserver zwischenzuspeichern. Ändern Sie dann die _NT_SYMBOL_PATH-Variable, um den Microsoft-Symbolserver zu entfernen. Sofern sich die ausführbaren Dateien nicht ändern, ist bei der Überprüfung auf ausführbare Dateien ohne Symbole keine Abfrage über das Internet erforderlich, da Sie über lokal zwischengespeicherte Kopien aller Symbole verfügen, die Sie vom Microsoft-Symbolserver benötigen.

Manuelles Abrufen von Symbolen

Wenn Sie den Debugger ordnungsgemäß eingerichtet haben, lädt er automatisch alle Symbole, die er aus dem lokalen Cache oder von einem Symbolserver benötigt. Wenn Sie die Symbole nur für eine einzelne ausführbare Datei oder für einen Ordner mit ausführbaren Dateien abrufen möchten, können Sie symchk verwenden. Wenn Sie beispielsweise die Symbole für die Datei „d3dx9_30.dll“ im Windows-Systemordner in das aktuelle Verzeichnis herunterladen möchten, können Sie den folgenden Befehl verwenden:

"c:\Program Files\Debugging Tools for Windows\symchk" c:\Windows\System32\d3dx9_30.dll /oc \.

Das symchk-Tool bietet viele andere Verwendungsmöglichkeiten. Weitere Informationen finden Sie unter symchk oder in der Microsoft Debugging Tools-Dokumentation für Windows.

Einrichten eines Symbolservers

Das Einrichten eines Symbolservers ist sehr einfach. Symbolserver sind aus den folgenden Gründen nützlich:

  • Sie können Bandbreite sparen und die Symbolauflösung für Ihr Unternehmen, Team oder Produkt beschleunigen: Bei einem internen Symbolserver für eine lokale Dateifreigabe in Ihrem Netzwerk werden alle Verweise auf externe Symbolserver (z. B. auf den Microsoft-Symbolserver) zwischengespeichert. Viele Personen können gleichzeitig auf einen lokalen oder internen Symbolserver zugreifen. Daher wird Bandbreite und Latenz gespart, die doppelte Symbolanforderungen verursachen können.
  • Sie können Symbole für alte Builds, Versionen oder externe Releases Ihrer Anwendung speichern: Wenn Sie die Symbole für diese Builds auf einem Symbolserver speichern, auf den Sie problemlos zugreifen können, können Sie Abstürze und Fehler in diesen Builds auf jedem Computer debuggen, auf dem ein Debugger verfügbar ist und eine Verbindung mit dem lokalen Symbolserver besteht. Dies ist besonders hilfreich, wenn Sie Mini-Absturzabbilder debuggen, die von ausführbaren Dateien generiert werden, die Sie selbst nicht erstellt haben (d. h. Builds, die von anderen Programmierer*innen oder von einem Buildcomputer generiert wurden). Wenn die Symbole für diese Builds auf Ihrem Symbolserver gespeichert sind, können Sie zuverlässig und präzise debuggen.
  • Sie können Symbole auf dem neuesten Stand halten: Wenn Komponenten aktualisiert werden (z. B. Betriebssystemkomponenten, die von Windows Update oder vom DirectX-SDK geändert werden), können Sie trotzdem mithilfe der neuesten Symbole debuggen.

Das Einrichten eines Symbolservers in Ihrem eigenen lokalen Netzwerk ist so einfach wie das Erstellen einer Dateifreigabe auf einem Server und das Erteilen vollständiger Berechtigungen für den Zugriff auf die Freigabe zum Erstellen von Dateien und Ordnern. Diese Freigabe sollte unter einem Serverbetriebssystem wie Windows Server 2003 erstellt werden, damit die Anzahl der Personen nicht beschränkt ist, die gleichzeitig auf die Freigabe zugreifen können.

Wenn Sie beispielsweise eine Dateifreigabe über das Verzeichnis „\\mainserver\symbols“ einrichten, legen die Mitglieder Ihres Teams die _NT_SYMBOL_PATH-Variable auf Folgendes fest:

Srv*c:\symbols*\\mainserver\symbols*https://msdl.microsoft.com/download/symbols

Wenn Symbole abgerufen werden, werden Dateien und Ordner im freigegebenen Verzeichnis „\\mainserver\symbols“ sowie in einzelnen Caches im Verzeichnis „c:\symbols“ angezeigt.

Dies sind in der Regel alle Komponenten, die an der Einrichtung und Verwendung Ihres eigenen Symbolservers oder des Microsoft-Symbolservers beteiligt sind.

Hinzufügen von Symbolen zu einem Symbolserver

Verwenden Sie das Tool „symstore.exe“, um Dateien bei einer Symbolserverfreigabe hinzuzufügen, zu löschen oder zu bearbeiten. Dieses Tool ist Teil des Microsoft Debugging Tools-Pakets für Windows. Die vollständige Dokumentation zu Symbolservern, dem symstore-Tool und den Indizierungssymbolen ist im Microsoft Debugging Tools-Paket für Windows enthalten.

Möglicherweise müssen Sie Ihrem eigenen Symbolserver im Rahmen eines Buildprozesses Symbole direkt hinzufügen oder Ihrem gesamten Team Symbole für Bibliotheken oder Tools von Drittanbietern zur Verfügung stellen. Der Vorgang zum Hinzufügen eines Symbols zu einer Symbolserver-Dateifreigabe wird als Indizieren von Symbolen bezeichnet. Es gibt zwei gängige Methoden zum Indizieren von Symbolen. Eine Symboldatei kann auf den Symbolserver kopiert werden. Alternativ kann ein Zeiger auf den Speicherort des Symbols auf den Symbolserver kopiert werden. Wenn Sie über einen Archivordner verfügen, der Ihre alten Builds enthält, müssen Sie Zeiger auf die PDB-Dateien indizieren, die sich bereits in der Freigabe befinden, anstatt Symbole zu duplizieren. Da Symbole mehrere Megabyte groß sein können, empfiehlt es sich, im Entwicklungsprozess vorauszuplanen, wie viel Speicherplatz Sie für die Archivierung aller Builds Ihres Projekts benötigen. Wenn Sie nur Zeiger auf Symbole indizieren, können Probleme auftreten, wenn Sie alte Builds entfernen oder den Namen einer Dateifreigabe ändern.

Sie können beispielsweise den folgenden Befehl verwenden, um alle Symbole unter „c:\dxsym\Extras\Symbols“, die Sie aus dem DirectX-SDK von Oktober 2006 abgerufen haben, rekursiv in eine Symbolserver-Dateifreigabe namens „\\mainserver\symbols“ zu indizieren:

"c:\Program Files\Debugging Tools for Windows\symstore" add /f "C:\dxsym\Extras\Symbols\*.pdb"
/s \\mainserver\symbols /t "October 2006 DirectX SDK " /r

Der Parameter /t "Kommentar" wird verwendet, um der Transaktion, die die Symbole hinzugefügt hat, eine Beschreibung hinzuzufügen. Dies kann hilfreich sein, wenn Sie administrative Aufgaben für die Symbole ausführen.

Bewährte Methoden

  • Richten Sie Ihre eigene Symbolserver-Dateifreigabe für Ihr Team, Unternehmen oder Produkt ein.
  • Richten Sie die _NT_SYMBOL_PATH-Variable ein, um auf einen lokalen Cache, einen privaten Symbolserver und den Microsoft-Symbolserver zu verweisen.
  • Wenn ein Debugger keine Symbole für eine Komponente laden kann, die Sie debuggen, wenden Sie sich an die Besitzer*innen der Komponente, um Symbole anzufordern (mindestens eine gestrippte PDB-Datei).
  • Richten Sie ein automatisiertes Buildsystem ein, um Symbole auf Ihrem privaten Symbolserver für jeden Build zu indizieren, der erstellt wird. Stellen Sie sicher, dass die von Ihnen verteilten Builds die Builds sind, die durch diesen Prozess generiert werden. Dadurch wird sichergestellt, dass Symbole immer zum Debuggen von Problemen verfügbar sind.
  • Richten Sie einen Symbolserver ein, um Debuggern den Zugriff auf den Quellcode für ein bestimmtes Modul direkt über ein Visual Source Safe- oder Perforce-basiertes Quellcode-Verwaltungssystem zu ermöglichen. Wenn die Quelldateiinformationen und Symbole für eine veröffentlichte Version eines Spiels indiziert sind, können Entwickler*innen, die Zugriff auf Ihren Symbolserver haben, gemeldete Fehler auf Quellcodeebene vollständig debuggen, ohne Buildumgebungen oder alte Versionen von Quelldateien auf ihren Entwicklungscomputern beibehalten zu müssen. Informationen zum Einrichten des Symbolservers zum Zulassen der Indizierung von Quelldateiinformationen finden Sie in der Quellserverdokumentation.