Debuggen von verwaltetem Code mithilfe des Windows-Debuggers
Mit den Windows-Debuggern (WinDbg, CDB und NTSD) können Sie Zielanwendungen debuggen, die verwalteten Code enthalten. Verwenden Sie zum Debuggen von verwaltetem Code die !SOS-Debugerweiterung (sos.dll) sowie eine Datenzugriffskomponente (mscordacwks.dll) in Kombination mit der CLR-Laufzeit.
Die Windows-Debugger wie z. B. WinDbg sind vom Visual Studio-Debugger getrennt. Informationen zum Unterschied zwischen den Windows-Debuggern und dem Visual Studio-Debugger finden Sie unter Debuggingtools für Windows.
Dieser Artikel enthält Anweisungen zum Debuggen von verwaltetem Code, einschließlich .NET Framework-, .NET Core- und .NET 5+-Anwendungen, mithilfe von Windows-Debuggern (WinDbg, CDB, NTSD).
Hinweis
Stellen Sie beim Debuggen von .NET Framework-, .NET Core- und .NET 5+-Anwendungen sicher, dass Sie die neueste Version der Windows-Debuggertools verwenden. Darüber hinaus sollten Sie die Verwendung von Visual Studio oder Visual Studio Code in Betracht ziehen, um ein stärker integriertes Debugging zu ermöglichen. WinDbg ist komplexer, erfordert einen größeren Einrichtungsaufwand und wird in der Regel verwendet, wenn zusätzliche Informationen auf niedriger Ebene benötigt werden.
Einführung in verwalteten Code
Verwalteter Code wird zusammen mit der Microsoft .NET Common Language Runtime (CLR) ausgeführt. In einer Anwendung mit verwaltetem Code liegt der vom Compiler erzeugte Binärcode in der plattformunabhängigen Microsoft Intermediate Language (MSIL) vor.
Bei Ausführung von verwaltetem Code erzeugt die Laufzeit nativen, plattformspezifischen Code. Der Prozess zum Generieren von nativem Code aus MSIL wird als Just-in-Time-Kompilierung (JIT-Kompilierung) bezeichnet. Nachdem der JIT-Compiler die MSIL für eine bestimmte Methode kompiliert hat, verbleibt der native Code der Methode im Arbeitsspeicher. Wenn diese Methode später aufgerufen wird, wird der native Code ausgeführt, und der JIT-Compiler muss nicht einbezogen werden.
Sie können verwalteten Code mithilfe verschiedener Compiler einer Vielzahl von Softwareherstellern erstellen. Insbesondere kann Microsoft Visual Studio verwalteten Code aus verschiedenen Sprachen wie C#, Visual Basic, JScript und C++ mit verwalteten Erweiterungen erstellen.
Die CLR wird nicht bei jeder Aktualisierung des .NET Framework aktualisiert. Die Versionen 2.0, 3.0 und 3.5 des .NET Framework verwenden beispielsweise alle die Version 2.0 der CLR. Weitere Informationen zu .NET-Versionen finden Sie unter .NET Framework-Versionen und -Abhängigkeiten. Informationen zum Bestimmen der .NET-Version auf Ihrem PC finden Sie unter Bestimmen der installierten .NET Framework-Versionen.
Debuggen von verwaltetem Code
Um verwalteten Code mit der !SOS-Debugerweiterung zu debuggen, muss der Debugger verschiedene Komponenten laden. Die !SOS-Debugerweiterung und die erforderlichen Komponenten, die verwendet werden, sind für .NET Core und das ursprüngliche .NET Framework unterschiedlich. Für beide wird die Data Access Component (DAC) (mscordacwks.dll) verwendet.
Das .NET SDK stellt Tools bereit, die beim Debuggen von .NET-Apps hilfreich sein können. Weitere Informationen finden Sie unter Was ist das .NET SDK?
.NET Core
- Für .NET Core oder .NET 5+ und höhere Versionen ist die Laufzeit
coreclr.dll. Weitere Informationen finden Sie unter Übersicht: Common Language Runtime (CLR). - .NET Core SOS-Debugerweiterung
Für .NET Core steht ein dotnet CLI-Tool zur Installation von !sos.dll zur Verfügung. Weitere Informationen finden Sie unter SOS-Installer (dotnet-sos).
Das ursprüngliche .NET Framework.
- Für das ursprüngliche .NET Framework ist
clr.dlldie Laufzeit. - SOS-Debugerweiterung (sos.dll)
Abrufen der SOS-Debugerweiterung (sos.dll)
Die Dateien der SOS-Debugerweiterung (sos.dll) sind nicht in allen Versionen der Debugtools für Windows enthalten. Wenn sos.dll nicht verfügbar ist, beachten Sie die Informationen unter Installieren von SOS unter Windows.
Laden der SOS-Debugerweiterung (sos.dll)
Zum Debuggen von .NET Core- und .NET 5+-Anwendungen müssen Sie die entsprechende Version der SOS-Debugerweiterung laden.
Für eine im Debugger enthaltene Version von !SOS, die im aktuellen Erweiterungssuchpfad enthalten ist, würde beispielsweise der Befehl .load verwendet.
0:000> .load sos.dll
Um zu überprüfen, ob die SOS-Debugerweiterung ordnungsgemäß geladen wurde, verwenden Sie den Befehl .chain, und prüfen Sie die Erweiterungs-DLL-Kette.
...
Extension DLL chain:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll: image 4.8.9275.0, API 1.0.0, built Wed Aug 28 14:43:27 2024
[path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll]
C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\8.0.8\coreclr.dll: image 8,0,824,36612 @Commit: 08338fcaa5c9b9a8190abb99222fed12aaba956c, built Tue Jul 16 11:10:19 2024
[path: C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\8.0.8\coreclr.dll]
Wenn die Version des Debuggers die sos.dll nicht enthält, müssen Sie möglicherweise den vollständigen Pfad zur Datei „SOS.dll“ angeben. In der Regel finden Sie die Datei „SOS.dll“ im Laufzeitverzeichnis Ihrer .NET Core- oder .NET Framework-Installation.
0:000> .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll
Laden einer bestimmten Version von sos.dll
Das Laden der sos.dll kann kompliziert sein, da eine Abhängigkeit von den zusätzlichen DLLs besteht, die von der sos.dll für die Kommunikation mit .NET verwendet werden. Darüber hinaus hängt die erforderliche DLL-Version von der .NET-Version der zu debuggenden App ab, und auf dem Computer können mehrere Versionen von .NET vorhanden sein.
Eine Strategie zum Laden der richtigen Version der abhängigen DLL besteht darin, den Debugger mit dem Befehl sx, sxd, sxe, sxi, sxn, sxr, sx- (Set Exceptions)[../debuggercmds/sx--sxd--sxe--sxi--sxn--sxr--sx---set-exceptions-.md] zur Unterbrechung aufzufordern, wenn die erste .NET CLR-Benachrichtigung (CLRN) auftritt. Nach der Anfügung an die .NET-Zielanwendung wird dieser Befehl nach der ersten Unterbrechung verwendet.
0:000> sxe CLRN
Setzen Sie nun die Ausführung fort, und warten Sie, bis die Unterbrechung auftritt.
0:000> g
Wenn die Unterbrechung auftritt, deaktivieren Sie die CLR-Benachrichtigungsunterbrechung, da wir wissen, dass clr.dll (oder coreclr.dll) geladen wurde.
0:000> sxd CLRN
Verwenden Sie mit dem Debugger in diesem Kontext den Befehl .loadby, um !sos aus demselben „nahegelegenen“ Verzeichnisspeicherort zu laden.
0:000> .loadby sos clr
Eine weitere Option besteht darin, den Befehl .cordll (Control CLR Debugging) zum Laden der CLR-Debug-DLLs zu verwenden, indem Sie einen Pfad zum Zielframeworkspeicherort angeben.
0:000> .cordll -ve -u -lp C:\Windows\Microsoft.NET\Framework\v4.0.30319\
CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll
Automatically loaded SOS Extension
CLR DLL status: Loaded DLL C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll
Verwenden der SOS-Debugerweiterung
Um zu überprüfen, ob die SOS-Debugerweiterung ordnungsgemäß geladen wurde, geben Sie den Befehl .chain ein.
0:000> .chain
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows (x64);...
Extension DLL chain:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll: image 4.8.9275.0, API 1.0.0, built Wed Aug 28 14:43:27 2024
[path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll]
...
.NET-Symboldateien
Symboldateien sind für das Debuggen unerlässlich. Für .NET Framework-, .NET Core- und .NET 5+-Anwendungen können Sie die erforderlichen Symboldateien vom öffentlichen Symbolserver von Microsoft abrufen. Verwenden Sie den folgenden Befehl, um den Symbolpfad festzulegen und das Laden von Symbolen zu wiederholen.
.symfix
!sym noisy
.reload
Testen der .NET Core !sos-Erweiterung
Geben Sie zum Testen der SOS-Debugerweiterung !sos.help ein.
0:000> !sos.help
-------------------------------------------------------------------------------
SOS is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
importance. Shortcut names for popular functions are listed in parenthesis.
Type "!help <functionname>" for detailed info on that function.
Object Inspection Examining code and stacks
----------------------------- -----------------------------
DumpObj (do) Threads
DumpArray (da) ThreadState
DumpStackObjects (dso) IP2MD
DumpHeap U
DumpVC DumpStack
GCRoot EEStack
ObjSize CLRStack
FinalizeQueue GCInfo
PrintException (pe) EHInfo
TraverseHeap BPMD
COMState
Probieren Sie dann einen der Befehle aus, die von der SOS-Debugerweiterung bereitgestellt werden. Sie könnten beispielsweise !sos.DumpDomain oder den Befehl !sos.Threads ausprobieren, der von der .NET Core SOS-Debugerweiterung bereitgestellt wird.
0:000> !sos.DumpDomain
--------------------------------------
System Domain: 7565d980
LowFrequencyHeap: 7565dca4
HighFrequencyHeap: 7565dcf0
StubHeap: 7565dd3c
Stage: OPEN
Name: None
--------------------------------------
Shared Domain: 7565d620
LowFrequencyHeap: 7565dca4
HighFrequencyHeap: 7565dcf0
StubHeap: 7565dd3c
Stage: OPEN
Name: None
Assembly: 00fa5e78 [C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll]
ClassLoader: 00fa5f40
Module Name
73571000 C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
0:000> !sos.Threads
ThreadCount: 2
UnstartedThread: 0
BackgroundThread: 2
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 4538 00f91110 20220 Preemptive 02FE1238:00000000 00f58be0 1 Ukn
7 2 250c 00f9da88 21220 Cooperative 00000000:00000000 00f58be0 1 Ukn (Finalizer)
Testen der .NET Framework !sos-Erweiterung
Geben Sie zum Testen der SOS-Debugerweiterung !sos.help ein. Probieren Sie dann einen der Befehle aus, die von der SOS-Debugerweiterung bereitgestellt werden. Sie könnten beispielsweise !sos.sostatus oder den Befehl !sos.threads ausprobieren.
0:030> !soshelp
crashinfo Displays the crash details that created the dump.
help, soshelp <command> Displays help for a command.
loadsymbols <url> Loads symbols for all modules.
logclose <path> Disables console file logging.
logging <path> Enables/disables internal diagnostic logging.
logopen <path> Enables console file logging.
maddress Displays a breakdown of the virtual address space.
modules, lm Displays the native modules in the process.
registers, r Displays the thread's registers.
runtimes <id> Lists the runtimes in the target or changes the default runtime.
setclrpath <path> Sets the path to load coreclr DAC/DBI files.
setsymbolserver, SetSymbolServer <url> Enables and sets symbol server support for symbols and module download.
sosflush Resets the internal cached state.
sosstatus Displays internal status.
threads, setthread <thread> Lists the threads in the target or sets the current thread.
Hinweise
Manchmal lädt eine Anwendung mit verwaltetem Code mehr als eine Version der CLR. In diesem Fall müssen Sie angeben, welche DAC-Version geladen werden soll. Weitere Informationen finden Sie unter .cordll und Clrver.exe (CLR Version Tool).