Eseguire il debug di un dump della memoria gestita con analizzatori di diagnostica .NET

Questa esercitazione illustra come:

• Apertura di un dump della memoria
• Selezionare ed eseguire analizzatori sul dump
• Esaminare i risultati degli analizzatori
• Passaggio al codice problematico

Nell'esempio descritto in questo articolo, il problema è che l'app non risponde alle richieste in modo tempestivo.

Apertura di un dump della memoria in Visual Studio

1. Aprire il dump della memoria in Visual Studio usando il comando di menu File > apri > file e selezionare il dump della memoria.

2. Si noti che nella pagina Riepilogo dump della memoria viene visualizzata una nuova azione denominata Esegui analisi diagnostica.

   

3. Selezionare questa azione per avviare il debugger e aprire la nuova pagina Analisi diagnostica con un elenco delle opzioni di analizzatore disponibili, organizzate in base al sintomo sottostante.

Selezionare ed eseguire analizzatori sul dump

Per analizzare questi sintomi, le opzioni migliori sono disponibili in Velocità di risposta del processo in quanto corrisponde meglio al problema in questo esempio.

1. Fare clic sul pulsante Analizza per avviare il processo di indagine

2. L'analizzatore presenterà i risultati in base alla combinazione di informazioni sul processo e dati CLR acquisiti nel dump della memoria.

Esaminare i risultati degli analizzatori

1. In questo caso, l'analizzatore ha rilevato due errori. Selezionare il risultato dell'analizzatore per visualizzare il riepilogo dell'analisi e la correzione suggerita.

   

2. Il riepilogo dell'analisi ha dichiarato che il "pool di thread CLR sta riscontrando una fame". Queste informazioni suggeriscono che CLR ha attualmente usato tutti i thread del pool di thread disponibili, il che significa che il servizio non può rispondere alle nuove richieste finché non viene rilasciato un thread.

   Nota

   La correzione in questo caso è "Non attendere in modo sincrono su monitoraggi, eventi, attività o altri oggetti che potrebbero bloccare il thread. Verificare se è possibile aggiornare il metodo in modo che sia asincrono.

Passaggio al codice problematico

Il mio prossimo lavoro consiste nel trovare il codice problematico.

1. Facendo clic sul collegamento Mostra stack di chiamate, Visual Studio passerà immediatamente ai thread che presentano questo comportamento.

2. La finestra Stack di chiamate mostrerà metodi che potrebbero potenzialmente distinguere rapidamente il codice (SyncOverAsyncExmple.) dal codice Framework (System.).

   

3. Ogni stack frame di chiamate corrisponde a un metodo e facendo doppio clic sugli stack frame di Visual Studio passerà al codice che ha portato direttamente a questo scenario in questo thread.

4. In questo esempio non sono presenti simboli o codice, ma nella pagina Simboli non caricati è possibile selezionare l'opzione Decompile Source code (Codice sorgente decompilazione).

   

5. Nell'origine decompilata seguente è evidente che un'attività asincrona (ConsumeThreadPoolThread) chiama una funzione di blocco sincrono.

   Nota

   Metodo "DoSomething()" che contiene un metodo WaitHandle.WaitOne che blocca il thread del pool di thread corrente finché non riceve un segnale.

   Per migliorare la velocità di risposta delle app, è importante rimuovere il blocco del codice sincrono da tutti i contesti asincroni.

   

Contenuto correlato

• Usare i file dump nel debugger
• Generare codice sorgente da assembly .NET durante il debug
• Specificare file di simboli (PDB) e di origine