Come faccio a individuare la fonte di un'eccezione non gestita?

Question

Ho un'applicazione WinForms in cui io voglio essere in grado di fornire una funzione di editing HTML. Così ho tradotto HTML Writer di Lutz Roeder da C # in VB.NET, e convertito da una finestra formare in un controllo utente personalizzato, che ora è ospitata in un form MDI figlio.

Tutto funziona bene fino a quando chiudo il padre MDI, nel qual caso si blocca, e non posso intercettare l'eccezione.

Ho isolato il controllo editor di in un piccolo WinForms vaniglia app che non fa niente altro, e verificato che il problema si verifica ancora.

Inoltre ho acceso non gestito codice di debug (sto usando VS2010, compilare per x86 e Framework 3.5), e tutto quello che ottengo è questo:

Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.

L'unica cosa altra cosa che ho notato è che se lascio un lungo intervallo di tempo dopo l'apertura della maschera contenente l'editor, non in crash.

Quello che mi piacerebbe davvero apprezzare è alcune idee su come andare alla ricerca di questo problema. Può darsi, naturalmente, che ho fatto un errore nel C # per la conversione di VB, ma sto lottando per sapere dove guardare.

Modifica :

Ho eseguito l'applicazione con il debugger, e non mi dà niente di utile.

tutto quello che ottiene è il Windows 'applicazione ha smesso di funzionare' il messaggio, con questo nei particolari di problema:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: HtmlEditorMdi.exe
  Application Version:  1.0.0.0
  Application Timestamp:    4cfb74c7
  Fault Module Name:    mscorwks.dll
  Fault Module Version: 2.0.50727.4952
  Fault Module Timestamp:   4bebd49a
  Exception Code:   c0000005
  Exception Offset: 000022b5
  OS Version:   6.1.7600.2.0.0.256.1
  Locale ID:    2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

posso vedere che si tratta di una violazione di accesso, ma anche se vado Debug> Eccezioni> Eccezioni Win32 , e segno di spunta c0000005 , non ho ricevuto niente di utile, quando si rompe -. solo 'nessuna fonte disponibile'

Answer 1

Il primo messaggio che hai citato è prodotto dal gestore di heap di Windows quando si scopre che la struttura heap interna viene distrutta. Esso mostra che diagnostica quando vede che un debugger è collegato. Il blocco citato secondo è ciò che accade quando si ignora la diagnostica (senza debugger), si bombe su un'eccezione di hardware quando tenta di liberare memoria nell'heap danneggiato in ogni caso.

Il problema di danneggiamento di heap è che il vero danno è fatto molto tempo prima che si genera la diagnostica. Potete vedere una traccia dello stack che porta alla diagnosi nella finestra Stack di chiamate, è necessario abilitare il server di simboli Microsoft per ottenere simboli significativi per le funzioni di Windows. Ma non vi dirà qualcosa di utile per il codice che in realtà ha causato il danno, che richiede una macchina del tempo.

Questo tipo di danneggiamento di heap è invariabilmente causato dal codice non gestito. L'eccezione AccessViolation è una piaga ben noto a C / C ++ i programmatori e un grande motivo per cui il codice gestito è diventato popolare. Mentre Lutz' il codice sorgente è tutto gestito, contiene una molto di P / Invoke e COM interfaccia dichiarazioni. Non v'è alcun buon modo per eseguire il debug di loro, non c'è bisogno del codice sorgente.

Come una di quelle dichiarazioni sottilmente sbagliato quando li convertito in VB.NET è certamente un modo questo possa accadere. Potrebbe anche essere che il bug era sempre lì, ma capolino solo ora. Sei fortunato. Btw, non credo che il codice è a 64 bit pulita, costringerlo a correre in 32-mode per una possibile soluzione rapida. Per il vostro progetto EXE principale: Progetto + Proprietà, scheda Compile, scorrere verso il basso, avanzate opzioni di compilazione, di destinazione CPU = 86. Questo è rilevante solo se si esegue su una versione a 64 bit di Windows.

Oltre a questo, vi consiglio di utilizzare solo il progetto C # come-è. Mescolando lingue in una soluzione è uno scenario molto ben supportato in .NET.

Answer 2

Il WinDbg debugger è il "grande pistola" per questo tipo di problema. Si può spesso dare indizi parlandovi eccezioni gestite ecc L'unico problema è che non è facile da usare e ha una curva di apprendimento molto alto.