Debug dei file di dump in Visual Studio

Question

Utilizzo Visual Studio 2010 Professional Edition e Windows Vista.

In primo luogo, ho questo codice. Come puoi vedere, il programma si bloccherà!

using System; 

namespace Crash 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      string a = null; 

      if (a.Length == 12) 
      { 
       // ^^ Crash 
      } 
     } 
    } 
} 

Il programma si bloccherà sulla dichiarazione if. Ora, voglio scoprire che si è schiantato su quella dichiarazione if.

Se "Avvio senza debug" da Visual Studio, Crash.exe si arresta in modo anomalo. Usa 1,356kb di memoria. Ottengo l'opzione Vista di Close Program/Debug. Se scelgo Debug, posso aprire una nuova istanza di Visual Studio e mi indirizza a una NullReferenceException sull'istruzione if. Questo è buono.

Ora supponiamo che si arresti in modo anomalo su un altro computer e li induco a darmi un file di dump tramite Task Manager. È 54,567kb. Perché così grande! È vasto! Comunque, io sono meno interessato a che (un po ')

Se apro quella discarica con Windbg, ottengo molto poco utile al mio occhio inesperto:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 


Loading Dump File [C:\Users\Richard\Desktop\Crash.DMP] 
User Mini Dump File with Full Memory: Only application data is available 

Symbol search path is: SRV*C:\SYMBOLS*http://msdl.microsoft.com/download/symbols 
Executable search path is: 
Windows Server 2008/Windows Vista Version 6002 (Service Pack 2) MP (4 procs) Free x86 compatible 
Product: WinNt, suite: SingleUserTS Personal 
Machine Name: 
Debug session time: Sat Jan 15 11:07:36.000 2011 (UTC + 0:00) 
System Uptime: 0 days 4:24:57.783 
Process Uptime: 0 days 0:00:05.000 
........................ 
eax=002afd40 ebx=77afa6b4 ecx=002afd48 edx=00000001 esi=001cdaa4 edi=00000000 
eip=77bf5e74 esp=001cda5c ebp=001cdacc iopl=0   nv up ei ng nz ac pe cy 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000297 
ntdll!KiFastSystemCallRet: 
77bf5e74 c3    ret 

Tuttavia, questo è di minore interesse per me . Per quanto posso dire, ho bisogno di scrivere comandi per ottenere un utile output e Visual Studio è migliore.

Così lo apro con Visual Studio. Posso scegliere "Debug with Native Only", ma ho un sacco di cose che significano qualcosa per persone intelligenti come te, e io non sono intelligente! Ottengo questi due schermi:

Quindi, la mia domanda:

Come posso mostrare Visual Studio per il mio codice sorgente?

Inoltre, c'è un modo per ottenere un file di dump più piccolo? Sembra ridicolmente grande, anche dopo averlo compresso. Non capisco perché non ci possa essere uno che è solo un pochino più grande dell'impronta del programma, e che ottiene ancora un buon debugging, con il codice sorgente.

Answer 1

La funzione molto pubblicizzata che Visual Studio 2010 consente di eseguire il debug dei file di dettagli di arresto anomalo e di eseguire il codice sorgente gestito viene fornita con un trucco: funziona only for .NET 4.0 assemblies. Ecco i passaggi:

1. Creare un file di dettagli di blocco su un altro computer utilizzando il Task Manager
2. Aprire la soluzione in VS2010
3. Aprire il file .DMP (File-> Apri ...)
4. Fare clic su Debug With Mixed (Questo sarà visibile solo per .NET 4.0) Codice
5. Sorgente si aprirà e si sarà in grado di ispezionare l'esatta causa e la posizione dell'eccezione

Per quanto riguarda il debug con Visual Studio nativo solo è interessato non è più utile di WinDbg.

Answer 2

Si dovrebbe fornire al debugger il relativo file pdb (database del programma) in modo che possa caricare i simboli. Anche per ottenere una vista migliore, utilizzare il server Microsoft Public Symbol. This article contiene informazioni su di esso.

Answer 3

Gli strumenti che si utilizzano qui non sono stati progettati per la risoluzione dei problemi relativi ai programmi gestiti che si bloccano. Minidump e Windbg è quello che usi per scoprire cosa c'è che non va nel codice scritto in C o C++. Strumenti piuttosto importanti, sono lingue i cui runtime non hanno alcun supporto per il tipo di cose che puoi ottenere da un programma gestito in crash. Come un'eccezione con una traccia dello stack.

Il motivo per cui le dimensioni minidump sono così diverse è a causa del mini in minidump. In base alla progettazione, era destinato a catturare una piccola istantanea del processo. L'argomento pertinente è DumpType in MiniDumpWriteDump function. C'è un codice veramente intelligente in questa funzione che può capire quali parti dello stato del processo non devono essere registrate perché non è probabile che lo si utilizzi nella sessione del debugger. Quale è possibile ignorare fornendo ulteriori flag di dump type. Il minidump generato da Explorer ha tutte queste bandiere attivate, si ottiene l'intero kit e il caboodle.

Quale è in realtà piuttosto importante per un programma gestito. L'euristica utilizzata da questo creatore di minidump è quella appropriata solo per il codice non gestito. Il debug di un dump di un programma gestito funziona correttamente solo se si include l'intero heap di garbage collection nel dump. Sì, quella sarà una grande discarica, la mini non si applica più.

Il tuo prossimo problema è che stai ottenendo l'anima della vista macchina dai dati del minidump. Le tue schermate mostrano il codice della macchina. Ti capita di trovarti all'interno di Windows in questi scatti, nota come ntdll.dll è in cima allo stack. Le voci mscorwks.dll sono CLR. Più in basso, fuori dalla vista, dovresti vedere i frame dello stack dal tuo codice. Vedrai comunque il codice macchina che è stato generato dal compilatore JIT. Non il tuo codice C#.

C'è un componente aggiuntivo Windbg chiamato sos.dll che estende il set di comandi di Windbg per poter ispezionare i dati gestiti. Basta google "sos.dll" per ottenere buoni risultati. Questo è comunque ancora un lontano dal tipo di esperienza di debug che si otterrà dal debugger di Visual Studio. Che è intimamente consapevole del codice gestito, molto diverso da Windbg o dal debugger VS che può caricare minidump. Sos è stato davvero progettato per risolvere i bug CLR.

Non ci sono stati miglioramenti significativi in ​​VS2010 oltre alla pagina di informazioni minidump che ora vedi. Che in realtà non fa molto. Sospetto che il Debugger Team abbia questo nella loro lista delle cose da fare, ci sono sicuramente alcuni problemi fondamentali da superare. In particolare nel formato minidump e nel codice di creazione. Utilizza connect.microsoft.com per fornire feedback, prestano attenzione e lascia che i voti influenzino il loro elenco di priorità.