Vérifications automatiques

Le vérificateur de pilotes effectue les vérifications suivantes chaque fois qu’il vérifie un ou plusieurs pilotes. Vous ne pouvez pas activer ou désactiver ces vérifications. À compter de Windows 10, version 1709, ces vérifications automatiques ont été déplacées vers des indicateurs standard pertinents. Par conséquent, les utilisateurs qui activent Driver Verifier avec les indicateurs standard ne doivent pas voir une réduction des vérifications appliquées.

Surveillance des routines IRQL et mémoire

Le vérificateur de pilotes surveille le pilote sélectionné pour les actions interdites suivantes :

• Augmentation de l’IRQL en appelant KeLowerIrql

• Réduction du runtime d’intégration en appelant KeRaiseIrql

• Demande d’une allocation de mémoire de taille zéro

• Allocation ou libération d’un pool paginé avec irQL > APC_LEVEL

• Allocation ou libération d’un pool non paginé avec IRQL > DISPATCH_LEVEL

• Il s'agit d'une tentative de libérer une adresse qui n'a pas été retournée par une allocation précédente.

• Essayer de libérer une adresse qui était déjà libérée

• Acquisition ou libération d’un mutex rapide avec IRQL > APC_LEVEL

• Acquisition ou libération d’un verrou de rotation avec IRQL non égal à DISPATCH_LEVEL

• Double libération d’un verrou de rotation.

• Marquage d’une demande d’allocation MUST_SUCCEED. Aucune telle demande n’est jamais autorisée.

Si le vérificateur de pilote n’est pas actif, ces violations peuvent ne pas provoquer un blocage immédiat du système dans tous les cas. Le vérificateur de pilotes surveille le comportement du pilote et émet la vérification des bogues 0xC4 si l’une de ces violations se produit. Consultez 0xC4 de vérification des bogues (DRIVER_VERIFIER_DETECTED_VIOLATION) pour obtenir la liste des paramètres de vérification des bogues.

Surveillance du changement de stack

Le Vérificateur de pilotes surveille l'utilisation de la pile par le pilote vérifié. Si le pilote change sa pile et que la nouvelle pile n’est ni une pile de threads ni une pile DPC, un contrôle des erreurs est déclenché. (Il s’agit d’une vérification des bogues 0xC4 avec le premier paramètre égal à 0x90.) La pile affichée par la commande du débogueur KB devrait généralement révéler le pilote qui a effectué cette opération.

Vérification du déchargement du pilote

Après le déchargement d’un pilote en cours de vérification, le vérificateur de pilotes effectue plusieurs vérifications pour s’assurer que le pilote a nettoyé.

En particulier, Driver Verifier recherche les éléments suivants :

• Minuteurs non supprimés

• Appels en attente de procédure différée (DPC)

• Listes de choix non supprimées

• Threads de travail non effacés

• Files d’attente non supprimées

• Autres ressources similaires

Les problèmes tels que ceux-ci peuvent entraîner l’émission de vérifications de bogues système pendant un certain temps après le déchargement du pilote, et la cause de ces vérifications de bogues peut être difficile à déterminer. Lorsque le Driver Verifier est actif, ces violations entraînent un écran bleu d'erreur 0xC7 immédiatement après le déchargement du pilote. Consultez Vérification d'erreur 0xC7 (TIMER_OR_DPC_INVALID) pour obtenir la liste des paramètres de vérification d'erreur.

Surveillance de l’utilisation de la liste de descripteurs de mémoire (MDL)

Dans Windows Vista, le vérificateur de pilotes surveille également le pilote sélectionné pour les actions interdites suivantes :

• Appel de MmProbeAndLockPages ou MmProbeAndLockProcessPages sur un MDL qui ne possède pas les indicateurs appropriés. Par exemple, il est incorrect d’appeler MmProbeAndLockPages pour un MDL créé à l’aide de MmBuildMdlForNonPagedPool.

• Appeler MmMapLockedPages sur un MDL qui n’a pas les indicateurs appropriés. Par exemple, il est incorrect d’appeler MmMapLockedPages pour un MDL déjà mappé à une adresse système ou mdL qui n’est pas verrouillé.

• Appel de MmUnlockPages ou MmUnmapLockedPages sur un MDL partiel, autrement dit, un MDL créé avec IoBuildPartialMdl.

• Appel de MmUnmapLockedPages sur un MDL qui n’est pas mappé à une adresse système.

Si le vérificateur de pilote n’est pas actif, ces violations peuvent ne pas entraîner l’arrêt du système immédiatement dans tous les cas. Le vérificateur de pilotes surveille le comportement du pilote et émet la vérification des bogues 0xC4 si l’une de ces violations se produit. Consultez Vérification des bogues 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) pour la liste des paramètres de vérification des bogues.

Allocation d’objets de synchronisation à partir de la mémoire NonPagedPoolSession

À compter de Windows 7, le vérificateur de pilotes recherche les objets de synchronisation à partir de la mémoire de session.

Les objets de synchronisation doivent être non modifiables. Ils doivent également vivre dans l’espace d’adressage virtuel global à l’échelle du système.

Un pilote graphique peut allouer de la mémoire de session en appelant des API telles que EngAllocMem. Contrairement à l’espace d’adressage global, l’espace d’adressage de session est virtualisé pour chaque session Terminal Server. Cela signifie que la même adresse virtuelle utilisée dans le contexte de deux sessions différentes fait référence à deux objets différents. Le noyau Windows doit être en mesure d’accéder aux objets de synchronisation à partir de n’importe quelle session Terminal Server. La tentative de référencer une adresse mémoire de session à partir d’une autre session a des résultats imprévisibles, tels que les blocages système ou l’altération silencieuse des données d’une autre session.

À compter de Windows 7, lorsqu’un pilote vérifié initialise un objet de synchronisation en appelant des API telles que KeInitializeEvent ou KeInitializeMutex, Driver Verifier vérifie si l’adresse de l’objet se trouve dans l’espace d’adressage virtuel de session. Si le vérificateur de pilotes détecte ce type d’adresse incorrecte, il émet une vérification de bogue 0xC4 : DRIVER_VERIFIER_DETECTED_VIOLATION, avec une valeur de 0xDF pour le paramètre 1.

Modifications du compteur de référence d’objet comprises entre 0 et 1

À partir de Windows 7, le vérificateur de pilotes recherche des classes supplémentaires de références d’objets incorrectes.

Lorsque le gestionnaire d’objets du noyau Windows crée un objet, tel qu’un objet File ou un objet Thread, le compteur de référence du nouvel objet est défini sur 1. Le compteur de référence est incrémenté par des appels à des API telles que ObReferenceObjectByPointer ou ObReferenceObjectByHandle. Le compteur de référence est décrémenté par chaque appel ObDereferenceObject pour le même objet.

Une fois que le compteur de référence atteint la valeur 0, l’objet devient éligible à la libération. Le gestionnaire d’objets peut le libérer immédiatement, ou il peut le libérer ultérieurement. L’appel d’ObReferenceObjectByPointer ou ObDereferenceObject et la modification du compteur de référence de 0 à 1 signifie incrémenter le compteur de référence d’un objet déjà libéré. Cela est toujours incorrect, car cela peut entraîner l’endommagement de l’allocation de mémoire d’une autre personne.

Blocages ou retards d’arrêt du système

À partir de Windows 7, Driver Verifier provoque une interruption dans le débogueur du noyau si l'arrêt du système ne se termine pas 20 minutes après son démarrage. Le vérificateur de pilotes affecte le début de l’arrêt du système comme heure à laquelle le noyau Windows commence à arrêter ses différents sous-systèmes, tels que le Registre, Plug-And-Play ou les sous-systèmes du gestionnaire d’E/S.

Si un débogueur de noyau n’est pas attaché au système, le vérificateur de pilotes émet un Bug Check 0xC4 : DRIVER_VERIFIER_DETECTED_VIOLATION, avec une valeur de paramètre 1 de 0x115, au lieu de ce point d’arrêt.

Souvent, un arrêt du système qui ne parvient pas à se terminer en moins de 20 minutes indique qu’un des pilotes de périphériques en cours d'exécution sur ce système ne fonctionne pas correctement. L’exécution !analyze -v à partir du débogueur du noyau affiche la trace de pile du fil d’exécution du système responsable de l’arrêt. Vous devez examiner cette trace de pile et déterminer si le thread d’arrêt est bloqué par l’un des pilotes testés.

Parfois, le système ne peut pas s’arrêter car il est soumis à des tests de stress lourds, même si tous les pilotes fonctionnent correctement. L’utilisateur peut choisir de poursuivre l’exécution après ce point d’arrêt du vérificateur de pilotes et vérifier si le système s’arrête finalement.