Détermination de la raison pour laquelle le réflecteur a terminé le processus hôte
Cette rubrique décrit comment vous pouvez analyser la raison pour laquelle le réflecteur a arrêté le processus hôte du pilote (WUDFHost.exe) ou pourquoi le processus hôte du pilote s’est arrêté.
La raison la plus courante pour laquelle le réflecteur doit arrêter le processus hôte est l’expiration des délais d’expiration du processus hôte UMDF.
Nous vous recommandons vivement d’effectuer tout le développement et le test de votre pilote UMDF avec un débogueur de noyau attaché au système de test et d’activer Application Verifier (AppVerif.exe) sur WUDFHost.exe. Utilisez la commande suivante, attachez un débogueur de noyau, puis redémarrez.
AppVerif –enable Heaps Exceptions Handles Locks Memory TLS Leak –for WudfHost.exe
Utilisation de fichiers dump
Lorsque votre pilote UMDF se bloque ou rencontre un problème, un arrêt est signalé dans le débogueur du noyau. Ces problèmes doivent être débogués lorsque les exceptions en mode utilisateur sont signalées dans le débogueur du noyau. Les sauts de débogueur du noyau sont également signalés par WudfRd.sys avant de mettre fin à un processus hôte de pilote en raison d’un pilote UMDF problématique (non réactif). Vous trouverez également les journaux et les vidages de tas signalés à l’emplacement suivant. Pour passer en revue les fichiers de vidage capturés par UMDF, procédez comme suit :
Recherchez le dernier fichier .dmp dans le répertoire %ProgramData%\Microsoft\WDF. Avant UMDF 2.15 fourni avec Windows 10 1507, le répertoire du journal est sous %windir%\system32\LogFiles\WUDF.
Chargez le dernier fichier .dmp dans le débogueur à l’aide de la commande suivante :
WinDbg -z <path to the .dmp file>Examinez l’état des threads au moment de l’arrêt.
Si vous avez besoin de vidages de tas capturés, au moment du test, définissez les valeurs de Registre suivantes et relancez votre système de test avant d’exécuter des tests. Vous pouvez également examiner l’historique des rapports d’erreurs Windows à partir du journal des événements de l’application du système sur %SystemRoot%\System32\Winevt\Logs\Application.evtx
reg add "HKLM\Software\Microsoft\windows NT\CurrentVersion\Wudf" /v LogMinidumpType /t REG_DWORD /d 0x1122
reg add "HKLM\Software\Microsoft\windows NT\CurrentVersion\Wudf" /v LogEnable /t REG_DWORD /d 1
Utilisation du débogueur
Dans d’autres cas, vous devrez peut-être attacher à une cible en mode noyau actif pour déterminer pourquoi le réflecteur a arrêté le processus hôte. Pour configurer votre session de débogage, suivez les étapes décrites dans Comment activer le débogage d’un pilote UMDF.
Une fois que vous avez établi une connexion, utilisez !wdfkd.wdfumtriage pour examiner les pilotes UMDF, affichez les irPs en attente à l’aide de l’extension de débogueur UMDF !wdfkd.wdfumirps ( !wudfext.umirps pour UMDF version 1).
Si un IRP PnP ou un IRP d’alimentation est en attente, déterminez pourquoi le pilote provoque le blocage de l’IRP en examinant les threads dans le processus hôte.
Vous pouvez utiliser l’extension !process pour examiner les threads en cours d’exécution dans le processus hôte. La valeur des indicateurs 0x1f affiche la trace de pile pour chaque thread.
!process process <addr> 0x1f
Si votre pilote n’a pas terminé rapidement un IRP annulé, déterminez le protocole IRP qui a été annulé et pourquoi il n’a pas terminé.
Si un IRP de nettoyage ou de fermeture est en attente, déterminez pourquoi l’IRP prend beaucoup de temps pour traiter.