Debug di codice gestito tramite il debugger Di Windows

Articolo
09/27/2024

È possibile usare i debugger windows (WinDbg, CDB e NTSD) per eseguire il debug di applicazioni di destinazione contenenti codice gestito. Per eseguire il debug del codice gestito, usare ! Estensione di debug SOS (sos.dll) e un componente di accesso ai dati (mscordacwks.dll) in combinazione con il runtime CLR.

I debugger di Windows, ad esempio WinDbg, sono separati dal debugger di Visual Studio. Per informazioni sulla distinzione tra i debugger di Windows e il debugger di Visual Studio, vedere Strumenti di debug per Windows.

Questo articolo fornisce istruzioni sull'uso di debugger Windows (WinDbg, CDB, NTSD) per eseguire il debug di codice gestito, tra cui .NET Framework, .NET Core e applicazioni .NET 5+.

Nota

Quando si esegue il debug di applicazioni .NET Framework, .NET Core e .NET 5+, assicurarsi di usare la versione più recente degli strumenti del debugger di Windows. È anche consigliabile usare Visual Studio o Visual Studio Code per un'esperienza di debug più integrata. WinDbg è più complesso, richiede più lavoro per la configurazione e viene in genere usato quando sono necessarie informazioni di basso livello aggiuntive.

Introduzione al codice gestito

Il codice gestito viene eseguito insieme a Microsoft .NET Common Language Runtime (CLR). In un'applicazione con codice gestito, il codice binario prodotto dal compilatore è in Microsoft Intermediate Language (MSIL), indipendente dalla piattaforma.

Quando viene eseguito il codice gestito, il runtime produce codice nativo specifico della piattaforma. Il processo di generazione di codice nativo da MSIL viene chiamato compilazione JIT (Just-In-Time). Dopo che il compilatore JIT ha compilato MSIL per un metodo specifico, il codice nativo del metodo rimane in memoria. Ogni volta che questo metodo viene chiamato in un secondo momento, il codice nativo viene eseguito e il compilatore JIT non deve essere coinvolto.

È possibile compilare codice gestito usando diversi compilatori prodotti da un'ampia gamma di produttori di software. In particolare, Microsoft Visual Studio può compilare codice gestito da diversi linguaggi, tra cui C#, Visual Basic, JScript e C++ con estensioni gestite.

CLR non viene aggiornato ogni volta che viene aggiornato .NET Framework. Ad esempio, le versioni 2.0, 3.0 e 3.5 di .NET Framework usano tutte la versione 2.0 di CLR. Per altre informazioni sulle versioni di .NET, vedere Versioni e dipendenze di .NET Framework. Per informazioni sulla determiatura della versione di .NET nel PC, vedere Determinare quali versioni di .NET Framework sono installate.

Debug di codice gestito

Per eseguire il debug del codice gestito usando ! Estensione di debug SOS, il debugger deve caricare vari componenti. Le! Estensione di debug SOS e i componenti necessari usati per diversi per .NET Core e .NET Framework originale. Per entrambi, viene usato il componente di accesso ai dati (DAC) (mscordacwks.dll).

.NET SDK offre strumenti che possono essere utili per l'uso del debug di app .NET. Per altre informazioni, vedere Che cos'è .NET SDK?.

.NET Core

Per .NET Core o .NET 5+ e versioni successive, il runtime è coreclr.dll. Per altre informazioni, vedere Panoramica di Common Language Runtime (CLR).
Estensione di debug SOS di .NET Core

Per .NET Core è disponibile uno strumento dell'interfaccia della riga di comando dotnet per installare sos.dll. Per altre informazioni, vedere programma di installazione SOS (dotnet-sos).For more information, see SOS installer (dotnet-sos).

.NET Framework originale.

Per .NET Framework originale, clr.dll è il runtime.
Estensione di debug SOS (sos.dll)

Recupero dell'estensione di debug SOS (sos.dll)

I file di estensione di debug SOS (sos.dll) non sono inclusi in tutte le versioni degli strumenti di debug per Windows. Se sos.dll non è disponibile, vedere Installazione di SOS in Windows.

Caricamento dell'estensione di debug SOS (sos.dll)

Per eseguire il debug di applicazioni .NET Core e .NET 5+, è necessario caricare la versione appropriata dell'estensione di debug SOS.

Ad esempio, a una versione di ! SOS incluso nel debugger ed è incluso nel percorso di ricerca dell'estensione corrente, verrà usato il comando .load .

0:000> .load sos.dll

Per verificare che l'estensione di debug SOS sia stata caricata correttamente, usare il comando .chain ed eseguire exmaine la catena dll di estensione.

...
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]

Se la versione del debugger non include il sos.dll, potrebbe essere necessario specificare il percorso completo del file SOS.dll. In genere è possibile trovare il file SOS.dll nella directory di runtime dell'installazione di .NET Core o .NET Framework.

0:000> .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll

Caricamento di una versione specifica di sos.dll

Il caricamento del sos.dll può essere complesso, poiché esiste una dipendenza dalle DLL aggiuntive usate dal sos.dll per comunicare con .NET. Inoltre, la versione della DLL necessaria dipende dalla versione .NET dell'app di cui è in corso il debug e nel computer possono essere presenti più versioni di .NET.

Una strategia per caricare la versione corretta della DLL dipendente consiste nel chiedere al debugger di interrompere l'interruzione quando si verifica la prima notifica clr .NET (CLRN) usando sx, sxd, sxe, sxi, sxn, sxr, sxr (Set Exceptions)[.. Comando /debuggercmds/sx--sxd--sxe--sxi--sxn--sxr-sx---set-exceptions-.md]. Dopo aver collegato all'applicazione .NET di destinazione, questo comando verrà usato dopo la prima interruzione.

0:000> sxe CLRN

Riprendere quindi l'esecuzione e attendere che si verifichi l'interruzione.

0:000> g

Quando si verifica l'interruzione, disabilitare l'interruzione di notifica clr, come si sa clr.dll (o coreclr.dll) è stata caricata.

0:000> sxd CLRN

Con il debugger in questo contesto, usare . loadby per caricare !sos dallo stesso percorso della directory "nelle vicinanze".

0:000> .loadby sos clr

Un'altra opzione consiste nell'usare il file cordll (Control CLR Debugging) per caricare le DLL di debug CLR fornendo un percorso al percorso del framework di destinazione.

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

Uso dell'estensione di debug SOS

Per verificare che l'estensione di debug SOS sia stata caricata correttamente, immettere il comando .chain .

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]
...

File di simboli .NET

I file di simboli sono essenziali per il debug. Per le applicazioni .NET Framework, .NET Core e .NET 5+, è possibile recuperare i file di simboli necessari dal server dei simboli pubblici di Microsoft. Usare il comando seguente per impostare il percorso del simbolo e il caricamento dei simboli echo.

.symfix

!sym noisy

.reload

Test dell'estensione .NET Core !sos

Per testare l'estensione di debug SOS, immettere !sos.help.

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

Provare quindi uno dei comandi forniti dall'estensione di debug SOS. Ad esempio, è possibile provare !sos. DumpDomain o !sos. Comando thread forniti dall'estensione di debug SOS .NET Core.

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)

Test dell'estensione .NET Framework !sos

Per testare l'estensione di debug SOS, immettere !sos.help. Provare quindi uno dei comandi forniti dall'estensione di debug SOS. Ad esempio, è possibile provare !sos.sostatus o il comando !sos.threads .

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.

Note

A volte un'applicazione con codice gestito carica più di una versione di CLR. In tal caso, è necessario specificare la versione dell'applicazione livello dati da caricare. Per altre informazioni, vedere .cordll and Clrver.exe (CLR Version Tool).

Condividi tramite