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 |
Eccezione in un singolo passaggio |
Applicazione |
Bpe |
Eccezione del punto di interruzione |
Applicazione |
cce |
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. |