2013-08-20 13 views
33

Il mio client ha un'applicazione ASP.NET installata su due server di produzione (bilanciati con NLB, ma è irrilevante). Entrambi incidente server ogni 3-4 ore con il seguente Visualizzatore eventi errore registrato:Come eseguire il debug di errore w3wp clr.dll

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
Faulting module name: clr.dll, version: 4.0.30319.18034, time stamp: 0x50b5a783
Exception code: 0xc00000fd Fault offset: 0x000000000001a840
Faulting process id: 0xd50
Faulting application start time: 0x01ce97fe076d27b4
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Report Id: e0c90a5f-0455-11e3-8f0e-005056891553

non ho idea di come eseguire il debug o dove iniziare. Quando si verifica l'arresto, l'utilizzo del processore server passa al 100% e rimane lì. Il processo in errore è w3wp.exe. Non sono nemmeno sicuro se il mio codice sta generando l'errore o meno. È IIS 7.5. Qualsiasi suggerimento sarebbe molto apprezzato.

risposta

56

Sembra che tu abbia un'eccezione StackOverflow, causata da una ricorsione illimitata (una funzione che si chiama ripetutamente, ecc.). Questo non può essere catturato dal normale blocco try/catch. È possibile rintracciare il problema utilizzando DebugDiag e WinDbg.

DebugDiag può essere configurato per generare un crash dump quando si verifica StackOverflowException. Scarica a https://www.microsoft.com/en-us/download/details.aspx?id=49924.

  1. Aprire DebugDiag e fare clic su Aggiungi regola.
  2. "Blocco" dovrebbe essere già selezionato. Fare clic su Avanti.
  3. Scegliere "Un pool di applicazioni Web IIS specifico" e fare clic su Avanti.
  4. Selezionare il pool di applicazioni e fare clic su Avanti.
  5. Si dovrebbe essere nella finestra di configurazione avanzata. Fai clic su Eccezioni in Impostazioni avanzate.
  6. Fare clic su Aggiungi eccezione e selezionare Overflow di stack con un tipo di azione di Userdump completo
  7. Fare clic su OK, salvare e chiudere.

La prossima volta che si verifica una StackOverflowException, si verificherà un arresto anomalo del sistema. Ora è necessario interpretare il file di dump.

Gli strumenti di debug per Windows fanno parte di Windows SDK e possono essere scaricati allo http://msdn.microsoft.com/en-US/windows/hardware/gg463009/.

  1. Per utilizzare WinDbg, è necessario ottenere i file di simboli. Download the symbol files e inserirli in una cartella locale.
  2. Aprire WinDbg. Nel menu File, fare clic su Symbol File Path.
  3. Nella casella Percorso simbolo, la documentazione dice di digitare il seguente comando: SRV*your local folder for symbols*http://msdl.microsoft.com/download/symbols, tuttavia ho appena inserito la cartella locale per i simboli e ha funzionato correttamente.
  4. Uscire e aprire nuovamente WinDbg e aprire il crash dump e individuare il file di dump creato da DebugDiag.
  5. Nella riga di comando, tipo .loadby sos clr
  6. Ora digitate !CLRStack

Nei risultati, dovrebbe essere chiaro quale sia il problema (è probabile vedere un gruppo di linee che mostra la funzione (s) che è stato ripetutamente chiamato).

+0

Domanda correlata: http://stackoverflow.com/questions/6019674/how-to-debug-crashed-dump-file – MikeSmithDev

+0

Ho provato questo, preso un dump, ottenuto alcuni simboli di debug e ora ho il seguente errore quando caricamento del dump: '*** ERRORE: il file simbolo non è stato trovato. Predefinito per esportare i simboli per ntdll.dll - Questo file di dump ha un'eccezione di interesse memorizzata in esso. È possibile accedere alle informazioni sulle eccezioni memorizzate tramite .ecxr. ... *** ERRORE: il file simbolo non è stato trovato. Predefinito per esportare i simboli per clr.dll - *** ATTENZIONE: impossibile verificare il checksum per mscorlib.ni.dll *** ERRORE: caricamento del modulo completato ma i simboli non possono essere caricati per mscorlib.ni.dll' – cristi71000

+0

OOps, il mio male, ora ho caricato il dump senza errori ma quando faccio '! CLRStack' dice 'Impossibile caricare la DLL di accesso ai dati' – cristi71000

1

Alcune aggiunte alla risposta di cui sopra. Sviluppa l'estensione Explorer che ha ottenuto un errore all'accesso dell'utente.Quindi per l'utente sembra "schermo lampeggiante" (mentre explorer tenta di avviarsi e bloccarsi, quindi di riavviare ecc.). Connesso sotto un altro account utente installato DebugDiag e WinDbg. Sto usando Windows 8.1 con .Net 4.0 con tutti gli ultimi aggiornamenti su oggi (13 gennaio 2014) Ho provato a scaricare pochi simboli localmente, ma WinDbg non può caricare clr.pdb a causa di signaure errato.

Risolto utilizzando simboli online: utilizzare "SRV * http://msdl.microsoft.com/download/symbols" come percorso dei simboli.

0

Un'altra causa potrebbe "funzione ricorsiva infinita". Quando si verifica un ciclo infitine, Windows tenta di evitare il deadlock e disabilita il pool di applicazioni relazionato.

Ho incontrato lo stesso numero oggi. Ho una funzione ricorsiva che elenca il progetto parentproject-sub. Un progetto è stato impostato come progetto principale e quando la funzione ricusiva tenta di elencare tutti i progetti parent-sub, si verifica un loop infinito.

0

sono stato in grado di controllare Visualizzatore eventi -> Registri di Windows -> Sistema e trovare

Application pool 'DankAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

Sotto:

A process serving application pool 'DankAppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '5704'. The data field contains the error number.

E:

The QueueMonitor service terminated unexpectedly. It has done this 32 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service.

Almeno la QueueMonitor il servizio è un punto di partenza.