Rilevare se un'eccezione è un'eccezione di stato danneggiato

Question

Ho un codice che sta chiamando Rotativa, che chiama wkhtml2pdf. Sospetto dal comportamento che sto vedendo che wkhtml2pdf.exe sta causando un'eccezione di stato corrotta (CSE) per essere generata. Voglio catturare e registrare un CSE se lanciato, così posso rintracciare dove sta accadendo.

Quando lascio l'applicazione in esecuzione durante la notte nel debugger, quando torno VS ha shutdown. A volte è ricominciato, a volte no. Sospetto della corruzione della memoria Ho iniziato a fare ricerche e sono incappato nella gestione di CSE.

che sto facendo qualcosa di simile:

[HandleProcessCorruptedStateExceptions] 
void DoStuff() 
{ 
    try 
    { 
      DOThatThingThatMakesTheDebuggerHaltAndShutDown(); 
    } 
    catch(Exception ex) 
    { 
      //how do I detect that it's a CSE in here, so I can log it especially blatantly 
    } 
} 

C'è un modo per rilevare se l'eccezione è un motore di ricerca personalizzato in generale Catch?

Ho visto un kludge in cui hanno 2 clausole di eccezione generale. Quello interno non gestisce i CSE e imposta una bandiera. Se quello esterno viene chiamato senza bandiera, allora è un CSE, ma spero in qualcosa di più pulito. Voglio fare è registrare questo stato negativo, quindi passarlo all'applicazione per insaponare normalmente.

Quando guardo l'errore nel registro eventi che ha portato giù VS2013 ottengo questo:

Applicazione: devenv.exe Versione quadro: v4.0.30319 Descrizione: Il processo è stato terminato a causa di un non gestita eccezione. Eccezione Info: codice eccezione c0000005, indirizzo di eccezione 4DA44C1F Stack: a Microsoft.VisualStudio.Debugger.Clr.NativeDkmClrModuleInstance.ProcF4BC786AEBAC294EE9C4C0BB1B0F56A7 (IntPtr, IntPtr ByRef) a Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance.GetMetaDataImport() a Microsoft.IntelliTrace.Concord.MetadataHelper..ctor (Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance) a Microsoft.IntelliTrace.Concord.Integration.CpdeNotifyPointServiceAdapter.InstallBreakpoint (Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance, Microsoft. VisualStudio.Debugger.Interop.Internal.NP_INSTALL_REQUEST)
a Mi crosoft.IntelliTrace.Concord.Integration.CpdeNotifyPointServiceAdapter.BindToModule (Microsoft.VisualStudio.Debugger.Clr.DkmClrModuleInstance) a Microsoft.IntelliTrace.Concord.IntelliTraceProcessState.AlertModuleLoad (Microsoft.VisualStudio.Debugger.DkmModuleInstance) a Microsoft.IntelliTrace. Concord.NotifyPoints.NotifyPointManager.OnModuleInstanceLoad (Microsoft.VisualStudio.Debugger.DkmModuleInstance, Microsoft.VisualStudio.Debugger.DkmWorkList, Microsoft.VisualStudio.Debugger.DkmEventDescriptorS) a Microsoft.VisualStudio.Debugger.EntryPoint.IDkmModuleInstanceLoadNotification_OnModuleInstanceLoad (IntPtr, IntPtr , IntPtr, IntPtr)

seguito da questo:

Faulting nome dell'applicazione: devenv.exe, Versione: 12.0.30501.0, tempo timbro: 0x5361f453 Faulting nome del modulo: vsdebugeng.impl.DLL, Versione: 12.0.30501.0, tempo bollo: 0x5361f482 Codice eccezione: 0xc0000005 Offset di errore: 0x00094c1f ID processo di errore: 0x1c9c Applicazione di errore ora di avvio: 0x01cfe7cc0cf50465 Percorso di applicazione di errore: C: \ Programmi File (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ devenv.exe Faulting percorso modulo: C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ Packages \ Debugger \ vsdebugeng.impl.DLL Relazione Id: 097b17c6-5438-11e4-8409-001f2904053c

Answer 1

Tieni presente che non esiste una "CorruptedStateException". È solo una parola da collezione, un insieme di eccezioni che il team CLR ha scelto come "eccessivamente cattivo". Non hanno intenzionalmente documentato il tipo di eccezioni che hanno inserito in quel set, a parte che ci sono "circa una dozzina" e che hanno iniziato come eccezioni di Windows SEH. L'unico che conosco che è sicuramente in quel set è AccessViolationException. Quello che si è schiantato contro VS nel tuo caso. Abbastanza comune, tanto brutto come vengono.

La funzionalità è stata aggiunta a .NET 4.0 per aiutare i programmatori a fare ciò che si fa, catturando tutte le eccezioni con catch (Exception). E poi lasciando che il programma continui a funzionare. Questo ha un talento per i maltrattamenti, ma cattura anche le eccezioni veramente sgradevoli, il tipo che non dovrebbero mai prendere perché sono garantite per essere irrecuperabili. Spesso inconsapevolmente. L'errore del programma che provoca questo è molto difficile da diagnosticare, può essere un po 'di tempo prima che il comportamento scorretto sia rilevabile.

Posso ipotizzare quali altre eccezioni SEH sono presenti nel set. Ma quello è solo supposizioni. Il punto chiave è che non hai avere per sapere. Qualsiasi metodo con [HandleProcessCorruptedStateExceptions] dovrebbe essere un gestore di eccezioni esterno, attivato al thread-entry. Mi piace Main(). E fare molto piccolo, il tipo di cosa che un gestore SEH dovrebbe fare, basta che l'utente sappia perché il programma ha fallito e chiama Environment.FailFast().

Quindi la programmazione catch (Exception)senza l'attributo ora è a posto, il CLR lo salterà quando cerca un gestore. Non puoi ingoiare accidentalmente le cose cattive. Il tuo caso è forse un po 'diverso, sembra un add-in senza un punto di accesso ben definito. Sposta il corpo del metodo con try/catch in un altro metodo e ometti l'attributo su quello. Per essere chiamato con il metodo con l'attributo, ora si può tranquillamente supporre che abbia preso uno di quelli cattivi.

E assicuratevi, ovviamente, di non lasciare VS in esecuzione quando si cattura. Lo stato del debugger viene fatto a pezzi, la sessione di debug è sicuramente finita, il programmatore che tenta di continuare a usarlo finirà male. Quindi visualizza una finestra di messaggio e fallisci veloce o ripeti.