Come risolvere i messaggi di segnalazione errori .NET 2.0 nel registro eventi?
https://stackoverflow.com/questions/814560
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Lavoro su un prodotto open source chiamato EVEMon scritto in C # destinato alla piattaforma .NET 2.0, I avere un utente che soffre di uno strano arresto anomalo di .NET che non siamo riusciti a risolvere.
Event Type: Error Event Source: .NET Runtime 2.0 Error Reporting Event Category: None Event ID: 5000 Date: 4/29/2009 Time: 10:58:10 PM User: N/A Computer: removed this Description: EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4 system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9 system.argumentexception, P10 NIL. Data: //hex representation of the above Description
L'applicazione stessa si arresta in modo anomalo senza visualizzare un errore (nonostante abbia un errore nella gestione dell'interfaccia utente), i messaggi precedenti sono stati copiati dal registro eventi di Windows. L'utente finale ha reinstallato .NET e aggiornato alle ultime versioni. I file .PDB sono distribuiti con ogni versione di rilascio del programma per facilitare il debug e il test, l'utente con il problema in questione ha la gamma completa di file PDB per la versione corretta di EVEMon.
Esiste una tecnica specifica, provata e testata per analizzare e diagnosticare questo tipo di incidente? e in caso affermativo, quali strumenti e tecnologie sono disponibili per facilitare il debug?
Ringraziamenti speciali
Vorrei ringraziare in particolare Steffen Opel e sottolineare che la sua risposta pur non rispondendo direttamente alla domanda che stavo ponendo, ha affrontato il problema più grande con la mia base di codice che nella gestione globale degli errori mancava un componente importante.
Soluzione
Ecco come affronterei il problema per un utente finale con un arresto anomalo.
-
Scarica e installa gli strumenti di debug per Windows all'indirizzo http: // www .microsoft.com / WHDC / devtools / debug / default.mspx
-
Una volta installati gli strumenti (finiscono per accedere a C: \ Programmi \ per impostazione predefinita) avviare una finestra della riga di comando.
-
Passa alla directory che contiene adplus (ad es. " C: \ Programmi \ Strumenti di debug per Windows (x86) ").
-
Esegui il comando follwing. Ciò avvierà l'applicazione e allegherà adplus.
adplus -crash -o C: \ debug \ -FullOnFirst -sc C: \ path \ to \ your \ app.exe
Dopo aver creato il dump dell'arresto anomalo
Dopo l'arresto anomalo dell'applicazione, avviare WinDbg e caricare il file .dmp creato in C: \ debug. (File - > Open Crash Dump)
Esegui questi comandi per vedere la traccia dello stack e speriamo di trovare il problema.
Per caricare SOS per il debug
- Pre .NET 4.0
.loadby sos mscorwks
- .NET 4.0
.loadby sos clr
Per vedere la traccia dello stack
!clrstack
Per vedere una traccia dello stack più utile
!clrstack –p
Per colpire dentro un oggetto ... forse vedi cosa ha causato l'eccezione
!do <address>
es. Questo è il risultato di un'applicazione che ha generato un errore casuale con un'eccezione IO. WinDbg ha indicato il percorso a cui si faceva riferimento che non era corretto.
0:009> !do 017f2b7c
Name: System.String
MethodTable: 790fd8c4
EEClass: 790fd824
Size: 124(0x7c) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: \\server\path\not_here.txt
Fields:
MT Field Offset Type VT Attr Value Name
79102290 4000096 4 System.Int32 1 instance 54 m_arrayLength
79102290 4000097 8 System.Int32 1 instance 53 m_stringLength
790ff328 4000098 c System.Char 1 instance 5c m_firstChar
790fd8c4 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00161df8:790d884c <<
7912dd40 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00161df8:014113e8 <<
Altri suggerimenti
Una sbirciatina nel codice sorgente (trunk) indica che la gestione delle eccezioni non gestita sembra essere incompleta rispetto alle applicazioni di Windows Form:
Devi gestire entrambe le eccezioni di thread non UI e le eccezioni di thread UI:
-
Per il primo è necessario implementare un gestore eccezioni non gestite CLR tramite
AppDomain.CurrentDomain.UnhandledException, che è già in atto. -
Per quest'ultimo è necessario implementare un gestore eccezioni non gestite di Windows Form tramite
Application.ThreadException, che sembra mancare; questo potrebbe effettivamente produrre esattamente quei problemi a cui stai assistendo. Per un esempio di implementazione, consultare la documentazione MSDN di Application.ThreadException evento .
Si noti che in questo momento si sopprime esplicitamente la cattura di eccezioni di Windows Form non gestite tramite Application.SetUnhandledExceptionMode (UnhandledExceptionMode.ThrowException) , è necessario modificarlo in UnhandledExceptionMode.CatchException per abilitare il routing al gestore per Application.ThreadException , come già correttamente suggerito da Jehof.
Quale sistema operativo (Windows XP, Windows Vista, ecc.) utilizza l'utente?
Se Windows Vista tenta di disabilitare " Funzionalità di risoluzione dei problemi e soluzioni " (Pannello di controllo - > Rapporti problemi e soluzioni - > Modifica impostazioni - > Impostazioni avanzate - > Disattiva per i miei programmi, segnalazione problemi)
O prova a impostare
Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );
Questo instraderà sempre le eccezioni al gestore ThreadException.
In breve: esiste un'eccezione non gestita nell'applicazione.
Se si dispone dell'accesso alla macchina (tramite accesso remoto, ecc.), provare a installare Visual Studio Express e avviare l'applicazione. Dovresti vedere una finestra di dialogo che offre la possibilità di eseguire il debug dell'applicazione con una nuova istanza di Visual Studio.
Potrebbe anche esserci qualcosa che impedisce l'inizializzazione corretta di Windows Form. Ho visto post nei forum che suggeriscono che i problemi con i caratteri possono causare questo: assicurati che gli utenti abbiano i caratteri installati di cui l'applicazione ha bisogno oltre ai soliti valori predefiniti come MS SansSerif, Arial, Tahoma, Times e simili.
E in mancanza ... prova a sacrificare un pollo sul PC. Funziona sempre con un incantesimo!
Abbiamo riscontrato problemi con le eccezioni in Thread-Code. Se si genera un nuovo thread e si dimentica di gestire un'eccezione nel metodo thread, l'applicazione si ferma "quot". - nessun messaggio di errore, niente di niente, ma solo una voce nel registro eventi. Nemmeno allora UnhandledExceptionHandler viene attivato.
Forse qualcosa del genere è la causa?
... se riesci a contattare quell'utente sofferente, ecco un
Idea: registra le fasi di pre-esecuzione
Invece di creare un collegamento al tuo program.exe , crea un collegamento a program.bat , che
echo "Pre-start" > stage.txt
start program.exe
La prima riga di Program.cs sarà quindi
File.WriteAllLines("stage.txt", "Program execution started.");
Nel gestore di AppDomain.UnhandledException la prima riga sarà
File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");
Inoltre, assicurarsi che il gestore non alloca memoria o risorse: pre-allocarle all'avvio dei programmi. Il gestore attiva solo la scrittura nel registro.
Commenti
È molto probabile che il stage.txt (inviato dall'utente) conterrà " Pre-start " ;. Ciò accade quando viene generata un'eccezione nel file .dll di terze parti, anche prima che il programma sia avviato.
In quel caso avrai bisogno di un semplice programma di controllo, che non farà riferimento agli assembly che program.exe fa, ma Assembly.Load (...) loro.
P.S.
stage.txt dovrebbe essere posizionato da qualche parte in% APPDATA%, non in Programmi.
Ho trovato un caso interessante su Server 2003 e un'altra bella discussione .
Dovresti ottenere una traccia dello stack più dettagliata inviando il file .pdb per quella particolare versione all'utente (da mettere accanto al .exe ) e avendo riproducono il crash.
Dovresti gestire AppDomain.UnhandledException nel codice.
C'era un domanda simile posta. Vedi anche quelli correlati.
