Table of contents

Einführung

Als Symbols werden Dateien beschrieben, die es ermöglichen in unterschiedlichen Debugging Tools korrekte Funktionsnamen angezeigt werden. Diese Funktionnamen können sich zwar unterscheiden zu den “echten” Funktionsnamen im Source Code, aber geben in der Regel eine gute Idee davon was dahinter steckt.

Live-Demo mit Process Explorer

Um zu sehen, wie das in den Tools aussieht ob Symbols geladen werden oder nicht, werden wir das im Process Explorer Tool ansehen. Der Stack im Process Explorer sieht ohne Symbols wie folgt aus:

Nach dem konfigurieren, ist zu sehen wie die Symbols geladen werden:

Das kann einen Moment dauern, dann öffnet sich der Dialog:

Dabei ist zu erkennen, für die CalculatorApp.dll selbst sehen wir keine weiteren Informationen. Aber für andere Module gibt es weitere Informationen twinapi.appcore.dll. Warum sehen wir für CalculatorApp.dll keine weiteren Informationen? Der Grund dafür ist, dass Microsoft keine öffentlichen Symbols zur Verfügung stellt.

Konfiguration von Symbols

Zwei wesentliche Konfiguration sind zu beachten:

• Die korrekte dbghelp.dll
• Die korrekte Konfiguration des/der Symbols Pfade

dbghelp.dll

Yarden Shafir Twitter Post beschreibt die Problematik, dass die dbghelp.dll in C:\Windows\System32 nicht funktionstüchtig ist (der eigentliche Übeltäter ist die fehlende symsrv.dll).

Die übliche Vorgehensweise ist, dass das Windows SDK installiert wird. In der Installation GUI ist es nur notwendig, die Debugging Tools for Windows auszuwählen und zu installieren.

Danach kann beispielsweise im Process Explorer die richtige dbghelp.dll ausgewählt werden (C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\).

Was ist mit anderen Tools?

Die meisten anderen Programme haben bereits die korrekte Konfiguration - lediglich der Symbol Pfad muss meistens noch konfiguriert werden.
Falls es noch andere Tools gibt, die die Konfiguration von dbghelp.dll benötigen, lass es mich wissen.

NT_SYMBOL_PATH

Um die korrekte Symbol Pfade zu konfigurieren, empfiehlt es sich die Umgebungsvariable NT_SYMBOL_PATH zu setzen. Der Grund ist, dass viele Troubleshooting Tools diese Umgebungsvariable verwenden um die konfigurierten Symbol Server zu finden. Das erspart oft das konfigurieren in den jeweiligen Tools.

Details dazu gibt es beispielsweise von Microsoft: Symbol Path

Ein guter Start wäre beispielsweise folgender Wert für Umgebungsvariable

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

Symbolserver

Eine gute Liste für Symbolserver hat Bruce Dawson zusammengetragen und ist in diesem Blogbeitrag zu finden: Creating a Public Symbol Server, Easily

Ein Beispiel für das Einbinden von mehreren Symbolserver:

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com

Private Symbols vs Public Symbols

Als Systemadministrator der in der Regel fremde Programme (kein Zugriff auf Quellcode) werden wir es so gut wie immer mit sogenannten Public Symbols zu tun haben. Diese Symbols beeinhalten wesentliche Informationen, möglicherweise aber nicht die korrekten Funktionsnamen wie sie im Source Code sind und bestimmte Informationen

Im Gegensatz zu Private Symbols die dann zur Verfügung stehen sobald die Software inkl. Quellcode zur Verfügung stehen. Oft werden diese dann implizit mitgenutzt (Visual Studio Debugging).

Eine genauere Gegenüberstellung findet sich hier: Public and Private Symbols