Debug del codice gestito tramite il debugger di Windows

  • Articolo

È possibile usare i debugger di Windows (WinDbg, CDB e NTSD) per eseguire il debug di applicazioni di destinazione contenenti codice gestito. Per eseguire il debug del codice gestito, è necessario caricare l'estensione di debug SOS (sos.dll) e un componente di accesso ai dati (mscordacwks.dll).

I debugger di Windows sono separati dal debugger di Visual Studio. Per informazioni sulla distinzione tra i debugger di Windows e il debugger di Visual Studio, vedere Debug di Windows.

Introduzione al codice gestito

Il codice gestito viene eseguito insieme a Microsoft .NET Common Language Runtime (CLR). In un'applicazione gestita il codice binario generato dal compilatore è in Microsoft Intermediate Language (MSIL), che è 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 aver compilato il compilatore JIT 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 creare codice gestito usando diversi compilatori prodotti da un'ampia gamma di produttori di software. In particolare, Microsoft Visual Studio può creare codice gestito da diversi linguaggi, tra cui C#, Visual Basic, JScript e C++ con estensioni gestite.

ClR non viene aggiornato ogni volta che .NET Framework viene aggiornato. Ad esempio, le versioni 2.0, 3.0 e 3.5 di .NET Framework usano tutte la versione 2.0 di CLR. Nella tabella seguente viene illustrata la versione e il nome file del CLR usato da ogni versione di .NET Framework.

Versione di .NET Framework Versione CLR Nome file CLR
1,1 1,1 mscorwks.dll
2,0 2,0 mscorwks.dll
3,0 2,0 mscorwks.dll
3,5 2,0 mscorwks.dll
4.0 4.0 clr.dll
4.5 4,0 clr.dll

Debug del codice gestito

Per eseguire il debug del codice gestito, il debugger deve caricare questi due componenti.

Nota Per tutte le versioni di .NET Framework, il nome file dell'applicazione livello dati è mscordacwks.dll e il nome file dell'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 nella versione corrente degli strumenti di debug per Windows.

Per .NET Framework versione 2.0 e versioni successive, sos.dll è incluso nell'installazione di .NET Framework.

Per la versione 1. x di .NET Framework, sos.dll non è incluso nell'installazione di .NET Framework. Per ottenere sos.dll per .NET Framework 1. x, scaricare la versione a 32 bit di Strumenti di debug di Windows 7 per Windows.

Gli strumenti di debug di Windows 7 per Windows sono inclusi in Windows SDK per Windows 7, disponibile in queste due posizioni:

Se si esegue una versione x64 di Windows, usare l'ISO, in modo che sia possibile specificare che si vuole la versione a 32 bit dell'SDK. Sos.dll è incluso solo nella versione a 32 bit di Strumenti di debug di Windows 7 per Windows.

Caricamento di mscordacwks.dll e sos.dll (debug live)

Si supponga che il debugger e l'applicazione sottoposta a debug siano in esecuzione nello stesso computer. .NET Framework usato dall'applicazione viene quindi installato nel computer ed è disponibile per il debugger.

Il debugger deve caricare una versione dell'applicazione livello dati uguale alla versione di CLR usata dall'applicazione di codice gestito. Anche il bit (a 32 bit o a 64 bit) deve corrispondere. L'applicazione livello dati (mscordacwks.dll) include .NET Framework. Per caricare la versione corretta dell'applicazione livello dati, collegare il debugger all'applicazione di codice gestito e immettere questo comando.

.cordll -ve -u -l

L'output dovrebbe essere simile a questo.

CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll
CLR DLL status: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

Per verificare che la versione di mscordacwks.dll corrisponda alla versione di CLR usata dall'applicazione, immettere uno dei comandi seguenti per visualizzare informazioni sul modulo CLR caricato.

lmv mclr (per la versione 4.0 di CLR)

lmv mscorwks (per la versione 1.0 o 2.0 del CLR)

L'output dovrebbe essere simile a questo.

start             end                 module name
000007ff`26710000 000007ff`2706e000   clr        (deferred)             
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
...

Nell'esempio precedente si noti che la versione di CLR (clr.dll) corrisponde alla versione dell'applicazione livello dati (mscordacwks.dll): v4.0.30319. Si noti anche che entrambi i componenti sono a 64 bit.

Quando si usa .cordll per caricare l'applicazione livello dati, l'estensione di debug SOS (sos.dll) potrebbe essere caricata automaticamente. Se sos.dll non viene caricato automaticamente, è possibile usare uno di questi comandi per caricarlo.

.loadby sos clr (per la versione 4.0 di CLR)

.loadby sos mscorwks (per la versione 1.0 o 2.0 del CLR)

In alternativa all'uso di .loadby, è possibile usare .load. Ad esempio, per caricare la versione 4.0 di CLR a 64 bit, è possibile immettere un comando simile a questo.

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

Nell'output precedente si noti che la versione dell'estensione di debug SOS (sos.dll) corrisponde alla versione di CLR e all'applicazione livello dati: v4.0.30319. Si noti anche che tutti e tre i componenti sono a 64 bit.

Caricamento di mscordacwks.dll e sos.dll (file dump)

Si supponga di usare il debugger per aprire un file dump (di un'applicazione di codice gestito) creato in un altro computer.

Il debugger deve caricare una versione dell'applicazione livello dati uguale alla versione di CLR usata dall'applicazione di codice gestito nell'altro computer. Anche il bit (a 32 bit o a 64 bit) deve corrispondere.

L'applicazione livello dati (mscordacwks.dll) include .NET Framework, ma si supponga di non avere la versione corretta di .NET Framework installata nel computer che esegue il debugger. Sono disponibili tre opzioni.

  • Caricare l'applicazione livello dati da un server di simboli. Ad esempio, è possibile includere il server di simboli pubblici di Microsoft nel percorso del simbolo.
  • Installare la versione corretta di .NET Framework nel computer che esegue il debugger.
  • Ottenere la versione corretta di mscordacwks.dll dalla persona che ha creato il file di dump (in un altro computer) e copiarlo manualmente nel computer che esegue il debugger.

In questo articolo viene illustrato l'uso del server di simboli pubblici di Microsoft.

Immettere questi comandi.

.sympath+ srv\* (Aggiungere il server dei simboli al percorso del simbolo).

!sym rumoroso

.cordll -ve -u -l

L'output sarà simile a questo.

CLRDLL: Unable to get version info for 'C:\Windows\Microsoft.NET
   \Framework64\v4.0.30319\mscordacwks.dll', Win32 error 0n87

SYMSRV:  C:\ProgramData\dbg\sym\mscordacwks_AMD64_AMD64_4.0.30319.18010.dll
   \5038768C95e000\mscordacwks_AMD64_AMD64_4.0.30319.18010.dll not found

SYMSRV:  mscordacwks_AMD64_AMD64_4.0.30319.18010.dll from 
   https://msdl.microsoft.com/download/symbols: 570542 bytes - copied         
...
SYMSRV:  C:\ProgramData\dbg\sym\SOS_AMD64_AMD64_4.0.30319.18010.dll
   \5038768C95e000\SOS_AMD64_AMD64_4.0.30319.18010.dll not found

SYMSRV:  SOS_AMD64_AMD64_4.0.30319.18010.dll from 
   https://msdl.microsoft.com/download/symbols: 297048 bytes - copied         
...
Automatically loaded SOS Extension
...

Nell'output precedente è possibile notare che il debugger ha prima cercato mscordacwks.dll e sos.dll nel computer locale in C:\Windows\Microsoft.NET e nella cache dei simboli (C:\ProgramData\dbg\sym). Quando il debugger non ha trovato le versioni corrette dei file nel computer locale, le ha recuperate dal server dei simboli pubblici.

Per verificare che la versione di mscordacwks.dll corrisponda alla versione di CLR usata dall'applicazione, immettere uno dei comandi seguenti per visualizzare informazioni sul modulo CLR caricato.

lmv -mclr (per la versione 4.0 di CLR)

lmv -mscorwks (per la versione 1.0 o 2.0 di CLR)

L'output dovrebbe essere simile a questo.

start             end                 module name
000007ff`26710000 000007ff`2706e000   clr        (deferred)             
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
...

Nell'esempio precedente si noti che la versione di CLR (clr.dll) corrisponde alla versione del prodotto dell'applicazione livello dati (mscordacwks.dll): v4.0.30319. Si noti anche che entrambi i componenti sono a 64 bit.

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:
...
Extension DLL chain:
    C:\ProgramData\dbg\sym\SOS_AMD64_AMD64_4.0.30319.18010.dll\...
        ...
    dbghelp: image 6.13.0014.1665, API 6.2.6, built Wed Dec 12 03:02:43 2012
...

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. DumpDomain o !sos. Comando Thread .

Note

A volte un'applicazione di codice gestito carica più di una versione di CLR. In questo caso, è necessario specificare quale versione dell'applicazione livello dati caricare. Per altre informazioni, vedere .cordll.