Controlli automatici

Driver Verifier esegue i controlli seguenti ogni volta che verifica uno o più driver. Non è possibile attivare o disattivare questi controlli. A partire da Windows 10 versione 1709, questi controlli automatici sono stati spostati in flag standard pertinenti. Di conseguenza, gli utenti che abilitano Driver Verifier con i flag standard non dovrebbero vedere alcuna riduzione dei controlli applicati.

Monitoraggio di routine IRQL e memoria

Driver Verifier monitora il driver selezionato per le seguenti azioni non consentite:

• Abbassamento di IRQL chiamando KeLowerIrql

• Abbassamento di IRQL chiamando KeRaiseIrql

• Richiesta di un'allocazione di memoria di dimensioni pari a zero

• Allocazione o rilascio di pool di paging con irQL > APC_LEVEL

• Allocazione o rilascio del pool non di paging con IRQL > DISPATCH_LEVEL

• Tentativo di liberare un indirizzo non restituito da un'allocazione precedente

• Tentativo di liberare un indirizzo già liberato

• Acquisizione o rilascio di un mutex veloce con irQL > APC_LEVEL

• Acquisizione o rilascio di un blocco spin con IRQL non uguale a DISPATCH_LEVEL

• Rilascio doppio di un blocco di rotazione.

• Contrassegnare una richiesta di allocazione come MUST_SUCCEED. Nessuna richiesta di questo tipo è mai consentita.

Se Driver Verifier non è attivo, queste violazioni potrebbero non causare un arresto anomalo immediato del sistema in tutti i casi. Driver Verifier monitora il comportamento del driver e rilascia il controllo dei bug 0xC4 se si verifica una di queste violazioni. Vedere Controllo bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) per un elenco dei parametri di controllo dei bug.

Monitoraggio dello stack switching

Driver Verifier monitora l'utilizzo dello stack del driver verificato. Se il driver cambia lo stack e il nuovo stack non è né uno stack di thread né uno stack DPC, viene eseguito un controllo dei bug. Questo sarà il controllo dei bug 0xC4 con il primo parametro uguale a 0x90. Lo stack visualizzato dal comando debugger KB in genere rivelerà il driver che ha eseguito questa operazione.

Verifica dello scaricamento del driver

Dopo che un driver in fase di verifica viene scaricato, Driver Verifier esegue diversi controlli per assicurarsi che il driver abbia completato la pulizia.

In particolare, Driver Verifier cerca:

• Timer non eliminati

• Chiamate di procedure posticipate in sospeso

• Elenchi lookaside non eliminati

• Thread di lavoro non cancellati

• Code non cancellate

• Altre risorse simili

Problemi come questi possono potenzialmente causare l'emissione di controlli di bug di sistema dopo lo scaricamento del driver e la causa di questi controlli di bug può essere difficile da determinare. Quando Driver Verifier è attivo, tali violazioni genereranno un controllo errori 0xC7, che viene emesso immediatamente dopo lo scaricamento del driver. Per un elenco dei parametri di bug check, vedere Bug Check 0xC7 (TIMER_OR_DPC_INVALID).

Monitoraggio dell'utilizzo del descrittore di memoria (MDL)

In Windows Vista, Driver Verifier monitora anche il driver selezionato per le seguenti azioni non consentite:

• Chiamare MmProbeAndLockPages o MmProbeAndLockProcessPages su un MDL che non dispone dei flag appropriati. Ad esempio, non è corretto chiamare MmProbeAndLockPages per un MDL creato tramite MmBuildMdlForNonPagedPool.

• Chiamata di MmMapLockedPages su un MDL che non possiede i flag appropriati. Ad esempio, non è corretto chiamare MmMapLockedPages per un MDL già mappato a un indirizzo di sistema o mDL non bloccato.

• Chiamata di MmUnlockPages o MmUnmapLockedPages su un MDL parziale, ovvero un MDL creato tramite IoBuildPartialMdl.

• Chiamata di MmUnmapLockedPages su un MDL non mappato a un indirizzo di sistema.

Se Driver Verifier non è attivo, queste violazioni potrebbero non causare l'arresto immediato del sistema in tutti i casi. Driver Verifier monitora il comportamento del driver e rilascia il controllo dei bug 0xC4 se si verifica una di queste violazioni. Vedere Controllo bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) per un elenco dei parametri di controllo dei bug.

Allocazione di oggetti di sincronizzazione dalla memoria NonPagedPoolSession

A partire da Windows 7, Driver Verifier verifica la presenza di oggetti di sincronizzazione dalla memoria della sessione.

Gli oggetti di sincronizzazione devono essere non modificabili. Devono anche risiedere nello spazio indirizzi virtuale globale e a livello di sistema.

Un driver di grafica può allocare memoria di sessione chiamando API come EngAllocMem. A differenza dello spazio indirizzi globale, lo spazio degli indirizzi della sessione viene virtualizzato per ogni sessione di Terminal Server. Ciò significa che lo stesso indirizzo virtuale usato nel contesto di due sessioni diverse fa riferimento a due oggetti diversi. Il kernel di Windows deve essere in grado di accedere agli oggetti di sincronizzazione da qualsiasi sessione di Terminal Server. Il tentativo di fare riferimento a un indirizzo di memoria sessione da una sessione diversa ha risultati imprevedibili, ad esempio arresti anomali del sistema o danneggiamento invisibile all'utente dei dati di un'altra sessione.

A partire da Windows 7, quando un driver verificato inizializza un oggetto di sincronizzazione chiamando API come KeInitializeEvent o KeInitializeMutex, Driver Verifier verifica se l'indirizzo dell'oggetto rientra nello spazio degli indirizzi virtuali della sessione. Se Driver Verifier rileva questo tipo di indirizzo non corretto, genera un Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, con un valore del parametro 1 pari a 0xDF.

Il contatore di riferimento degli oggetti passa da 0 a 1

A partire da Windows 7, Driver Verifier verifica la presenza di classi aggiuntive di riferimenti a oggetti non corretti.

Quando gestione oggetti kernel di Windows crea un oggetto, ad esempio un oggetto File o un oggetto Thread, il contatore di riferimento del nuovo oggetto è impostato su 1. Il contatore dei riferimenti viene incrementato dalle chiamate alle API, ad esempio ObReferenceObjectByPointer o ObReferenceObjectByHandle. Il contatore di riferimento viene decrementato da ogni chiamata ObDereferenceObject per lo stesso oggetto.

Dopo che il contatore di riferimento raggiunge il valore 0, l'oggetto diventa idoneo per essere liberato. Il gestore oggetti potrebbe liberarlo immediatamente o liberarlo in un secondo momento. Chiamare ObReferenceObjectByPointer o ObDereferenceObject e modificare il contatore di riferimento da 0 a 1 significa incrementare il contatore di riferimento di un oggetto già liberato. Questo errore non è sempre corretto perché può causare un danneggiamento dell'allocazione di memoria di un altro utente.

Blocchi o ritardi di arresto del sistema

A partire da Windows 7, Driver Verifier genera un'interruzione nel debugger del kernel se l'arresto del sistema non termina 20 minuti dopo l'avvio. Driver Verifier assegna l'avvio dell'arresto del sistema come ora in cui il kernel di Windows inizia a arrestare i vari sottosistemi, ad esempio Registro di sistema, Plug And Play o i sottosistemi di gestione I/O.

Se un debugger del kernel non è collegato al sistema, Driver Verifier genera un controllo bug 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, con un valore di parametro 1 di 0x115 anziché questo punto di interruzione.

Spesso un arresto del sistema che non può terminare in meno di 20 minuti indica che uno dei driver in esecuzione in tale sistema non funziona correttamente. L'esecuzione di !analyze -v dal debugger del kernel visualizza l'analisi dello stack del thread di lavoro di sistema responsabile dell'arresto. È necessario esaminare l'analisi dello stack e determinare se il thread di arresto è bloccato da uno dei driver da testare.

A volte il sistema non può essere arrestato perché è soggetto a test di stress pesanti, anche se tutti i driver funzionano correttamente. L'utente può scegliere di continuare l'esecuzione dopo questo punto di interruzione Driver Verifier e verificare se il sistema alla fine si arresta.