Controllo delle eccezioni e degli eventi

Articolo
04/14/2023

È possibile rilevare e gestire le eccezioni nelle applicazioni in modalità utente e in modalità kernel tramite diversi metodi. Un debugger attivo, un debugger postmortem o una routine di gestione degli errori interni sono tutti modi comuni per gestire le eccezioni.

Per altre informazioni sull'ordine di precedenza di questi vari gestori di eccezioni, vedere Abilitazione del debug postmortem.

Quando il sistema operativo Microsoft Windows consente a un debugger di gestire un'eccezione, l'applicazione che ha generato l'eccezione si interrompe nel debugger. Vale a dire, l'applicazione si arresta e il debugger diventa attivo. Il debugger può quindi gestire l'eccezione in qualche modo o analizzare la situazione. Il debugger può quindi terminare il processo o lasciarlo riprendere in esecuzione.

Se il debugger ignora l'eccezione e consente all'applicazione di continuare l'esecuzione, il sistema operativo cerca altri gestori di eccezioni come se non fosse presente alcun debugger. Se l'eccezione viene gestita, l'applicazione continua a essere in esecuzione. Tuttavia, se l'eccezione rimane non gestita, il debugger viene quindi data una seconda opportunità per gestire la situazione.

Uso del debugger per analizzare un'eccezione

Quando un'eccezione o un evento si interrompe nel debugger, è possibile usare il debugger per esaminare il codice che viene eseguito e la memoria usata dall'applicazione. Modificando determinate quantità o passando a un punto diverso nell'applicazione, è possibile rimuovere la causa dell'eccezione.

È possibile riprendere l'esecuzione eseguendo un comando gh (Go with Exception Handled) o gn (Go with ExceptionNot Handled).

Se si rilascia il comando gn nella seconda opportunità del debugger per gestire l'eccezione, l'applicazione termina.

Eccezioni in modalità kernel

Le eccezioni che si verificano nel codice in modalità kernel sono più gravi rispetto alle eccezioni in modalità utente. Se le eccezioni in modalità kernel non vengono gestite, viene emesso un controllo di bug e il sistema si arresta.

Come per le eccezioni in modalità utente, se un debugger in modalità kernel è collegato al sistema, il debugger viene notificato prima che venga visualizzata la schermata di controllo dei bug (nota anche come schermata blu). Se non è collegato alcun debugger, viene visualizzata la schermata di controllo dei bug. In questo caso, il sistema operativo potrebbe creare un file di dump di arresto anomalo.

Controllo delle eccezioni e degli eventi dal debugger

È possibile configurare il debugger per reagire alle eccezioni e agli eventi specificati in modo specifico.

Il debugger può impostare lo stato di interruzione per ogni eccezione o evento:

L'evento può causare un'interruzione nel debugger non appena si verifica (la prima possibilità).
L'evento può essere interrotto dopo che altri gestori di errori hanno dato l'opportunità di rispondere (la seconda possibilità).
L'evento può anche inviare un messaggio al debugger, ma continuare a eseguire.
Il debugger può ignorare l'evento.

Il debugger può anche impostare lo stato di gestione per ogni eccezione ed evento. Il debugger può trattare l'evento come un'eccezione gestita o un'eccezione non gestita. Naturalmente, gli eventi che non sono effettivamente errori non richiedono alcuna gestione.

È possibile controllare lo stato di interruzione e gestire lo stato eseguendo una delle operazioni seguenti:

Usare il comando SXE, SXD, SXN o SXI nella finestra Comando debugger.
(CDB e NTSD) Usare l'opzione -x, -xe, -xd, -xn o -xi nella riga di comando.
(CDB, NTSD e KD) Usare la parola chiave sxe o sxd nel file Tools.ini.
(solo WinDbg) Selezionare Filtri eventi nel menu Debug per aprire la finestra di dialogo Filtri eventi e quindi scegliere le opzioni desiderate.

Il comando SX\*, l'opzione della riga di comando -x\* e la parola chiave sx\* Tools.ini in genere imposta lo stato di interruzione dell'evento specificato. È possibile aggiungere l'opzione -h per causare l'impostazione dello stato di gestione.

Esistono quattro codici eventi speciali (cc, hc, bpec e ssec) che specificano sempre lo stato di gestione anziché lo stato di interruzione.

È possibile visualizzare l'eccezione o l'evento più recenti usando il comando lastevent (Display Last Event).

Controllo dello stato di interruzione

Quando si imposta lo stato di interruzione di un'eccezione o di un evento, è possibile usare le opzioni seguenti.

Comando	Nome stato	Descrizione
SXE o -xe	Applicazione (Abilitato)	Quando si verifica questa eccezione, la destinazione si interrompe immediatamente nel debugger. Questa interruzione si verifica prima che vengano attivati altri gestori di errori. Questo metodo viene chiamato gestione della prima probabilità.
SXD o -xd	Seconda interruzione di probabilità (Disabilitato)	Il debugger non si interrompe per questo tipo di eccezione first-chance (anche se viene visualizzato un messaggio). Se altri gestori di errori non possono risolvere questa eccezione, l'esecuzione si arresta e la destinazione si interrompe nel debugger. Questo metodo viene chiamato gestione seconda probabilità.
SXN o -xn	Output (Notifica)	Quando si verifica questa eccezione, l'applicazione di destinazione non si interrompe nel debugger. Viene tuttavia visualizzato un messaggio che informa l'utente di questa eccezione.
SXI o -xi	Ignora	Quando si verifica questa eccezione, l'applicazione di destinazione non si interrompe nel debugger e non viene visualizzato alcun messaggio.

Se un'eccezione non è prevista da un'impostazione SX*, l'applicazione di destinazione si interrompe nel debugger alla seconda possibilità. Lo stato predefinito per gli eventi è elencato nella sezione "Definizioni eventi e impostazioni predefinite" seguente di questo argomento.

Per impostare lo stato di interruzione usando l'interfaccia grafica WinDbg, Filtri eventi nel menu Debug selezionare l'evento desiderato dall'elenco nella finestra di dialogo Filtri eventi e quindi selezionare Abilitato, Disabilitato, Output o Ignora.

Controllo dello stato di gestione

Tutti gli eventi vengono considerati non gestiti, a meno che non si usi il comando gh (Go with Exception Handled).

Tutte le eccezioni vengono considerate non gestite, a meno che non si usi il comando sx\* insieme all'opzione -h .

Inoltre, le opzioni SX* possono configurare lo stato di gestione per handle non validi, STATUS_BREAKPOINT istruzioni di interruzione e eccezioni in singolo passaggio. Questa configurazione è separata dalla configurazione dell'interruzione. Quando si configura lo stato di interruzione, questi eventi sono denominati rispettivamente ch, bpe e sse. Quando si configura lo stato di gestione, questi eventi sono denominati rispettivamente hc, bpec e ssec. Per l'elenco completo degli eventi, vedere la sezione "Definizioni eventi e impostazioni predefinite" seguente.

È possibile configurare lo stato di gestione per l'evento CTRL+C (cc), ma non lo stato di interruzione. Se un'applicazione riceve un evento CTRL+C, l'applicazione si interrompe sempre nel debugger.

Quando si usa il comando SX* in eventi cc, hc, bpec e ssec oppure quando si usa il comando SX* insieme all'opzione -h in un'eccezione, si verificano le azioni seguenti.

Comando	Nome stato	Descrizione
SXE	Gest.	L'evento viene considerato gestito quando l'esecuzione riprende.
SXD, SXN, SXI	Non gestito	L'evento viene considerato non gestito quando l'esecuzione riprende.

Per impostare lo stato di gestione usando l'interfaccia grafica WinDbg, selezionare Filtri eventi nel menu Debug, selezionare l'evento desiderato dall'elenco nella finestra di dialogo Filtri eventi e quindi selezionare Handled o Not Handled.

Comandi automatici

Il debugger consente inoltre di impostare i comandi che vengono eseguiti automaticamente se l'evento o l'eccezione causa un'interruzione nel debugger. È possibile impostare una stringa di comando per l'interruzione di prima probabilità e una stringa di comando per l'interruzione di seconda probabilità. È possibile impostare queste stringhe con il comando SX\* o debug | Comando Filtri eventi . Ogni stringa di comando può contenere più comandi separati da punti e virgola.

Questi comandi vengono eseguiti indipendentemente dallo stato di interruzione. Ovvero, se lo stato di interruzione è "Ignora", il comando viene ancora eseguito. Se lo stato di interruzione è "Interruzione seconda possibilità", il comando first-chance viene eseguito quando si verifica prima l'eccezione, prima che vengano coinvolti altri gestori di eccezioni. La stringa di comando può terminare con un comando di esecuzione, ad esempio g (Go),gh (Go with Exception Handled) o gn (Go with ExceptionNot Handled).

Definizioni di eventi e impostazioni predefinite

È possibile modificare lo stato di interruzione o la gestione delle eccezioni seguenti. Lo stato di interruzione predefinito è indicato.

Lo stato di gestione predefinito delle eccezioni seguenti è sempre "Non gestito". Prestare attenzione alla modifica dello stato. Se si modifica questo stato su "Handled", tutte le eccezioni first-chance e second-chance di questo tipo vengono considerate gestite e questa configurazione ignora tutte le routine di gestione delle eccezioni.

Codice evento	Significato	Stato di interruzione predefinito
asrt	Errore di asserzione	Applicazione
Av	Violazione di accesso	Applicazione
Dm	Dati non allineati	Applicazione
Dz	Divisione integer per zero	Applicazione
c0000008e	Divisione a virgola mobile per zero	Applicazione
eh	Eccezione EH C++	Pausa di seconda probabilità
Gp	Violazione della pagina guard	Applicazione
Ii	Istruzione non valida	Pausa di seconda probabilità
iov	Overflow intero	Applicazione
Ip	Errore di I/O nella pagina	Applicazione
Isc	Chiamata di sistema non valida	Applicazione
lsq	Sequenza di blocchi non valida	Applicazione
Sbo	Sovraccarico del buffer dello stack	Applicazione
Sov	Overflow dello stack	Applicazione
imbarazzato	Debugger di riattivazione	Applicazione
Aph	Blocco dell'applicazione Questa eccezione viene attivata se il sistema operativo Windows conclude che un processo ha interrotto la risposta, ovvero è bloccata.	Applicazione
3c	Terminazione dell'applicazione figlio	Pausa di seconda probabilità
chhc	Handle non valido	Applicazione
Number	Qualsiasi eccezione numerata	Pausa di seconda probabilità

Nota È possibile eseguire l'override dello stato di interruzione asrt per un indirizzo specifico usando il comando ah (Gestione asserzioni). I codici eventi ch e hc fanno riferimento alla stessa eccezione. Quando si controlla lo stato di interruzione, usare sx* ch. Quando si controlla lo stato di gestione, usare sx* hc.

È possibile modificare lo stato di interruzione o la gestione delle eccezioni seguenti. Lo stato di interruzione predefinito è indicato.

Lo stato di gestione predefinito delle eccezioni seguenti è sempre "Gestito". Poiché queste eccezioni vengono usate per comunicare con il debugger, non è in genere consigliabile modificare lo stato in "Non gestito". Questo stato causa l'rilevamento delle eccezioni da parte di altri gestori di eccezioni se il debugger li ignora.

Un'applicazione può usare DBG_COMMAND_EXCEPTION (dbce) per comunicare con il debugger. Questa eccezione è simile a un punto di interruzione, ma è possibile usare il comando SX* per reagire in modo specifico quando si verifica questa eccezione.

Codice evento	Significato	Stato di interruzione predefinito
dbce	Eccezione di comando del debugger speciale	Ignora
vcpp	Eccezione di Visual C++ speciale	Ignora
Wos	Eccezione wow64 a passaggio singolo	Applicazione
wob	Eccezione del punto di interruzione WOW64-	Applicazione
Sse ssec	Eccezione in un singolo passaggio	Applicazione
Bpe bpec	Eccezione del punto di interruzione	Applicazione
cce Cc	CTRL+C o CTRL+INTERR Questa eccezione viene attivata se la destinazione è un'applicazione console e CTRL+C o CTRL+INTERR viene passata.	Applicazione

Nota Le tre eccezioni finali nella tabella precedente hanno due codici evento diversi. Quando si controlla lo stato di interruzione, usare sse, bpe e cce. Quando si controlla lo stato di gestione, usare ssec, bpec e cc.

Le eccezioni seguenti sono utili quando si esegue il debug del codice gestito.

Codice evento	Significato	Stato predefinito
Clr	Eccezione common Language Runtime	Pausa di seconda probabilità Non gestito
clrn	Eccezione di notifica di Common Language Runtime	Pausa di seconda probabilità Gest.

Clr

Eccezione common Language Runtime

Pausa di seconda probabilità

Non gestito

clrn

Eccezione di notifica di Common Language Runtime