2012-12-05 11 views

risposta

12

Per l'approccio più semplice - vai al fondo per leggere la descrizione di come farlo con Visual Studio 2013.


Ora ci potrebbero essere alcuni nuovi strumenti - forse qualcosa in Visual Studio aggiornata e mi piacerebbe trovare su questi, ma ho cercato WinDbg prima con un certo successo. Qui sono i miei vecchi appunti su come farlo:

1. Create dump file from process manager 
2. Run WinDbg (X64) 
3. File/Open Crash Dump… (Crtl+D) 
4. Run following: 

lm 
.load C:\windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll 
.sympath SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols 
.symfix 
.reload 
!dumpheap -stat 

Nota che se il processo se x86, soprattutto se si esegue su una versione x64 di Windows - sarà necessario utilizzare una versione x86 del debugger (WinDbg invia entrambe le versioni) per salvare il dump. SOS, che è un'estensione di debug della memoria gestita per WinDbg non supporta il debug di dump x64 bit dei processi x86 bit. Sarà quindi anche bisogno di aggiornare il percorso sos, rispettivamente, così sembra che questo:

.load C:\windows\Microsoft.NET\Framework\v4.0.30319\sos.dll 

Forse non tutti questi comandi sono necessari, ma questo è ciò che ha funzionato per me.

Ora è possibile trovare il tipo di oggetto che sembra esistere in troppi casi

!DumpHeap -type TypeName 

dove nome del tipo è solo il nome del tipo - namespace non pienamente qualificato necessario.

Ora è possibile controllare ciò che mantiene questo oggetto in memoria:

!GCRoot Object_Address 

dal vivo il debug non ha funzionato per me dal momento che l'applicazione sembra avere sospeso quando si collega un debugger. Penso di aver visto un'opzione da qualche parte per far sì che l'app rimanga in memoria, ma ho dimenticato dove, ma per il profiling della memoria, guardare un file di dumping statico potrebbe essere sufficiente.


È possibile scaricare WinDbg come parte di Windows SDK o come download standalone di "Debugging Tools for Windows" da here.

Per creare un file di dettagli, andare su Task Manager, fare clic con il pulsante destro del mouse su proces e selezionare "Crea file di dettagli".


Alcuni altri link:

http://blogs.microsoft.co.il/blogs/sasha/archive/2012/10/15/diagnosing-memory-leaks-in-managed-windows-store-apps.aspx

http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx

http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/f3a3faa3-f1b3-4348-944c-43f11c339423

http://msdn.microsoft.com/en-us/library/bb190764.aspx

http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx


* EDIT

Secondo .NET Memory Allocation Profiling with Visual Studio 2012 da Stephen Toub - PerfView strumento supporta l'analisi perdite in applicazioni .NET di Windows Store. Controlla un articolo e una procedura video con Vance Morrison here.


* EDIT 2

Visual Studio 2013 Preview aggiunge una nuova opzione per analizzare cumuli memoria gestita dal file di dump. Per farlo, è sufficiente mettere in pausa l'app nel debugger di Visual Studio, salvare il dump corrente tramite Debug/Salva dump as, quindi riprendere l'esecuzione e utilizzare l'app fino a quando si verifica la perdita sospetta e fare un altro dump. Quindi vai su File/Apri/File e apri il secondo file di dettagli. A destra del sommario del dump nel pannello "Azioni" vedrai un'azione "Memoria gestita di debug". Selezionalo e quindi in "Seleziona linea di base" seleziona il tuo primo file di dettagli. Verrà visualizzato un elenco di oggetti nell'heap gestito, raggruppati per tipo, con differenze di conteggio. Si noti che in genere si osservano prima gli oggetti con differenze di conteggio basse, non nulle per tenere traccia di una singola origine di perdita. È possibile eseguire il drill nella lista degli oggetti e vedere cosa li tiene in memoria espandendo l'albero nella vista Graph di riferimento.

+0

Altri link più freschi: http://blogs.microsoft.co.il/blogs/sasha/archive/2012/10/15/diagnosing-memory-leaks-in -managed-windows-store-apps.aspx –

+0

Inoltre sembra che i file etl (Event Trace Log) che è possibile produrre usando il comando wpr (Windows Performance Recorder) e letti con wpa (Windows Performance Analyzer) possano essere utili per trovare perdite , anche se non l'ho ancora giocato. Controlla questi link che potrebbero contenere alcune informazioni utili http://www.idigitalhouse.com/Blog/?p=155 http://blogs.msdn.com/b/ntdebugging/archive/2012/11/30/troubleshooting-pool -leaks-part-7-windows-performance-toolkit.aspx –

+1

Le persone dovrebbero notare che l'opzione "Memoria gestita di debug" è disponibile solo in Visual Studio 2013 Ultimate e che il dump viene creato da un processo .NET 4.5. Maggiori informazioni qui: http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/20/using-visual-studio-2013-to-diagnose-net-memory-issues-in-production.aspx –

1
+0

Grazie! Dovrò provarlo! –

+1

Mi hanno twittato dicendo che supporta solo il tracciamento del lato gestito delle cose, ma che dovrebbe essere sufficiente per molte persone. –

+0

La domanda è stata codificata .net, quindi ho dimenticato di dire che non funzionerà (nell'ultima versione) con WinJS. Non sarei sorpreso di vederlo ad un certo punto. – kodefuguru

Problemi correlati