Erweiterte SymSrv-Verwendung

SymSrv kann Symboldateien aus einem zentralen Symbolspeicher bereitstellen. Dieser Speicher kann eine beliebige Anzahl von Symboldateien enthalten, die einer beliebigen Anzahl von Programmen oder Betriebssystemen entsprechen. Der Speicher kann auch Binärdateien enthalten (dies ist hilfreich beim Debuggen von Minidumps).

Der Speicher kann das tatsächliche Symbol und die Binärdateien enthalten, oder er kann einfach Zeiger auf Symboldateien enthalten. Wenn der Speicher Zeiger enthält, ruft SymSrv die tatsächlichen Dateien direkt aus ihren Quellen ab.

SymSrv kann auch verwendet werden, um einen großen Symbolspeicher in eine kleinere Teilmenge zu trennen, die für eine spezielle Debugaufgabe geeignet ist.

Schließlich kann SymSrv Symboldateien aus einer HTTP- oder HTTPS-Quelle mithilfe der anmeldeinformationen des Betriebssystems abrufen. SymSrv unterstützt HTTPS-Websites, die durch Smartcards, Zertifikate und reguläre Anmeldungen und Kennwörter geschützt sind. Weitere Informationen finden Sie unter HTTP-Symbolspeicher.

Festlegen des Symbolpfads

Um diesen Symbolserver zu verwenden, muss symsrv.dll im selben Verzeichnis wie der Debugger installiert sein. Der Symbolpfad kann wie in diesem Code dargestellt festgelegt werden:

set _NT_SYMBOL_PATH = symsrv*ServerDLL*DownstreamStore*\\Server\Share

set _NT_SYMBOL_PATH = symsrv*ServerDLL*\\Server\Share

set _NT_SYMBOL_PATH = srv*DownstreamStore*\\Server\Share

set _NT_SYMBOL_PATH = srv*\\Server\Share

Die Teile dieser Syntax werden wie folgt erläutert:

symsrv
Dieses Schlüsselwort muss immer zuerst angezeigt werden. Er gibt dem Debugger an, dass es sich bei diesem Element um einen Symbolserver handelt, nicht nur um ein normales Symbolverzeichnis.

ServerDLL
Gibt den Namen der Symbolserver-DLL an. Wenn Sie den SymSrv-Symbolserver verwenden, wird dies immer symsrv.dll.

srv
Dies ist kurz für symsrv*symsrv.dll.

DownstreamStore
Gibt den nachgelagerten Speicher an. Dies ist ein lokales Verzeichnis oder eine Netzwerkfreigabe, die zum Zwischenspeichern einzelner Symboldateien verwendet wird.

Sie können mehrere nachgeschaltete Speicher angeben, getrennt durch Sternchen. Mehrere nachgelagerte Speicher werden in Cascading Downstream Stores weiter unten auf dieser Seite erläutert.

Wenn Sie zwei Sternchen in eine Zeile einschließen, in der normalerweise ein nachgelagerter Speicher angegeben würde, wird der Standardspeicher nachgelagerter Speicher verwendet. Dieser Speicher befindet sich im Sym-Unterverzeichnis des Startverzeichnisses. Das Startverzeichnis ist standardmäßig im Debuggerinstallationsverzeichnis enthalten; dies kann mithilfe der !homedir-Erweiterung oder durch Festlegen der DBGHELP_HOMEDIR Umgebungsvariable geändert werden.

Wenn DownstreamStore ein Verzeichnis angibt, das nicht vorhanden ist, versucht SymStore, es zu erstellen.

Wenn der DownstreamStore-Parameter weggelassen wird und kein zusätzliches Sternchen enthalten ist , d. h., wenn Sie srv mit genau einem Sternchen oder Symsrv mit genau zwei Sternchen verwenden , wird kein nachgelagerter Speicher erstellt. Der Debugger lädt alle Symboldateien direkt vom Server, ohne sie lokal zwischenzuspeichern.

Hinweis : Wenn Sie von einer HTTP- oder HTTPS-Website auf Symbole zugreifen oder wenn der Symbolspeicher komprimierte Dateien verwendet, wird immer ein nachgeschalteter Speicher verwendet. Wenn kein nachgeschalteter Speicher angegeben wird, wird ein Speicher im Sym-Unterverzeichnis des Startverzeichnisses erstellt.

\\Server\Freigabe
Gibt den Server und die Freigabe des Remotesymbolspeichers an.

Wenn ein nachgeschalteter Speicher verwendet wird, sucht der Debugger zunächst nach einer Symboldatei in diesem Speicher. Wenn die Symboldatei nicht gefunden wird, sucht der Debugger die Symboldatei vom angegebenen Server und der freigabe, und speichert dann eine Kopie dieser Datei im nachgeschalteten Speicher zwischen. Die Datei wird in ein Unterverzeichnis in der Struktur unter DownstreamStore kopiert, die ihrem Speicherort in der Struktur unter \\Server\Freigabe entspricht.

Der Symbolserver muss nicht der einzige Eintrag im Symbolpfad sein. Wenn der Symbolpfad aus mehreren Einträgen besteht, überprüft der Debugger jeden Eintrag auf die erforderlichen Symboldateien (von links nach rechts), unabhängig davon, ob ein Symbolserver oder ein tatsächliches Verzeichnis benannt ist.

Nachfolgend finden Sie einige Beispiele. Wenn Sie SymSrv als Symbolserver mit einem Symbolspeicher auf \\mybuilds\mysymbols verwenden möchten, legen Sie den folgenden Symbolpfad fest:

set _NT_SYMBOL_PATH= symsrv*symsrv.dll*\\mybuilds\mysymbols

Um den Symbolpfad so festzulegen, dass der Debugger Symboldateien aus einem Symbolspeicher unter \\mybuilds\mysymbols in Ihr lokales Verzeichnis c:\localsymbols kopiert, verwenden Sie Folgendes:

set _NT_SYMBOL_PATH=symsrv*symsrv.dll*c:\localsymbols*\\mybuilds\mysymbols

Um den Symbolpfad so festzulegen, dass der Debugger Symboldateien von der HTTPS-Website https://www.company.com/manysymbols in ein lokales Netzwerkverzeichnis \\localserver\myshare\mycache kopiert, verwenden Sie Folgendes:

set _NT_SYMBOL_PATH=symsrv*symsrv.dll*\\localserver\myshare\mycache*https://www.company.com/manysymbols

Dieses letzte Beispiel kann auch gekürzt werden:

set _NT_SYMBOL_PATH=srv*\\localserver\myshare\mycache*https://www.company.com/manysymbols

Darüber hinaus kann der Symbolpfad mehrere Verzeichnisse oder Symbolserver enthalten, die durch Semikolons getrennt sind. Auf diese Weise können Sie Symbole von mehreren Speicherorten (oder sogar von mehreren Symbolservern) suchen. Wenn eine Binärdatei über eine nicht übereinstimmende Symboldatei verfügt, kann der Debugger sie nicht mithilfe des Symbolservers finden, da er nur auf die genauen Parameter überprüft. Der Debugger findet jedoch möglicherweise eine nicht übereinstimmende Symboldatei mit dem richtigen Namen, wobei der herkömmliche Symbolpfad verwendet und erfolgreich geladen wird. Obwohl die Datei technisch nicht die richtige Symboldatei ist, kann sie nützliche Informationen bereitstellen.

Löschen des Caches

Wenn Sie einen DownstreamStore als Cache verwenden, können Sie dieses Verzeichnis jederzeit löschen, um Speicherplatz zu sparen.

Es ist möglich, einen großen Symbolspeicher zu haben, der Symboldateien für viele verschiedene Programme oder Windows-Versionen enthält. Wenn Sie die version von Windows aktualisieren, die auf Ihrem Zielcomputer verwendet wird, stimmen die zwischengespeicherten Symboldateien mit der früheren Version überein. Diese zwischengespeicherten Dateien werden nicht weiter verwendet, daher ist dies ein guter Zeitpunkt, um den Cache zu löschen.

Cascading Downstream Stores

Sie können eine beliebige Anzahl nachgeschalteter Speicher angeben, getrennt durch Sternchen. Diese Stores werden als kaskadierende Symbolspeicher bezeichnet.

Nach dem Anfänglichen srv* oder symsrv*ServerDLL*, jedes nachfolgende Token stellt eine Symbolposition dar. Das Token, das am weitesten links ist, wird zuerst überprüft. Ein leeres Token , das durch zwei Sternchen in einer Zeile oder durch ein Sternchen am Ende der Zeichenfolge angegeben wird, stellt den Standard-Downstreamspeicher dar.

Hier ist ein Beispiel für einen Symbolpfad, der zwei nachgelagerte Speicher verwendet, um Informationen aus dem Hauptsymbolspeicher zu speichern, auf den zugegriffen wird. Dies kann als Masterspeicher, mittlerer Speicher und lokaler Cache bezeichnet werden:

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

In diesem Szenario sucht SymSrv zuerst in "c:\localcache" nach einer Symboldatei. Wenn sie dort gefunden wird, wird ein Pfad dorthin zurückgegeben. Wenn sie dort nicht gefunden wird, wird sie im \\interim\store angezeigt. Wenn die Symboldatei dort gefunden wird, kopiert SymSrv sie in c:\localcache und gibt den Pfad zurück. Wenn sie dort nicht gefunden wird, sucht SymSrv im öffentlichen Microsoft-Symbolspeicher unter https://msdl.microsoft.com/download/symbols; wenn die Datei dort gefunden wird, kopiert SymSrv sie sowohl in \\interim\store als auch in c:\localcache.

Ein ähnliches Verhalten würde mithilfe des folgenden Pfads abgerufen:

srv**\\interim\store*https://internetsite

In diesem Fall ist der lokale Cache der Standard-Downstreamspeicher, und der Masterspeicher ist eine Internetwebsite. Für die Verwendung zwischen den anderen beiden wurde ein Speicher auf mittlerer Ebene des \\interim\store angegeben.

Wenn SymSrv einen Pfad verarbeitet, der kaskadierende Speicher enthält, wird jeder Speicher übersprungen, in den er nicht lesen oder schreiben kann. Wenn also eine Freigabe heruntergeht, wird die Datei ohne Fehler in den nachgelagerten Speicher kopiert. Ein schöner Nebeneffekt dieses Fehlers besteht darin, dass der Benutzer mehrere Masterspeicher angeben kann, die einen einzelnen Datenstrom nachgelagerter Speicher feeds, solange die Masterspeicher nicht schreibbar sind.

Wenn eine komprimierte Symboldatei aus dem Masterspeicher abgerufen wird, wird sie in komprimierter Form in einem beliebigen Speicher auf mittlerer Ebene gespeichert. Die Datei wird im untersten Speicher im Pfad nicht komprimiert.

Arbeiten mit HTTP- und SMB-Symbolserverpfaden

Wie bereits erwähnt, bezieht sich die Verkettung (oder Kaskadierung) auf die Kopie, die zwischen jedem "*"-Trennzeichen im Symbolpfad auftritt. Die Symbole werden in einer von links nach rechts angeordneten Reihenfolge gesucht. Bei jedem Miss wird der nächste (upstream) Symbolserver abgefragt, bis die Datei gefunden wird.

Wenn die Datei gefunden wird, wird die Datei vom (upstream)Symbolserver auf den vorherigen (nachgeschalteten) Symbolserver kopiert. Dies wird für jeden (nachgeschalteten) Symbolserver wiederholt. Auf diese Weise werden die (gemeinsam genutzten) nachgeschalteten Symbolserver mit den kollektiven Bemühungen aller Clients aufgefüllt, die die Symbolserver verwenden.

Obwohl verkettete UNC-Pfade ohne das PRÄfix SRV* verwendet werden können, empfiehlt es sich, SRV* anzugeben, damit die erweiterte Fehlerbehandlung von symsrv.dll verwendet werden kann.

Wenn sie einen HTTP-Symbolserver in den Pfad einschließen, kann nur ein Server angegeben werden (pro Kette), und er muss am Ende des Pfads sein (da er nicht als Cache geschrieben werden kann). Wenn sich ein HTTP-basierter Symbolspeicher in der Mitte oder links neben der Speicherliste befindet, wäre es nicht möglich, gefundene Dateien in die Liste zu kopieren, und die Kette würde unterbrochen. Da der Symbolhandler keine Datei von einer Website öffnen kann, sollte ein HTTP-basierter Speicher nicht ganz links oder nur in der Liste gespeichert sein. Wenn SymSrv jemals diesem Symbolpfad angezeigt wird, versucht es, die Datei in den standard-downstream-Speicher zu kopieren und von dort aus zu öffnen, unabhängig davon, ob der standard-downstream-Speicher im Symbolpfad angegeben ist oder nicht.

HTTP wird nur bei Verwendung des SRV*-Präfixes (implementiert durch den symsrv.dll-Symbolhandler) unterstützt.

Beispielszenarien für HTTP- und SMB-Freigabesymbolserver

Bei einer allgemeinen UNC-bereitstellung handelt es sich um eine zentrale Zentrale, die alle Dateien hostet (\\MainOffice\Symbols), Zweigstellen, die eine Teilmenge (\\BranchOfficeA\Symbols) zwischenspeichern, und Desktops (C:\Symbols) zwischenspeichern die Dateien, auf die verwiesen wird.

srv*C:\Symbols*\\BranchOfficeA\Symbols*\\MainOffice\Symbols

Wenn die SMB-Freigabe der primäre (upstream) Symbolspeicher ist, ist "Read" erforderlich.

srv*C:\Symbols*\\MachineName\Symbols

Wenn die SMB-Freigabe ein Zwischenspeicher (downstream) ist, ist Lese-/Änderung erforderlich. Der Client kopiert die Datei aus dem primären Symbolspeicher in die SMB-Freigabe und dann von der SMB-Freigabe in den lokalen Ordner.

srv*C:\Symbols*\\MachineName\Symbols*https://msdl.microsoft.com/download/symbols
srv*C:\Symbols*\\MachineName\Symbols*\\MainOffice\Symbols

Wenn es sich bei der SMB-Freigabe um einen Zwischenspeicher (nachgeschalteter) Symbolspeicher in einer SymProxy-Bereitstellung handelt, ist nur Read erforderlich. Der SymProxy ISAPI-Filter führt die Schreibvorgänge aus, nicht den Client.

srv*C:\Symbols*\\MachineName\Symbols*https://SymProxyName/Symbols

Servercacheszenarien mit mehreren HTTP- und SMB-Freigabesymbolen

Es ist möglich, mehrere Ketten von Symbolservern und Cachespeicherorten anzugeben, getrennt durch einen Semikolon ";". Wenn sich die Symbole in der ersten Kette befinden, wird die zweite Kette nicht durchlaufen. Wenn sich die Symbole nicht in der ersten Kette befinden, wird die zweite Kette durchlaufen und wenn sich die Symbole in der zweiten Kette befinden, werden sie an der angegebenen Position zwischengespeichert. Bei diesem Ansatz kann ein primärer Symbolserver normalerweise verwendet werden, wobei nur ein sekundärer Server verwendet wird, wenn die Symbole nicht auf dem primären Symbolserver verfügbar sind, der in der ersten Kette angegeben ist.

srv*C:\Symbols*\\Machine1\Symbols*https://SymProxyName/Symbols;srv*C:\WebSymbols*https://msdl.microsoft.com/download/symbols

cache*localsymbolcache

Eine weitere Möglichkeit zum Erstellen eines lokalen Caches von Symbolen ist die Verwendung der cache*localsymbolcache Zeichenfolge im Symbolpfad. Dies ist nicht Teil des Symbolserverelements, sondern ein separates Element im Symbolpfad. Der Debugger verwendet den angegebenen Verzeichnis localsymbolcache , um alle Symbole zu speichern, die von jedem Element geladen werden, das in Ihrem Symbolpfad rechts neben dieser Zeichenfolge angezeigt wird. Auf diese Weise können Sie einen lokalen Cache für Symbole verwenden, die von einem beliebigen Speicherort heruntergeladen wurden, nicht nur für Symbole, die von einem Symbolserver heruntergeladen wurden.

Der folgende Symbolpfad speichert z. B. keine Symbole zwischen, die von \\someshare stammen. Es verwendet c:\mysymbols, um Symbole zwischenzuspeichern, die von \\anothershare stammen, da das Element, das mit \\anothershare beginnt, rechts neben dem Cache*c:\mysymbols-Element angezeigt wird. Es wird auch c:\mysymbols verwendet, um Symbole aus dem öffentlichen Microsoft-Symbolspeicher zwischenzuspeichern, aufgrund der üblichen Syntax, die vom Symbolserver verwendet wird (srv mit zwei oder mehr Sternchen). Wenn Sie anschließend den Befehl ".sympath+" verwenden, um diesem Pfad zusätzliche Speicherorte hinzuzufügen, werden diese neuen Elemente ebenfalls zwischengespeichert, da sie an die rechte Seite des Pfads angefügt werden.

_NT_SYMBOL_PATH=\\someshare\that\cachestar\ignores;srv*c:\mysymbols*https://msdl.microsoft.com/download/symbols;cache*c:\mysymbols;\\anothershare\that\gets\cached

Wie SymSrv Dateien sucht

SymSrv erstellt einen vollqualifizierten UNC-Pfad zur gewünschten Symboldatei. Dieser Pfad beginnt mit dem Pfad zum Symbolspeicher, der in der umgebungsvariablen _NT_SYMBOL_PATH aufgezeichnet wurde. Die SymbolServer-Routine wird dann verwendet, um den Namen der gewünschten Datei zu identifizieren. Dieser Name wird als Verzeichnisname an den Pfad angefügt. Ein anderer Verzeichnisname, bestehend aus der Verkettung der ID, zwei und drei Parameter, die an SymbolServer übergeben werden, wird dann angefügt. Wenn einer dieser Werte null ist, werden sie weggelassen.

Das resultierende Verzeichnis wird nach der Symboldatei oder einer Symbolspeicher-Zeigerdatei durchsucht.

Wenn diese Suche erfolgreich ist, übergibt SymbolServer den Pfad an den Aufrufer und gibt TRUE zurück. Wenn die Datei nicht gefunden wird, gibt SymbolServer FALSE zurück.

Verwenden von AgeStore zum Verringern der Cachegröße

Das AgeStore-Tool kann verwendet werden, um zwischengespeicherte Dateien zu löschen, die älter als ein angegebenes Datum sind, oder um den Inhalt des Caches unter einer angegebenen Größe zu reduzieren. Dies kann nützlich sein, wenn ihr downstreamer Speicher zu groß ist. Weitere Informationen finden Sie unter AgeStore.