Controlli automatici

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

Monitoraggio di routine IRQL e memoria

Il verificatore driver monitora il driver selezionato per le azioni non consentite seguenti:

• Generazione di IRQL chiamando KeLowerIrql

• Riduzione di IRQL chiamando KeRaiseIrql

• Richiesta di un'allocazione di memoria zero dimensioni

• Allocazione o rilascio di pool con irQL > APC_LEVEL

• Allocazione o rilascio di pool non di pagina con irQL > DISPATCH_LEVEL

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

• Cercando di liberare un indirizzo già liberato

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

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

• Rilascio doppio di un blocco di rotazione.

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

Se il verificatore driver non è attivo, queste violazioni potrebbero non causare un arresto anomalo immediato del sistema in tutti i casi. Verifica driver monitora il comportamento del driver e verifica i problemi di bug 0xC4 se si verifica una di queste violazioni. Per un elenco dei parametri di controllo dei bug, vedere Verifica bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION ).

Passaggio dello stack di monitoraggio

Il verificatore driver monitora l'utilizzo dello stack dal driver verificato. Se il driver commuta lo stack e il nuovo stack non è uno stack di thread né uno stack DPC, viene generato un controllo di bug. Il controllo di bug verrà verificato 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 del caricamento del driver

Dopo aver verificato il caricamento di un driver, il verificatore driver esegue diversi controlli per assicurarsi che il driver sia stato pulito.

In particolare, Driver Verifier cerca:

• Timer non recapitati

• Chiamate di routine posticipate in sospeso (DPC)

• Elenchi lookaside non visualizzati

• Thread di lavoro non annullati

• Code non eliminate

• Altre risorse simili

Problemi come questi possono potenzialmente causare l'emissione di controlli di bug di sistema un po ' dopo il caricamento del driver e la causa di questi controlli di bug può essere difficile da determinare. Quando il verificatore driver è attivo, tali violazioni causano un controllo di bug 0xC7 rilasciato immediatamente dopo il caricamento del driver. Per un elenco dei parametri di controllo dei bug, vedere Verifica bug 0xC7 (TIMER_OR_DPC_INVALID ).

Monitoraggio dell'elenco dei descrittori di memoria (MDL) Utilizzo

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

• Chiamata di MmProbeAndLockPages o MmProbeAndLockProcessPages in un MDL che non ha i flag appropriati. Ad esempio, non è corretto chiamare MmProbeAndLockPages per un MDL creato usando MmBuildMdlForNonPagedPool.

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

• Chiamata di MmUnlockPages o MmUnmapLockedPages in un MDL parziale, ovvero e MDL creato usando IoBuildPartialMdl.

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

Se il verificatore driver non è attivo, queste violazioni potrebbero non causare l'arresto immediato della risposta del sistema in tutti i casi. Verifica driver monitora il comportamento del driver e verifica i problemi di bug 0xC4 se si verifica una di queste violazioni. Per un elenco dei parametri di controllo dei bug, vedere Verifica bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION ).

Allocazione dell'oggetto di sincronizzazione dalla memoria NonPagedPoolSession

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

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

Un driver grafico può allocare memoria sessione chiamando LE API, ad esempio 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 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 indirizzi virtuale della sessione. Se Il verificatore driver rileva questo tipo di indirizzo non corretto, genera un controllo bug 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, con un valore parametro 1 di 0xDF.

Modifiche del contatore di riferimenti a oggetti da 0 a 1

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

Quando il gestore 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 di riferimento 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 oppure potrebbe liberarlo in un secondo momento. La chiamata a ObReferenceObjectByPointer o ObDereferenceObject e la modifica del contatore di riferimento da 0 a 1 significa aumentare il contatore di riferimento di un oggetto già liberato. Questo errore non è sempre corretto perché può causare il danneggiamento dell'allocazione di memoria di un altro utente.

Blocchi di arresto del sistema o ritardi

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. Il verificatore driver assegna l'inizio dell'arresto del sistema come ora in cui il kernel di Windows inizia a arrestare i vari sottosistemi, ad esempio Registro, Plug And Play o i sottosistemi di gestione I/O.

Se un debugger del kernel non è collegato al sistema, driver verifica un controllo bug 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, con un parametro 1 valore 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 su tale sistema non funziona correttamente. L'esecuzione di !analysis -v dal debugger del kernel visualizza la traccia dello stack del thread di lavoro di sistema responsabile dell'arresto. È necessario esaminare la traccia dello stack e determinare se il thread di arresto è bloccato da uno dei driver che vengono testati.

A volte il sistema non può arrestare perché è soggetto a test di stress pesanti, anche se tutti i driver funzionano correttamente. L'utente può scegliere di continuare l'esecuzione dopo il punto di interruzione del driver verifier e verificare se il sistema si arresta.