Détermination de la raison pour laquelle le réflecteur a arrêté le processus hôte

Cette rubrique explique 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 bloqué.

La raison la plus courante pour laquelle le réflecteur arrête 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 des exceptions en mode utilisateur sont signalées dans le débogueur du noyau. Les interruptions du débogueur du noyau sont également signalées par WudfRd.sys avant qu’il arrête un processus hôte de pilote en raison d’un pilote UMDF problématique (non réactif). Vous trouverez également des journaux et des vidages de tas signalés à l’emplacement suivant. Pour passer en revue les fichiers de vidage capturés par UMDF, procédez comme suit :

1. Recherchez le dernier fichier .dmp dans le répertoire %ProgramData%\Microsoft\WDF. Avant UMDF 2.15 fourni avec Windows 10 1507, le répertoire des journaux se trouve sous %windir%\system32\LogFiles\WUDF.

2. Chargez le fichier .dmp le plus récent dans le débogueur à l’aide de la commande suivante :

   WinDbg -z <path to the .dmp file>
   

3. Examinez l’état des threads au moment de l’arrêt.

Si vous avez besoin de captures de vidages de tas, au moment du test, définissez les valeurs de Registre suivantes et redémarrez votre système de test avant d’exécuter les tests. Vous pouvez également examiner Rapport d'erreurs Windows historique à partir du journal des événements des applications du système à l’adresse %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, afficher les irPs en suspens à 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 0x1f indicateurs vous montre la trace de la pile pour chaque thread.

  !process<addr>0x1f

• Si votre pilote n’a pas effectué rapidement un IRP annulé, déterminez quel IRP a été annulé et pourquoi il ne s’est pas terminé.

• Si un IRP de nettoyage ou de fermeture est en attente, déterminez pourquoi le traitement de l’IRP prend beaucoup de temps.