Partager via

Vérifications automatiques

  • Article

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 la Windows 10, version 1709, ces vérifications automatiques ont été déplacées dans les indicateurs standard appropriés. Par conséquent, les utilisateurs qui activent Driver Verifier avec les indicateurs standard ne doivent pas voir de réduction des vérifications appliquées.

Surveillance des routines IRQL et mémoire

Driver Verifier surveille le pilote sélectionné pour les actions interdites suivantes :

  • Déclenchement de l’IRQL en appelant KeLowerIrql

  • Abaissement de l’IRQL 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

  • Tentative de libération d’une adresse qui n’a pas été retournée à partir d’une allocation précédente

  • Tentative de libération d’une adresse 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 différent de DISPATCH_LEVEL

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

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

Si Driver Verifier n’est pas actif, ces violations peuvent ne pas provoquer un plantage immédiat du système dans tous les cas. Driver Verifier surveille le comportement du pilote et émet des bogues case activée 0xC4 si l’une de ces violations se produit. Pour obtenir la liste des paramètres de case activée, consultez Vérification des bogues 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION).

Supervision du basculement de pile

Le vérificateur de pilotes surveille l’utilisation de la pile par le pilote en cours de vérification. Si le pilote bascule sa pile et que la nouvelle pile n’est ni une pile de threads ni une pile DPC, un bogue case activée est émis. (Il s’agit d’un bogue case activée 0xC4 avec le premier paramètre égal à 0x90.) La pile affichée par la commande du débogueur de base de connaissances révèle généralement 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 été nettoyé.

En particulier, le vérificateur de pilotes recherche les éléments suivants :

  • Minuteurs non supprimés

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

  • Listes de lookaside non supprimées

  • Threads de travail non supprimés

  • Files d’attente non supprimées

  • Autres ressources similaires

De tels problèmes peuvent potentiellement entraîner l’émission de vérifications des bogues système 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 driver Verifier est actif, ces violations entraînent l’émission de bogues case activée 0xC7 immédiatement après le déchargement du pilote. Pour obtenir la liste des paramètres de case activée, consultez Vérification des bogues 0xC7 (TIMER_OR_DPC_INVALID).

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 une MDL qui n’a pas les indicateurs appropriés. Par exemple, il est incorrect d’appeler MmProbeAndLockPages pour une MDL qui a été créée à l’aide de MmBuildMdlForNonPagedPool.

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

  • Appel de MmUnlockPages ou MmUnmapLockedPages sur une MDL partielle, autrement dit, et MDL créée à l’aide d’IoBuildPartialMdl.

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

Si Driver Verifier n’est pas actif, ces violations peuvent ne pas entraîner l’arrêt de la réponse immédiate du système dans tous les cas. Driver Verifier surveille le comportement du pilote et émet des bogues case activée 0xC4 si l’une de ces violations se produit. Pour obtenir la liste des paramètres de case activée, consultez Vérification des bogues 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION).

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

À compter de Windows 7, le vérificateur de pilote 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 des incidents système ou une 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 paramètre 1 de 0xDF.

Le compteur de référence d’objet passe de 0 à 1

À compter de Windows 7, driver verifier 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érences 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 a atteint la valeur 0, l’objet peut être libéré. Le gestionnaire d’objets peut le libérer immédiatement, ou il peut le libérer ultérieurement. Appeler ObReferenceObjectByPointer ou ObDereferenceObject et changer le 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

À compter de Windows 7, driver Verifier émet 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. Driver Verifier 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 pilote émet une vérification de bogue 0xC4 : DRIVER_VERIFIER_DETECTED_VIOLATION, avec un paramètre 1 de 0x115, au lieu de ce point d’arrêt.

Souvent, un arrêt du système qui ne peut pas se terminer en moins de 20 minutes indique que l’un des pilotes qui s’exécute sur ce système ne fonctionne pas correctement. L’exécution de !analyze -v à partir du débogueur du noyau affiche la trace de pile du thread de travail 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 contraintes 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 pilote et case activée si le système finit par s’arrêter.