Il debugger VS2008 non si interrompe in caso di eccezione non gestita

Question

Ho un problema strano con il mio debugger vs. Quando eseguo il mio programma con il debugger vs, il debugger non si rompe su un'eccezione non gestita. Al contrario, il controllo viene restituito a VS come se il programma uscisse normalmente. Se guardo nella scheda di output, c'è un'eccezione di prima possibilità elencata poco prima della fine del thread.

Comprendo come utilizzare " Eccezioni " dal menu Debug. Ho verificato l'interruzione delle eccezioni non gestite. Se controllo le eccezioni alla prima possibilità per l'eccezione specifica che si sta verificando, il debugger si interromperà.

Tuttavia, intendo che il debugger dovrebbe anche interrompere qualsiasi "Eccezione non gestita". Non lo sta facendo per me.

Ecco le ultime righe della mia scheda Output:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).

Non capisco perché l'eccezione sia flagges come "prima possibilità" eccezione quando non viene gestita.

Credo che il codice di uscita 0xe0434f4d sia un errore COM generico.

Qualche idea?

Metro.

Answer 1

Se utilizzi un sistema operativo a 64 bit, c'è una buona probabilità che tu sia morso da un comportamento a livello di sistema operativo che fa scomparire le eccezioni. Il modo più affidabile per riprodurlo è creare una nuova applicazione WinForm che genera semplicemente un'eccezione in OnLoad; sembrerà non essere lanciato. Dai un'occhiata a questi:

1. Visual Studio non si interrompe su un'eccezione non gestita con Windows a 64 bit
   • http: // social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb
2. Il caso dell'eccezione OnLoad che scompare
3. Eccezioni silenziose su macchine di sviluppo x64 (Microsoft Connect)
   • https: // connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

Il primo è quello che ho trovato da Google (dopo che questa discussione non ha aiutato) e quella discussione mi ha portato ai seguenti due. Il secondo ha la migliore spiegazione e il terzo è il bug / ticket Microsoft (che ribadisce che si tratta di "comportamento" in base alla progettazione).

Quindi, in sostanza, se l'applicazione genera un'eccezione che raggiunge un limite in modalità kernel durante il backup dello stack, viene bloccata a quel limite. E il team di Windows ha deciso che il modo migliore per affrontarlo era far finta che l'eccezione fosse gestita; l'esecuzione continua come se tutto fosse completato normalmente.

Oh, e questo succede ovunque . Il debug contro il rilascio è irrilevante. .Net vs C ++ è irrilevante. Questo è un comportamento a livello di sistema operativo.

Immagina di dover scrivere alcuni dati critici su disco, ma fallisce dalla parte sbagliata di un limite in modalità kernal. Un altro codice tenta di usarlo in seguito e, se sei fortunato, rilevi qualcosa che non va nei dati ... ma perché? Scommetto che non consideri mai che la tua richiesta non è riuscita a scrivere i dati --- perché ti aspettavi che venisse generata un'eccezione.

Jerks.

Answer 2

Quando leggo la risposta sull'avere due caselle di controllo in " Eccezione ... " finestra di dialogo, sono tornato indietro e ho riaperto la finestra di dialogo. Avevo solo una colonna di caselle di controllo - per interruzione su " Gettato " ;.

A quanto pare, se non hai " Abilita solo il mio codice (solo gestito) " spuntato nelle opzioni di debug, il "quotazione non gestita dall'utente" colonna non viene visualizzata nella sezione "Eccezioni" finestra di dialogo.

Ho selezionato " Abilita solo il mio codice " e verificato che l'opzione " Non gestita dall'utente " la casella di controllo in " Eccezioni " la finestra di dialogo è stata selezionata per tutte le categorie di eccezioni.

Sono stato in grado di ottenere eccezioni non gestite per entrare nel debugger per una sessione. Ma quando sono tornato il giorno successivo, il comportamento era come prima.

Metro.

Answer 3

Ctl-D, E richiama la finestra Eccezioni. È possibile impostare quali eccezioni si desidera e non si desidera interrompere.

Answer 4

Ci sono due caselle di controllo nelle " Eccezioni ... " casella, di solito devo averli entrambi controllati per farlo rompere su eccezioni non gestite. Indipendentemente dal fatto che si legge solo come è necessario averne uno controllato.

Answer 5

Una volta ogni tanto succede anche a me. Sembra un bug o qualcosa del genere, come quando replica lo scenario l'eccezione viene rilevata e mostrata come al solito.

Answer 6

Ho riscontrato un problema simile e ho verificato " Abilita solo il mio codice (solo gestito) " risolto il problema, mentre se lo spegnessi di nuovo il problema sarebbe tornato, nessun indizio sul perché (ma è possibile che alcune DLL che sembrano essere caricate quando è deselezionata causino il comportamento).