Condividi tramite


Controllo delle eccezioni e degli eventi

È 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.

È possibile modificare lo stato di interruzione degli eventi seguenti. Poiché questi eventi non sono eccezioni, lo stato di gestione è irrilevante.

Codice evento Significato Stato di interruzione predefinito

ser

Errore di sistema

Ignora

cpr[:Process]

Creazione del processo

L'impostazione dello stato di interruzione di questo evento si applica solo al debug in modalità utente. Questo evento non si verifica in modalità kernel.

È possibile controllare questo evento solo se è stato attivato il debug di processi figlio in CDB o WinDbg, tramitel'opzione della riga di comando -o o tramite il comando .childdbg (Debug processi figlio).

Il nome del processo può includere un'estensione di file facoltativa e un asterisco () o un punto interrogativo (?) come caratteri jolly. Il debugger ricorda solo l'impostazione cpr più recente. Le impostazioni separate per i processi separati non sono supportate. Includere due punti o uno spazio tra cpr e Processo.

Se Process viene omesso, l'impostazione si applica a qualsiasi creazione di processi figlio.

Ignora

epr[:Process]

Uscita del processo

L'impostazione dello stato di interruzione di questo evento si applica solo al debug in modalità utente. Questo evento non si verifica in modalità kernel.

È possibile controllare questo evento solo se è stato attivato il debug di processi figlio in CDB o WinDbg, tramitel'opzione della riga di comando -o o tramite il comando .childdbg (Debug processi figlio).

Il nome del processo può includere un'estensione di file facoltativa e un asterisco () o un punto interrogativo (?) come caratteri jolly. Il debugger ricorda solo l'impostazione epr più recente. Le impostazioni separate per i processi separati non sono supportate. Includere due punti o uno spazio tra epr e Process.

Se Process viene omesso, l'impostazione si applica a qualsiasi uscita del processo figlio.

Ignora

Ct

Creazione di thread

Ignora

et

Uscita del thread

Ignora

ld[:Module]

Caricare il modulo

Se si specifica Module, l'interruzione si verifica quando viene caricato il modulo con questo nome. Il modulo può specificare il nome o l'indirizzo del modulo. Se viene usato il nome, Module potrebbe contenere un'ampia gamma di caratteri jolly e identificatori. Per altre informazioni sulla sintassi, vedere Sintassi con caratteri jolly stringa.

Il debugger memorizza solo l'impostazione ld più recente. Le impostazioni separate per i moduli separati non sono supportate. Includere due punti o uno spazio tra ld e Module.

Se Module viene omesso, l'evento viene attivato quando viene caricato un modulo.

Output

ud[:Module]

Scarica modulo

Se si specifica Module, l'interruzione si verifica quando il modulo con questo nome o in questo indirizzo di base viene scaricato. Il modulo può specificare il nome o l'indirizzo del modulo. Se viene usato il nome, Module può essere un nome esatto o includere caratteri jolly. Se Module è un nome esatto, viene immediatamente risolto in un indirizzo di base usando l'elenco di moduli del debugger corrente e viene archiviato come indirizzo. Se Module contiene caratteri jolly, la stringa del criterio viene mantenuta per la corrispondenza successiva quando si verificano eventi di scaricamento.

Raramente, il debugger non dispone di informazioni sul nome per gli eventi di scaricamento e corrisponde solo all'indirizzo di base. Pertanto, se Module contiene caratteri jolly, il debugger non può eseguire una corrispondenza del nome in questo caso di scaricamento specifico e interrompe quando un modulo viene scaricato.

Il debugger ricorda solo l'impostazione definita dall'utente più recente. Le impostazioni separate per i moduli separati non sono supportate. Includere due punti o uno spazio tra ud e Module.

Se Module viene omesso, l'evento viene attivato quando viene caricato un modulo.

Output

out[:Output]

Output dell'applicazione di destinazione

Se si specifica Output, l'interruzione si verifica solo quando viene ricevuto l'output corrispondente al modello specificato. L'output può contenere un'ampia gamma di caratteri jolly e identificatori. Per altre informazioni sulla sintassi, vedere Sintassi con caratteri jolly stringa. Tuttavia, Output non può contenere due punti o spazi. Nella corrispondenza non viene fatta distinzione tra maiuscole e minuscole. Includere due punti o uno spazio tra out e Output.

Ignora

Ibp

Punto di interruzione iniziale

Questo evento si verifica all'inizio della sessione di debug e dopo il riavvio del computer di destinazione.

In modalità utente: Pausa. È possibile modificare questo stato su "Ignora" usando l'opzione della riga di comando-g.

In modalità kernel: Ignorare. È possibile modificare questo stato su "Abilitato" in base a un'ampia gamma di metodi. Per altre informazioni su come modificare questo stato, vedere Arresto anomalo e riavvio del computer di destinazione.

Iml

Caricamento del modulo iniziale

(solo modalità kernel)

ignorare. È possibile modificare questo stato su "Break" in base a un'ampia gamma di metodi. Per altre informazioni su come modificare questo stato, vedere Arresto anomalo e riavvio del computer di destinazione.