Come si esegue il debug di un errore .net Fatal Execution Engine?

Question

Come sviluppatore, sto provando a configurare un ambiente di sviluppo sul nostro nuovissimo server VMWare ESX. Le cose non stanno risolvendo: da qualche parte durante il Prodotto SharePoint & tecnologie configurazione guidata, l'applicazione scompare, e in caso log trovo il seguente errore:

.NET Runtime versione 2.0.50727.3082 - Fatal Error motore di esecuzione (7A0979C6) (80131506)

Ora so tutto questo suona sospettosamente come un problema di stile ServerFault.com (e un messaggio di errore molto generico, un sacco di visite simili su Google), e, naturalmente, ci sono affrontare la questione in tale un modo (installazione/disinstallazione di service pack/hotfix, diverse versioni os, test dei singoli elementi dell'installazione, impostazioni diverse per il vm, ecc.), ma per interesse personale mi piacerebbe e per ottenere un po 'più di comprensione del problema, quindi "installa l'hotfix XXYY e spera che vada via". Mi chiedevo: Come approccio questo errore dal punto di vista di un programmatore?

• Posso in qualche modo fermare un debugger quando si verifica questo problema, o manualmente puntarlo all'indirizzo indicato (in quale modulo)?
• Devo provare ad installare utilizzare Visual Studio per questo o utilizzare strumenti di livello inferiore come windbg?
• Quali sono questi codici di errore esattamente? Quest'ultimo sembra un errore com. L'altro è un indirizzo?
• Posso in qualche modo attivare segnalazioni di errori più dettagliate? Un errore .dll sarebbe bello.

Si può dire che non sono affatto esperto nel debug di questo livello in un ambiente .net, ma sono molto disposto ad apprendere. Qualsiasi suggerimento è il benvenuto!

p.s. Quando provo a eseguire lo strumento di configurazione della riga di comando psconfig per eseguire una configurazione non UI, la maggior parte dei comandi, se non tutti, attivano StackOverflowException. Di nuovo, da dove vado?

Answer 1

Risposta breve: leggere il blog di Tess Ferrandez. Questo contiene molte indicazioni preziose per il debug di applicazioni .NET e ti guida attraverso come farlo.

Più rispondere ...

all'interno di Visual Studio

Se si dispone di Visual Studio installato si potrebbe provare a rompere su ogni eccezione non gestita .NET. Per abilitarlo, vai al menu e scegli Debug, Exceptions e spunta Eccezioni di Common Language Runtime. Quindi vai su Strumenti, Opzioni, Debug e deseleziona Abilita solo il mio codice. Infine, allegare al processo della Configurazione guidata (ovviamente è necessario eseguirlo prima) e il debugger di Visual Studio si interromperà al punto in cui si verifica l'eccezione.

Supponendo che il debugger si interrompa (se non è stato collegato al processo errato), allora si dovrebbe avere accesso allo stack delle chiamate e si possono fare alcune ipotesi formulate dai nomi dei metodi su cosa sta andando male. Tuttavia c'è una possibilità che questo è offuscato che non sarà utile. Sarà inoltre possibile visualizzare l'istruzione MSIL corrente su cui è stato interrotto il debugger. È qui che inizia ad andare un po 'oltre me ma ci sono buone referenze là fuori per aiutarti a capire cosa sta succedendo nel codice.

Senza Visual Studio

Se non hanno Visual Studio o per qualche motivo non può ottenere il debugger per rompere, allora è possibile creare un dump del processo di crash. Ci sono due metodi che conosco. Uno è described by the Windows Server Performance Team usando il buon vecchio dottor Watson. L'altro è un nuovo strumento appena rilasciato da Mark Russinovich chiamato ProcInfo che può creare automaticamente un dump di un processo che si arresta in modo anomalo attraverso le eccezioni non gestite. Ci sono probabilmente altri metodi.

Una volta scaricato il dump, è possibile utilizzare this KB article per facilitare l'impostazione del debug.

Infine

Ritorna alla 'risposta breve' sopra: leggere il blog Tess' di progredire ulteriormente! Questo è un grande argomento e ha le migliori risorse che ho trovato. Inoltre c'è un buon post by Vincent Rothwell che potrebbe essere d'aiuto ma è davvero mirato al debug del tuo codice.

Per non parlare delle eccezioni. Indica un problema piuttosto serio. Guarderei corruzione, gravi errori hardware e prendere in considerazione una ricostruzione.