Verifica di I/O
Driver Verifier ha due livelli di verifica di I/O:
La verifica di I/O di livello 1 è sempre attiva ogni volta che viene selezionata la verifica di I/O.
La verifica di I/O di livello 2 è sempre attiva ogni volta che viene selezionata la verifica di I/O in Windows XP e versioni successive.
Vedi Anche:Verifica di I/O avanzata in Windows 7 e versioni successive del sistema operativo Windows, la verifica di I/O avanzata viene attivata automaticamente quando si seleziona Verifica di I/O. Non è disponibile o necessario selezionarlo come opzione separata.
Verifica di I/O di livello 1
Quando la verifica di I/O di livello 1 è abilitata, tutti i provider di integrazione ottenuti tramite IoAllocateIrp vengono allocati da un pool speciale e viene rilevato il loro uso.
Inoltre, Driver Verifier verifica la presenza di chiamate di I/O non valide, tra cui:
Tenta di liberare un IRP il cui tipo non è IO_TYPE_IRP
Passa oggetti dispositivo non validi a IoCallDriver
Passa un IRP a IoCompleteRequest che contiene lo stato non valido o che dispone ancora di un set di routine di annullamento
Modifiche a IRQL in una chiamata alla routine di invio del driver
Tenta di liberare un IRP che rimane associato a un thread
Passa un oggetto dispositivo a IoInitializeTimer che contiene già un timer inizializzato
Passa un buffer non valido a IoBuildAsynchronousFsdRequest o IoBuildDeviceIoControlRequest
Passa un blocco di stato di I/O a un IRP, quando questo blocco di stato di I/O viene allocato in uno stack con un rollforward troppo lontano
Passa un oggetto evento a un IRP, quando questo oggetto evento viene allocato in uno stack con un'operazione troppo lunga
Poiché il pool IRP speciale è di dimensioni limitate, la verifica di I/O è più efficace quando viene usata solo su un driver alla volta.
Gli errori del livello di verifica di I/O 1 causano l'emissione del controllo dei bug 0xC9. Il primo parametro di questo controllo di bug indica quale violazione si è verificata. Per un elenco completo dei parametri, vedere Controllo bug 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION).
Verifica di I/O di livello 2
Gli errori del livello di verifica di I/O 2 vengono visualizzati in modi diversi: nella schermata blu, in un file di dump di arresto anomalo del sistema e in un debugger del kernel.
Nella schermata blu questi errori vengono annotati dal messaggio ERRORE DI VERIFICA SISTEMA IO e dalla stringa WDM DRIVER ERRORXXX, dove XXX è un codice di errore di I/O.
In un file di dump di arresto anomalo del sistema, la maggior parte di questi errori viene annotata dal messaggio BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION) insieme al codice di errore di I/O. In questo caso, il codice di errore di I/O viene visualizzato come primo parametro del controllo dei bug 0xC9. Il resto è indicato dal messaggio Controllo bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION), insieme a un codice di errore di Driver Verifier. In questo caso, il codice di errore Driver Verifier viene visualizzato come primo parametro del controllo bug 0xC4.
In un debugger del kernel (KD o WinDbg), questi errori vengono annotati dal messaggio WDM DRIVER ERROR e da una stringa di testo descrittiva. Quando il debugger del kernel è attivo, è possibile ignorare gli errori di livello 2 e riprendere l'operazione di sistema. Questa operazione non è possibile con altri controlli di bug.
La schermata blu, il file di dump di arresto anomalo del sistema e il debugger del kernel visualizzano anche informazioni aggiuntive. Per una descrizione completa della maggior parte dei messaggi di errore del livello di verifica I/O 2, vedere Controllo bug 0xC9. Per il resto, vedere Controllo bug 0xC4.
A partire da Window Vista, l'opzione Verifica di I/O controlla la presenza degli errori seguenti del driver:
Il completamento e l'annullamento dei runtime di integrazione originati nelle applicazioni in modalità utente richiedono troppo tempo.
Rilascio di un blocco di rimozione non ancora acquisito.
Chiamando IoReleaseRemoveLock o IoReleaseRemoveLockAndWait con un parametro tag diverso dal parametro tag usato nella chiamata IoAcquireRemoveLock corrispondente.
Chiamata di IoCallDriver con interrupt disabilitati.
Chiamata di IoCallDriver in IRQL maggiore di DISPATCH_LEVEL.
Restituzione da una routine di invio del driver con interrupt disabilitati.
Restituzione da una routine di invio del driver con un IRQL modificato.
Restituzione da una routine di invio del driver con ICS disabilitati. In questo caso, il driver potrebbe aver chiamato KeEnterCriticalRegion più volte rispetto a KeLeaveCriticalRegion, che è la causa principale per il controllo dei bug 0x20 (KERNEL_APC_PENDING_DURING_EXIT) e il controllo bug 0x1 (APC_INDEX_MISMATCH).
A partire da Windows 7, l'opzione Verifica I/O verifica verifica la presenza degli errori seguenti del driver:
- Tenta di liberare i provider di integrazione chiamando ExFreePool. I runtime di integrazione devono essere liberati con IoFreeIrp.
È anche possibile usare questa opzione per rilevare un altro bug comune del driver, reinizializzando i blocchi rimossi. Rimuovere le strutture dei dati di blocco devono essere allocate all'interno delle estensioni del dispositivo. In questo modo, il gestore di I/O libera la memoria che contiene la struttura IO_REMOVE_LOCK solo quando l'oggetto dispositivo viene eliminato. Se il driver esegue i tre passaggi seguenti, è possibile che dopo il passaggio 2 un'applicazione o un driver contenga ancora un riferimento a Device1:
- Alloca la struttura IO_REMOVE_LOCK che corrisponde a Device1, ma esegue l'allocazione all'esterno dell'estensione di Device1.
- Chiama IoReleaseRemoveLockAndWait quando Device1 viene rimosso.
- Chiama IoInitializeRemoveLock per lo stesso blocco per riutilizzarlo come blocco di rimozione per Device2.
È possibile che dopo il passaggio 2 un'applicazione o un driver contenga ancora un riferimento a Device1. L'applicazione o il driver può comunque inviare richieste a Device1, anche se il dispositivo è stato rimosso. Pertanto, non è sicuro riutilizzare la stessa memoria di un nuovo blocco di rimozione fino a quando gestione I/O elimina Device1. La reinizializzazione dello stesso blocco mentre un altro thread sta tentando di acquisirlo può causare il danneggiamento del blocco, con risultati imprevedibili per il driver e l'intero sistema.
In Windows 7 e versioni successive del sistema operativo Windows, la verifica di I/O avanzata viene attivata automaticamente quando si seleziona Verifica di I/O.
Attivazione di questa opzione
È possibile attivare la funzionalità di verifica di I/O per uno o più driver usando Gestione verifica driver o la riga di comando Verifier.exe. Per informazioni dettagliate, vedere Selezione delle opzioni di verifica driver.
Nella riga di comando.
Nella riga di comando l'opzione Verifica di I/O è rappresentata da Bit 4 (0x10).At the command line, the I/O Verification option is represented represented by Bit 4 (0x10). Per attivare la verifica di I/O, usare un valore flag di 0x10 o aggiungere 0x10 al valore del flag. Ad esempio:
verifier /flags 0x10 /driver MyDriver.sys
La funzionalità sarà attiva dopo l'avvio successivo.
È anche possibile attivare e disattivare la verifica di I/O senza riavviare il computer aggiungendo il parametro /volatile al comando . Ad esempio:
verifier /volatile /flags 0x10 /adddriver MyDriver.sys
Questa impostazione è effettiva immediatamente, ma viene persa quando si arresta o si riavvia il computer. Per informazioni dettagliate, vedere Uso delle impostazioni volatili.
La funzionalità di verifica di I/O è inclusa anche nelle impostazioni standard. Ad esempio:
verifier /standard /driver MyDriver.sys
Uso di Gestione verifica driver
- Selezionare Crea impostazioni personalizzate (per sviluppatori di codice) e quindi fare clic su Avanti.
- Selezionare Seleziona singole impostazioni da un elenco completo.
- Selezionare (controllare) Verifica di I/O.
La funzionalità di verifica di I/O è inclusa anche nelle impostazioni standard. Per usare questa funzionalità, in Gestione verifica driver fare clic su Crea impostazioni standard.
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per