Partager via

Passer en revue les échecs courants des tests de fiabilité des principes de base de l’appareil

  • Article

Cette rubrique décrit les échecs de test courants que vous pouvez rencontrer lorsque vous exécutez des tests de fiabilité des principes de base de l’appareil du Kit Hardware Lab Windows (Windows HLK).

Le test est marqué comme ayant échoué dans HLK Studio, mais le journal te.wtl affiche uniquement les résultats de réussite

Si le test est marqué comme ayant échoué dans HLK Studio, mais que le journal te.wtl affiche uniquement les résultats de réussite, vous pouvez obtenir l’erreur qui a provoqué l’échec en exécutant les étapes suivantes :

  1. Cliquez avec le bouton droit sur l’icône rouge Exécuter le test
  2. Sélectionner une erreur

Une boîte de dialogue contenant une description de l’erreur qui s’est produite s’affiche.

Le test a échoué car un redémarrage inattendu s’est produit pendant le test

Si le texte d’erreur indique qu’un redémarrage inattendu s’est produit, cela signifie probablement que l’appareil a provoqué un redémarrage inattendu du système d’exploitation (BSOD). Pour diagnostiquer cet échec, attachez un débogueur ou configurez l’ordinateur de test de manière à générer automatiquement des vidages de mémoire complets et examinez le bogue case activée. Pour commencer à déboguer le noyau des échecs de test, consultez Utiliser le débogage du noyau pour déboguer les échecs de test de fiabilité des principes de base des appareils.

Échec de la tâche de vérification de l’état de l’appareil pendant l’installation

Les tâches de vérification de l’état de l’appareil échouent souvent, car l’appareil n’est pas correctement configuré avec un média ou une connexion avant le début des tests. Pour plus d’informations sur la configuration correcte d’un appareil à des fins de test, consultez Device.Fundamentals Reliability Testing Prerequisites.

La tâche De vérification de l’état de l’appareil est incluse dans la phase de configuration de chaque travail de test de fiabilité des principes fondamentaux de l’appareil. Il exécute un outil pour vérifier que l’appareil testé (DUT) est en état de fonctionnement. En cas d’échec, un journal est créé qui indique le problème avec l’appareil.

Par exemple, pour les appareils Bluetooth, vous pouvez obtenir l’erreur suivante :

PerformIO(Example ) Failed : Streaming error capturing audio HRESULT=0x8445001F Count 1

Ce message d’erreur peut indiquer qu’avant le test, vous devez vous connecter à l’appareil Bluetooth à l’aide du Panneau de configuration audio.

Dans l’exemple suivant, l’appareil de test signale le code de problème A - CM_PROB_FAILED_START status. Il doit signaler le code de problème 0 (aucun problème).

WDTF_TARGETS          : INFO  : - Query("IsPhantom=False AND (DeviceID='USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006')")
WDTF_TARGETS          : INFO  : Target: F5321 gw Mobile Broadband Network Adapter USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006 
WDTF_TEST             : ERROR : Found a device that has a non-zero problem code or is phantom. Logging device info.
WDTF_TEST             : INFO  : DeviceID:     USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006
WDTF_TEST             : INFO  : DisplayName:  F5321 gw Mobile Broadband Network Adapter
WDTF_TEST             : INFO  : Status:       Status Flags=0x1802400 (DN_HAS_PROBLEM DN_DISABLEABLE DN_NT_ENUMERATOR DN_NT_DRIVER) Problem Code=a (CM_PROB_FAILED_START)
WDTF_TEST             : INFO  : IsPhantom:    False

L’exercice du chemin d’accès de l’appareil échoue avec « Le thread de test a dépassé la limite de délai d’expiration. Erreur de fin de thread »

Lorsque le test journalise, le thread de test a dépassé la limite de délai d’expiration. Fin de l’erreur d’erreur de thread lors d’un test d’exercice du chemin d’accès d’appareil, le test journalise également la dernière opération qu’il a effectuée. Les développeurs de pilotes doivent déterminer pourquoi la dernière opération journalisée entraînerait le blocage du test. Par exemple :

WDTF_FUZZTEST : Test thread exceeded timeout limit. Terminating thread
WDTF_FUZZTEST : Last logged operation: ZwDeviceIoControlFile, CtrlCode=0x2b0020, InBuf=0xfffffc00, 0 OutBuf=0xfffffc00, 0

Échec du test Surprise Remove avec le message d’erreur « Échec de la réception de IRP_MN_REMOVE_DEVICE après réception de IRP_MN_SURPRISE_REMOVAL »

Le test DF - PNP Surprise Remove Device Test peut échouer avec le message d’erreur suivant si le gestionnaire PnP n’envoie pas l’IRP de suppression à la pile du périphérique de test après avoir envoyé l’IRP de suppression surprise :

"Failed to receive IRP_MN_REMOVE_DEVICE after receiving IRP_MN_SURPRISE_REMOVAL. Ensure that there are no open handles or references to the test device (in user mode or in kernel mode) preventing IRP_MN_REMOVE_DEVICE from being sent. You may need to terminate any processes or services that may have open user mode handles to this device."

Le gestionnaire PnP n’envoie pas la requête IRP_MN_REMOVE_DEVICE tant que tous les descripteurs de fichiers en attente sur l’appareil ne sont pas fermés. Autrement dit, le gestionnaire PnP n’envoie pas la requête IRP_MN_REMOVE_DEVICE tant que le nombre de références de l’AOP n’a pas atteint zéro. Consultez Gestion d’une demande de IRP_MN_SURPRISE_REMOVAL pour plus d’informations sur la façon de gérer correctement IRP_MN_SURPRISE_REMOVAL demande.

Pour faciliter le débogage de cet échec de test, vous devez déterminer comment le nombre de références de l’objet d’appareil physique (PDO) change. Identifiez le processus qui modifie le nombre de références et examinez à quoi ressemble la pile des appels lorsque le nombre de références est modifié. Les étapes suivantes peuvent être utilisées pour déboguer cet échec :

  1. Si vous ne l’avez pas déjà fait, connectez un débogueur de noyau à l’ordinateur de test. Consultez Configuration d’un ordinateur pour le déploiement, le test et le débogage de pilotes.

  2. Définissez un point d’arrêt ba (Arrêt sur l’accès) à l’emplacement où le nombre de références de l’AOP de l’appareil de test est stocké. Pour plus d’informations sur les points d’arrêt d’accès, consultez Points d’arrêt du processeur (ba) . Dans l’exemple suivant, la commande du débogueur du noyau !devnode obtient des informations sur le devnode pour le pilote USBvideo. L’adresse de l’AOP pour ce devnode est 0x849e9648.

    0: kd> !devnode 0 1 usbvideo
Dumping IopRootDeviceNode (= 0x848fadd8)
DevNode 0x849e9448 for PDO 0x849e9648
  InstancePath is "USB\VID_045E&PID_076D&MI_00\7&1243e0b7&0&0000"
  ServiceName is "usbvideo"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)

  3. Utilisez la commande !devobj sur l’ADO pour afficher des informations sur le nombre de références (RefCount) de l’AOP.

    0: kd> !devobj 0x849e9648
Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy

  4. Examinez l’objet de périphérique PDO à l’aide de la commande de débogueur du noyau dt (Type d’affichage). L’objet ReferenceCount indique le nombre de handles ouverts pour l’appareil qui sont associés à l’objet device.

    0: kd> dt nt!_DEVICE_OBJECT 849e9648  
…
   +0x002 Size             : 0x398
   +0x004 ReferenceCount   : 0n0
   +0x008 DriverObject     : 0x8727e120 _DRIVER_OBJECT
..
…

  5. Si le nombre de références est supérieur à 0 avant de commencer le test :

    • Définissez un point d’arrêt où l’AOP est créé.

    • Une fois l’AOP créée, définissez le point d’arrêt d’accès (ba) à l’emplacement où le nombre de références de l’AOP est stocké.

      Par exemple, la commande suivante définit un point d’arrêt ba (Break on Access) sur l’objet d’appareil (0x849e9648). Le point d’arrêt est défini sur l’accès en écriture au ReferenceCount (décalage +4) avec une taille de 4 octets (taille de ReferenceCount).

      0: kd> ba w 4 849e9648+4

    • Si le nombre de références de l’AOP est égal à 0 avant de commencer le test, il est probable que l’exécution du test est ce qui fait que le nombre de références de l’AOP est supérieur à zéro au moment où le test effectue la suppression surprise de l’appareil. Cela indique généralement une fuite de handle. Exécutez le test PNP Surprise Remove Device à partir d’une fenêtre d’invite de commandes ou de Visual Studio pour reproduire l’échec et capturer les informations nécessaires pour résoudre le problème.

    Notes

    Si vous définissez le paramètre DoConcurrentIO sur TRUE, le test ouvre des centaines de descripteurs de fichiers à l’AOP. Nous vous recommandons de définir ce paramètre sur FALSE lorsque vous reproduisez cet échec.

  6. Lorsque le point d’arrêt d’accès (ba) se produit, vous pouvez utiliser les commandes du débogueur du noyau !thread et k (Display Stack Backtrace) pour déboguer l’échec. Étant donné que le nombre de références peut changer plusieurs fois au cours de l’exécution du test, vous pouvez utiliser le paramètre commandString de la commande du débogueur ba (Break on Access) pour obtenir les informations dont vous avez besoin sur chaque modification apportée au nombre de références, tout en continuant à tester.

    Par exemple, dans la commande d’arrêt d’accès suivante, la commande commandString se compose d’une commande !thread qui identifie le processus à l’origine de la modification du nombre de références, et des commandes .reload ; k 100 qui identifient la pile des appels, d’une commande !devobj pour imprimer le nombre de références sur chaque modification et de la commande g pour continuer après le point d’arrêt.

    0: kd> ba w 4 849e9648+4 "!thread; .thread /p /r; .reload; k 100; !devobj 849e9648; g"

Exemple :

Dans l’exemple suivant, l’appel de fonction CreateFile à partir d’un thread en cours d’exécution dans cscript.exe provoque un incrément du nombre de références. La capture de toutes les instances où le nombre de références est modifié lors de l’exécution du test et l’analyse de ces piles d’appels peut aider à identifier les fuites de handle.

THREAD 87eb3d40  Cid 1094.1490  Teb: 7f5a8000 Win32Thread: 82da2210 RUNNING on processor 3
Not impersonating
DeviceMap                 a71b3228
Owning Process            88199cc0       Image:         cscript.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1232688        Ticks: 0
Context Switch Count      18             IdealProcessor: 2             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address ntdll!TppWorkerThread (0x7710704d)
Stack Init a6ebfde0 Current a6ebfa6c Base a6ec0000 Limit a6ebd000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr  Args to Child              
a6ebfa50 814a73fe f81771f8 814a72e5 8281000e nt!IopCheckDeviceAndDriver+0x61 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 849e9648 848f9200 87164008 nt!IopParseDevice+0x11d (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f874 7710689d ffffffff 77195ae2 00000000 ntdll!__RtlUserThreadStart+0x4a (FPO: [SEH]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 7710704d 0031c540 00000000 ntdll!_RtlUserThreadStart+0x1c (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Implicit thread is now 87eb3d40
Connected to Windows 8 9200 x86 compatible target at (Wed Sep 19 21:04:27.601 2012 (UTC - 7:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
................................................................
...........................
Loading unloaded module list
.....................
ChildEBP RetAddr  
a6ebfa50 814a73fe nt!IopCheckDeviceAndDriver+0x61 [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 nt!IopParseDevice+0x11d [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f2d4 6970274e KERNELBASE!CreateFileW+0x61 [d:\w8rtm\minkernel\kernelbase\fileopcr.c @ 1194]
0236f31c 6b6ce0e1 deviceaccess!CDeviceBroker::OpenDeviceFromInterfacePath+0x178 [d:\w8rtm\base\devices\broker\dll\broker.cpp @ 177]
0236f34c 6b6cc5c0 MFCORE!CDevProxy::CreateKsFilter+0x46 [d:\w8rtm\avcore\mf\core\transforms\devproxy\devproxy.cpp @ 2263]
…
…
0236f874 7710689d ntdll!__RtlUserThreadStart+0x4a [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 ntdll!_RtlUserThreadStart+0x1c [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 1 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy.

Échecs du journal des plug-ins SimpleIO

Les tests de fiabilité de base des appareils utilisent des plug-ins d’E/S simples WDTF fournis pour tester les E/S sur les appareils. Les plug-ins SimpleIO sont des extensions WDTF qui testent les fonctionnalités d’E/S génériques spécifiques à l’appareil. S’il existe un plug-in WDTF pour le type d’appareil testé, le test utilise l’interface IWDTFSimpleIOStressAction2 pour tester les E/S sur l’appareil.

Les erreurs enregistrées par les plug-ins WDTF SimpleIO utilisent la balise WDTF_SIMPLE_IO dans le fichier TestTextLog.log (voir Balises de nom d’objet WDTF. Le message d’erreur identifie toujours l’appareil testé et la raison spécifique de l’échec.

Exemple :

Dans cet exemple, le plug-in Wireless SimpleIO a enregistré une défaillance indiquant que des échecs d’E/S se sont produits lors du test d’un périphérique de carte LAN sans fil USB 802.11n. Plus précisément, le plug-in SimpleIO a effectué un test ping sur l’adresse de la passerelle à l’aide d’une fonction IcmpSendEcho, qui a renvoyé une erreur 11010. Cette erreur se traduit par Erreur en raison d’un manque de ressources.

WDTF_SIMPLE_IO            : ERROR :  - PerformIO(802.11n USB Wireless LAN Card USB\VID_XXXX&PID_XXXX\X&XXXXXXX&X&X ) Failed : WirelessPlugin: TestPingGateway() - IcmpSendEcho() call failed several times. The error reported is for the last failure instance Win32=11010 - Error due to lack of resources.

Le test des E/S sur un appareil particulier se bloque définitivement et finit par entraîner l’échec du test en raison d’un délai d’expiration

Les tests de fiabilité De base des appareils sont des tests basés sur des scénarios et combinent des tests d’E/S avec des scénarios de test d’alimentation PNP & . Les tests testent généralement les E/S pendant deux minutes avant et après un scénario. Pour instance, le test DF - Sleep with IO Before and After effectue les opérations suivantes :

For each sleep state supported on the system (CS, S1, S2, S3, S4)

Test I/O on devices with I/O plugins in parallel (one thread per device) for 2 minutes

Enter sleep state & exit after 2 minutes

Next

Le test finit par tester les E/S sur les appareils plusieurs fois (une fois pour chaque état de veille) lorsqu’il s’exécute. Pour plus d’informations sur la façon de le voir dans les fichiers journaux, consultez Examiner les fichiers journaux.

L’un des échecs courants lors du test d’E/S est que le test d’E/S sur un appareil particulier peut se bloquer définitivement. Cela entraîne l’échec du test après un délai d’expiration de test (généralement en heures). Consultez Résolution des échecs de test Windows HLK pour plus d’informations sur la façon d’identifier les échecs causés par le délai d’expiration.

Notes

Windows HLK met fin au processus suspendu après le délai d’expiration. Au lieu d’attendre que le test échoue finalement en raison d’un blocage permanent, nous vous recommandons d’examiner le blocage pendant que le processus suspendu est toujours en cours d’exécution sur le système. Pour plus d’informations sur la résolution des blocages de test, consultez la section Problèmes de fiabilité fondamentaux des appareils à l’aide de la rubrique Windows HLK .

Selon le nombre d’appareils sur lequel les E/S sont testées, l’appareil suspendu peut être identifié comme suit :

  1. Si le nombre d’appareils sur lesquels le test teste les E/S est un, vous ne verrez aucune progression dans la fenêtre de commande pendant plus de dix minutes. La dernière entrée de journal dans la fenêtre de commande aura une balise WDTF_SIMPLE_IO ou WDTF_SIMPLEIO_STRESS et identifiera l’appareil bloqué. Pour plus d’informations sur la lecture des fichiers journaux de test, consultez Examiner les fichiers journaux.

  2. Si le nombre d’appareils sur lesquels le test teste les E/S est supérieur à un, vous verrez une répétition constante des messages PerformIO(<Device Name>) Count... pendant plus de dix minutes dans la fenêtre de commande. Le test tente d’arrêter le test des E/S sur un appareil à la fois après deux minutes de test d’E/S sur ceux-ci. Si l’opération d’arrêt réussit pour un appareil particulier, vous devez voir un message « Arrêter » suivi d’un message « Fermer » pour l’appareil dans les journaux. Si le message « Arrêter » s’affiche, mais que le message « Fermer » correspondant n’est pas visible pour un appareil, cela signifie que le test d’E/S sur cet appareil est suspendu.

Exemple :

Dans le cas suivant, l’appareil haut débit mobile est l’appareil à problème, car il existe un message « Arrêter », mais aucun message « Fermer » correspondant. En revanche, l’appareil HID I2C a à la fois un message « Arrêter » et un message « Fermer », ce qui signifie que le test a pu arrêter les E/S sur l’appareil sans aucun problème. Le test n’a jamais eu l’occasion d’arrêter le test d’E/S sur les appareils Microsoft Basic Render Driver et Microsoft ACPI-Compliant System ; Par conséquent, les messages « PerformIO » sont affichés en continu pour ces appareils.

WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLE_IO            : INFO  :  - Close(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(XYZ Mobile Broadband Device USB\VEN_XXX&PID_XXX\X&XXXXXX&X&X)
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…

L’étape suivante consiste à inspecter les traces de pile des threads dans le processus de test pour déterminer pourquoi le test d’E/S sur l’appareil haut débit mobile est suspendu. Vous constaterez que l’un des threads du processus de test est utilisé pour tester spécifiquement les E/S sur l’appareil haut débit mobile. Pour plus d’informations sur la résolution des problèmes, consultez Utiliser le débogage du noyau pour déboguer les échecs de test de fiabilité fondamentaux de l’appareil.

Les tests ne reprennent pas à partir de la veille

Les tests de fiabilité des principes de base de l’appareil s’appuient sur les minuteurs de veille du système pour sortir le système de test des états de veille pendant les tests de gestion de l’alimentation. Les minuteurs de veille défectueux peuvent empêcher le système de test de se réveiller automatiquement pendant les séries de tests. Si le système de test ne se réveille pas automatiquement de la veille, vous devrez peut-être contacter votre fournisseur du BIOS pour qu’il publie un correctif BIOS pour résoudre les problèmes liés au minuteur de veille, ou exécuter des tests sur un autre système où les minuteurs de veille fonctionnent comme prévu.

Le système peut également se bloquer définitivement pendant la mise sous tension ou la mise hors tension en raison de bogues de pilote. Dans ce cas, vous devez réexécuter le test à l’aide du système de test connecté à un débogueur de noyau et déboguer le blocage du système à partir du débogueur du noyau.

Pour plus d’informations sur la configuration d’un débogueur de noyau , consultez Configuration manuelle Kernel-Mode débogage . Consultez Résolution des échecs de test Windows HLK pour obtenir des conseils généraux sur la façon de résoudre les blocages système pendant les séries de tests Windows HLK.

WirelessPlugin : ConnectToTestProfile() - Échec de la connexion au profil de test. Chaîne de raison : « Le réseau spécifique n’est pas disponible ». Message d’erreur

Les tests Device Fundamentals échouent avec ce message d’erreur si les valeurs correctes pour les paramètres Wpa2PskAesSsid et Wpa2PskPassword ne sont pas fournies au test au moment de la planification des tests. Les tests vous obligent à fournir des informations de connexion (SSID et mot de passe) d’un réseau sans fil de test si l’un des appareils testés est un adaptateur Wi-Fi. Pour plus d’informations sur ces paramètres, consultez la section paramètres de la page de documentation du test ayant échoué.

WDTFSensorsPlugin : Open() - Le capteur GPS n’est pas passé à l’état prêt

Les tests de fiabilité de base de l’appareil nécessitent que les systèmes dotés d’un capteur GPS soient testés dans un environnement où il existe un signal GPS fort (afin que les tests puissent tester les E/S sur l’appareil de capteur GPS). Cette erreur indique que le capteur GPS du système de test ne peut pas obtenir de correctif GPS. Envisagez d’exécuter les tests à un endroit où le système de test peut obtenir un signal GPS fort.

Message du journal de test : le nombre d’appareils trouvés après le redémarrage (1) n’est pas le même qu’avant le redémarrage (2) ; consultez les journaux pour trouver le ou les appareils manquants.

Ce message indique que l’un des appareils n’est pas revenu après le redémarrage. Pour examiner cet échec, générez et analysez les journaux Setupapi détaillés pour les tests de réinstallation, de redémarrage et de redémarrage en effectuant les étapes suivantes :

  1. Pour générer des journaux setupapi détaillés, définissez la clé de Registre KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup! LogLevel à 0x2000ffff
  2. Repromettez le problème, puis passez en revue les journaux Setupapi sur %windir%\inf\setupapi*
  3. Pour connaître la cause racine des problèmes d’installation de l’appareil, consultez Résolution des problèmes à l’aide du fichier Setupapi.log

Si le journal contient une erreur indiquant que l’appareil était manquant ou n’a pas démarré, exécutez !pnptriage à partir du débogueur et passez en revue la sortie. Pour plus d’informations sur les échecs de test de débogage, consultez Utiliser le débogage du noyau pour déboguer les échecs de test de fiabilité de base des appareils.

Résolution des problèmes de test de fiabilité des principes de base de l’appareil à l’aide de Windows HLK