Quali possibilità ci sono per l'analisi post mortem in .NET (ad es. Dopo un arresto anomalo di un programma)?

Question

Supponiamo che esista un programma C #, che viene utilizzato come servizio di Windows. Supponiamo che il servizio sia impazzito e stia consumando CPU e memoria come un matto. Deve essere riavviato molto presto, perché è un sistema di produzione. Quindi non ho molto tempo per raccogliere informazioni sul runtime. Forse una rapida occhiata al task manager ... tutto qui.

Dopodiché, tutto ciò che ho sono i file di log log4net e il registro eventi di Windows per l'analisi post mortem.

Supponi di aver scoperto il motivo del problema. Qualcun altro lo risolve e forse il programmatore aggiunge qualche registrazione aggiuntiva, quindi la prossima volta posso trovare un problema simile più velocemente. Tuttavia: dipendo ancora dalla qualità dei file di registro e spero che la prossima volta un problema si sveli in qualche modo alle registrazioni.

Esistono anche altri modi per eseguire l'analisi post mortem? Forse qualcosa come i dump del thread (come in Java), i dump della memoria o qualcos'altro, che possono essere di aiuto nell'analisi post mortem? Forse uno strumento .NET Framework incorporato può essere d'aiuto?

Sono molto interessato alle esperienze di progetto reali e al modo in cui proveresti ad affrontare questa domanda di manutenzione, che penso sia molto reale per la maggior parte dei programmatori.

Answer 1

Come Marc dice che WinDbg + SoS ti consentirà di eseguire il debug di molti problemi, non puoi davvero occuparti di Visual Studio. Ci sono alcuni tutorial eccellenti questo blog .

Per problemi di memoria è anche possibile consultare i contatori delle prestazioni .NET in Perfmon. Puoi vedere dove si trovano gli oggetti (quale generazione) e quanto tempo viene impiegato nella raccolta dei rifiuti. Questo dovrebbe darti alcune informazioni utili. Se vuoi sapere perché l'oggetto non viene raccolto WinDbg e SoS è la strada da percorrere. Per guidarti attraverso una semplice sessione i passaggi sono:

1. Ispeziona l'heap usando !dumpheap -stat, cerca un gran numero di istanze. Probabilmente hai qualche idea di cosa ti aspetteresti di trovare nell'heap in un dato momento, quindi se qualcosa sembra fuori dall'ordinario, guarda in quello.

2. Scegli un'istanza casuale e fai un !gcroot sull'indirizzo dell'istanza. Questo ti dirà perché l'oggetto non viene raccolto.

3. Ripeti

Probabili candidati per mantenere le cose in vita più a lungo di quanto dovrebbero essere: eventi, statistiche e la coda del finalizzatore per citarne alcuni.

Potresti anche dare un'occhiata alla mia risposta per questa domanda per vedere più cose su WinDbg.

Answer 2

Puoi eseguire crash dump con .NET e guardarli con windbg / sos (e sosassist). Non semplice, ma funziona. Ma abbastanza hardcore. Ricerche su & Quot; + windbg + .NET & Quot; dovrebbe rivelarsi interessante.

Diverso da quello: contatori di risorse? log files? Molte cose che potresti guardare possono essere abilitate abbastanza facilmente.

Answer 3

Sfortunatamente ho dovuto fare un bel po 'di questo - lo strumento migliore che ho trovato è cordbg che viene fornito con sdk (avrai bisogno della versione corretta per la tua versione .net). http://msdn.microsoft.com/en-us/library/a6zb7c8d. aspx per i dettagli.

Collega al processo in esecuzione in cordbg (a < [pid] >), collega a ciascun thread in esecuzione (t < [tid] >) quindi dump la pila per ogni thread (w).

L'automazione di questa attività con un piccolo script vb e quindi il dumping su un file ti consentirà di eseguire questo strumento diverse volte, catturando l'output in un file. Il confronto di tutti gli stack di thread ti darà un'ottima idea di dove la tua applicazione sta spendendo tempo.

La cosa bella di questo approccio, specialmente con l'automazione dei dump, è che puoi prendere molto rapidamente tutte le informazioni e riavviare il tuo processo nel minor tempo possibile.

Answer 4

Una grande risorsa per l'analisi post mortem con WinDbg e SOS è serie di post di blog sull'argomento.

EDIT: collegamento aggiornato

Answer 5

Se il processo è ancora attivo, è possibile eseguire Managed Stack Explorer contro di esso per ottenere una rapida istantanea di ciò che sta facendo. Puoi eseguirlo senza un'installazione esplicita.

A parte questo, un dump completo + windbg + SOS ti dà il maggior numero di informazioni, ma ottenerlo non è banale.