Partager via

Déterminer si un pilote fuit des objets d’infrastructure

  • Article

Cette rubrique explique comment rechercher les fuites de mémoire de pilote causées par des références non disponibles. Elle s’applique aux pilotes UMDF (User-Mode Driver Framework) versions 1 et 2.

UMDF 1

Dans UMDF version 1, une pile d’appels peut provoquer une fuite de mémoire si chaque appel à AddRef n’a pas d’appel Release correspondant.

Pour tester si votre pilote UMDF version 1 fuit des objets d’infrastructure, procédez comme suit :

  1. Utilisez l’application de contrôle WDF Verifier pour définir les options de vérificateur souhaitées. Pendant les tests réguliers, commencez par définir TrackObjects et non TrackRefCounts.

    Lorsque le pilote est déchargé, le vérificateur de code du framework entre dans le débogueur si un objet framework n’a pas été supprimé, et il vous invite à utiliser l’extension du débogueur !wudfdumpobjects . Cette extension de débogueur affiche une liste d’objets non supprimés.

  2. Si le vérificateur de code indique que le pilote fuit des objets d’infrastructure, utilisez l’application de contrôle pour définir l’option TrackRefCounts .

    Si cette option est définie, le vérificateur effectue le suivi des références aux objets d’infrastructure pendant l’exécution du pilote. Vous pouvez utiliser l’extension de débogueur !wudfrefhist pour afficher chaque pile d’appels (ensemble d’appels de fonction) qui incrémente ou décrémente le nombre de références d’un objet. En examinant les appels AddRef et Release dans ces piles d’appels, vous devriez être en mesure de trouver une pile qui ne décrémente pas le nombre de références de l’objet et provoque donc la fuite.

Pour plus d’informations sur les options de vérificateur supplémentaires, consultez Utilisation du vérificateur UMDF.

Pour plus d’informations sur la suppression d’objets d’infrastructure, consultez Gestion de la durée de vie des objets.

UMDF 2

Dans UMDF version 2, les références non publiées sont rares, mais peuvent se produire en raison d’incompatibilités d’appel lors de l’utilisation de WdfObjectReference et WdfObjectDereference.

Pour tester si votre pilote UMDF version 2 fuit des objets d’infrastructure, procédez comme suit :

  1. Suivez les étapes décrites dans Meilleures pratiques pour configurer votre ordinateur pour le débogage UMDF.

  2. Pour utiliser le suivi des balises, activez le vérificateur UMDF et gérez le suivi dans le Registre. Ces deux paramètres sont stockés dans la sous-clé Parameters\Wdf du pilote de la clé de nom> du piloteHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WUDF\Services\<.

    Pour activer le vérificateur UMDF, définissez une valeur différente de zéro pour VerifierOn.

    Pour activer le suivi des handles, définissez la valeur de TrackHandles sur le nom d’un ou plusieurs types d’objets, ou spécifiez un astérisque (*) pour effectuer le suivi de tous les types d’objets.

    Vous pouvez également modifier les paramètres du vérificateur UMDF à l’aide de l’application WdfVerifier.exe .

  3. Redémarrez, établissez une connexion de débogueur, puis utilisez les commandes de débogueur suivantes :

Si le vérificateur UMDF est activé, des fuites de mémoire sont détectées au moment du déchargement du pilote, tout comme dans KMDF.

Pour plus d’informations sur l’utilisation du nombre de références dans les pilotes KMDF et UMDF version 2, consultez Framework Object Life Cycle.