Revisión de errores comunes de prueba de confiabilidad de los aspectos básicos del dispositivo

En este tema se describen los errores de prueba comunes que puede encontrar al ejecutar pruebas de confiabilidad de los aspectos básicos de la confiabilidad del Kit de hardware de Windows (HLK) de Windows Hardware Lab Kit (Windows HLK).

La prueba se marca como errónea en HLK Studio, pero el registro te.wtl solo muestra los resultados de paso.

Si la prueba se marca como errónea en HLK Studio, pero el registro de te.wtl solo muestra resultados superados, puede obtener el error que provocó el error ejecutando los pasos siguientes:

1. Haga clic con el botón derecho en el icono rojo Ejecutar prueba
2. Seleccionar error

Aparecerá un cuadro de diálogo que contiene una descripción del error que se produjo.

Error en la prueba porque se produjo un reinicio inesperado durante las pruebas

Si el texto del error indica que se ha producido un reinicio inesperado, es probable que el dispositivo haga que el sistema operativo se reinicie inesperadamente (BSOD). Para diagnosticar este error, adjunte un depurador o configure la máquina de prueba para generar automáticamente volcados de memoria completos e investigue la comprobación de errores. Para empezar a trabajar con la depuración del kernel de errores de prueba, consulte Uso de la depuración de kernel para depurar errores de prueba de confiabilidad de Device Fundamentals.

Se produce un error en la tarea Comprobación de estado del dispositivo durante la instalación

Las tareas de comprobación de estado del dispositivo suelen producir un error porque el dispositivo no está configurado correctamente con medios o una conexión antes de que se inicien las pruebas. Para obtener información sobre cómo configurar correctamente un dispositivo para las pruebas, consulte Requisitos previos de prueba de confiabilidad de Device.Fundamentals.

La tarea Comprobación de estado del dispositivo se incluye en la fase de configuración de cada trabajo de prueba de confiabilidad de los aspectos básicos del dispositivo. Ejecuta una herramienta para comprobar que el dispositivo sometido a prueba (DUT) está en condiciones de trabajo. Si se produce un error, se crea un registro que indica el problema con el dispositivo.

Por ejemplo, en el caso de los dispositivos Bluetooth, podría obtener el siguiente error:

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

Este mensaje de error puede indicar que, antes de las pruebas, debe conectarse al dispositivo Bluetooth mediante el panel Control de audio.

En el ejemplo siguiente, el dispositivo de prueba notifica el código de problema A: CM_PROB_FAILED_START estado. Debe notificar el código del problema 0 (sin problema).

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

Error del ejercicio de ruta de acceso del dispositivo con "El subproceso de prueba superó el límite de tiempo de espera. Error de terminación del subproceso"

Cuando la prueba registra el límite de tiempo de espera superado el subproceso de prueba. Error de error de terminación del subproceso durante una prueba del ejercicio de ruta de acceso del dispositivo, la prueba también registra la última operación que realizó. Los desarrolladores de controladores deben determinar por qué la última operación registrada haría que la prueba se bloqueara. Por ejemplo:

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

Se produce un error en la prueba de eliminación sorpresa con el mensaje de error "No se pudo recibir IRP_MN_REMOVE_DEVICE después de recibir IRP_MN_SURPRISE_REMOVAL"

Es posible que se produzca un error en la prueba de eliminación de dispositivo DF - PNP sorpresa con el siguiente mensaje de error si el administrador de PnP no envía el IRP de eliminación de la pila de dispositivos de prueba después de enviar la sorpresa quitar IRP:

"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."

El administrador de PnP no envía la solicitud de IRP_MN_REMOVE_DEVICE hasta que se cierren todos los identificadores de archivos pendientes al dispositivo. Es decir, el administrador de PnP no envía la solicitud de IRP_MN_REMOVE_DEVICE hasta que el recuento de referencias del PDO alcanza cero. Consulte Control de una solicitud de IRP_MN_SURPRISE_REMOVAL para obtener información sobre cómo administrar correctamente IRP_MN_SURPRISE_REMOVAL solicitud.

Para ayudar a depurar este error de prueba, debe determinar cómo cambia el recuento de referencias del objeto de dispositivo físico (PDO). Identifique el proceso que cambia el recuento de referencias y examine el aspecto de la pila de llamadas cuando se cambia el recuento de referencias. Los pasos siguientes se pueden usar para depurar este error:

1. Si aún no lo ha hecho, conecte un depurador de kernel al equipo de prueba. Consulte Configuración de un equipo para la implementación de controladores, las pruebas y la depuración.

2. Establezca un punto de interrupción ba (Interrumpir en el acceso) en la ubicación donde se almacena el recuento de referencias del PDO del dispositivo de prueba. Consulte Puntos de interrupción del procesador (puntos de interrupción ba) para obtener más información sobre los puntos de interrupción de acceso. En el ejemplo siguiente, el comando !devnode del depurador de kernel obtiene información sobre el devnode para el controlador USBvideo. La dirección del PDO para este devnode es 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. Use el comando !devobj en el PDO para mostrar información sobre el recuento de referencias (RefCount) del PDO.

   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. Examine el objeto de dispositivo PDO mediante el comando del depurador de kernel dt (Tipo de visualización ). ReferenceCount muestra el número de identificadores abiertos para el dispositivo asociado al objeto device.

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

5. Si el recuento de referencias es mayor que 0 antes de iniciar la prueba:

   • Establezca un punto de interrupción donde se cree el PDO.

   • Una vez creado el PDO, establezca el punto de interrupción en el punto de interrupción de acceso (ba) en la ubicación donde se almacena el recuento de referencias del PDO.

     Por ejemplo, el siguiente comando establece un punto de interrupción ba (Interrumpir en access) en el objeto de dispositivo (0x849e9648). El punto de interrupción se establece en el acceso de escritura a ReferenceCount (+4 desplazamiento) con un tamaño de 4 bytes (el tamaño de ReferenceCount).

     0: kd> ba w 4 849e9648+4 
     

   • Si el recuento de referencias del PDO es igual a 0 antes de iniciar la prueba, es probable que la ejecución de la prueba sea lo que hace que el recuento de referencias del PDO sea mayor que cero en el momento en que la prueba realice la eliminación sorpresa del dispositivo. Esto suele indicar una fuga de identificadores. Ejecute la prueba de quitar dispositivo de PNP sorpresa desde una ventana del símbolo del sistema o desde Visual Studio para reproducir el error y capturar la información necesaria para solucionar el problema.

   Nota

   Si establece el parámetro DoConcurrentIO en TRUE, la prueba abre cientos de identificadores de archivo en el PDO. Se recomienda establecer este parámetro en FALSE al reproducir este error.

6. Cuando se produce la interrupción en el punto de interrupción de acceso (ba), puede usar los comandos del depurador del kernel !thread y k (Display Stack Backtrace) para depurar el error. Dado que el recuento de referencias puede cambiar varias veces durante el curso de la ejecución de la prueba, como opción, puede usar el parámetro commandString del comando del depurador ba (Interrumpir en Access) para obtener la información que necesita en cada cambio en el recuento de referencias y seguir probando.

   Por ejemplo, en el siguiente salto en el comando de acceso, commandString consta de un comando !thread que identificará el proceso que provocará el cambio del recuento de referencias y los comandos .reload ; k 100 que identificarán la pila de llamadas, un comando !devobj para imprimir el recuento de referencias en cada cambio y el comando g para continuar después del punto de interrupción.

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

Ejemplo:

En el ejemplo siguiente, la llamada a la función CreateFile desde un subproceso que se ejecuta en cscript.exe provoca un incremento en el recuento de referencias. Capturar todas las instancias en las que se cambia el recuento de referencias mientras se ejecuta la prueba y analizar estas pilas de llamadas puede ayudar a identificar las fugas de identificadores.

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.

Errores de registro de complementos de SimpleIO

Las pruebas de confiabilidad de los aspectos básicos del dispositivo usan complementos de E /S simples WDTF proporcionados para probar E/S en dispositivos. Los complementos simpleIO son extensiones WDTF que prueban la funcionalidad genérica de E/S específica del dispositivo. Si existe un complemento WDTF para el tipo de dispositivo que se está probando, la prueba usa la interfaz IWDTFSimpleIOStressAction2 para probar la E/S en el dispositivo.

Los errores registrados por los complementos de WDTF SimpleIO usan la etiqueta WDTF_SIMPLE_IO en el archivo TestTextLog.log (consulte etiquetas de nombre de objeto WDTF). El mensaje de error siempre identifica el dispositivo sometido a prueba y el motivo específico del error.

Ejemplo:

En este ejemplo, el complemento Wireless SimpleIO registró un error en el que se produjeron errores de E/S durante la prueba de un dispositivo lan inalámbrico USB 802.11n. En concreto, el complemento SimpleIO ha hecho ping a la dirección de la puerta de enlace mediante una función IcmpSendEcho, que devolvió un error 11010. Este error se traduce en Error debido a la falta de recursos.

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.

La prueba de E/S en un dispositivo determinado se bloquea permanentemente y, finalmente, hace que se produzca un error en la prueba debido a un tiempo de espera.

Las pruebas de confiabilidad de los aspectos básicos del dispositivo son pruebas basadas en escenarios y combinan pruebas de E/S con escenarios de prueba de energía PNP & . Las pruebas normalmente probarán la E/S durante dos minutos antes y después de un escenario. Por ejemplo, la prueba DF - Suspensión con E/S antes y después hace lo siguiente:

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

La prueba termina probando la E/S en dispositivos varias veces (una vez para cada estado de suspensión) cuando se ejecuta. Consulte Revisar archivos de registro para obtener información sobre cómo ver esto en los archivos de registro.

Uno de los errores comunes al probar E/S es que las pruebas de E/S en un dispositivo determinado pueden bloquearse permanentemente. Esto da como resultado que se produzca un error en la prueba después de un período de tiempo de espera de prueba (que suele ser horas). Consulte Solución de problemas de errores de prueba de HLK de Windows para obtener información sobre cómo identificar los errores causados por el tiempo de espera.

Nota

Windows HLK finalizará el proceso bloqueado después del período de tiempo de espera. En lugar de esperar a que se produzca un error en la prueba debido a un bloqueo permanente, se recomienda investigar el bloqueo mientras el proceso bloqueado sigue ejecutándose en el sistema. Consulte la sección Bloqueos de prueba de la solución de problemas de pruebas de confiabilidad de los aspectos básicos del dispositivo mediante el tema HLK de Windows para obtener información sobre cómo solucionar problemas de bloqueos de pruebas.

En función del número de dispositivos en los que se está probando la E/S, el dispositivo bloqueado se puede identificar de la siguiente manera:

1. Si el número de dispositivos en los que la prueba está probando E/S es una, no verá ningún progreso en la ventana de comandos durante más de diez minutos. La última entrada de registro de la ventana de comandos tendrá una etiqueta WDTF_SIMPLE_IO o WDTF_SIMPLEIO_STRESS y identificará el dispositivo bloqueado. Consulte Revisar archivos de registro para obtener más información sobre cómo leer los archivos de registro de prueba.

2. Si el número de dispositivos en los que la prueba está probando E/S es mayor que uno, verá una repetición constante de mensajes PerformIO(<Nombre> de dispositivo) Recuento ... durante más de diez minutos en la ventana de comandos. La prueba intenta detener la prueba de E/S en un dispositivo cada vez después de dos minutos de probar E/S en ellos. Si la operación de detención es correcta para un dispositivo determinado, debería ver un mensaje "Detener" seguido de un mensaje "Cerrar" para el dispositivo en los registros. Si se ve el mensaje "Detener", pero no se ve el mensaje "Cerrar" correspondiente para un dispositivo, implica que se bloquea la E/S de prueba en este dispositivo.

Ejemplo:

En el siguiente caso, el dispositivo de banda ancha móvil es el dispositivo problemático porque hay un mensaje "Detener", pero no hay ningún mensaje "Cerrar" correspondiente. Por otro lado, el dispositivo HID de I2C tiene un mensaje "Detener" y un mensaje "Cerrar", lo que implica que la prueba pudo detener la E/S en el dispositivo sin problemas. La prueba nunca tuvo la oportunidad de detener las pruebas de E/S en los dispositivos Microsoft Basic Render Driver y Microsoft ACPI-Compliant System; por lo tanto, los mensajes "PerformIO" se ven continuamente para estos dispositivos.

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
…
…

El siguiente paso es inspeccionar los seguimientos de pila de los subprocesos en el proceso de prueba para determinar por qué se bloquea la E/S de prueba en el dispositivo de banda ancha móvil. Encontrará que uno de los subprocesos del proceso de prueba se usa para probar específicamente la E/S en el dispositivo de banda ancha móvil. Consulte Uso de la depuración del kernel para depurar errores de prueba de confiabilidad de Device Fundamentals para obtener información adicional sobre la solución de problemas.

Las pruebas no se reanudan desde el modo de suspensión

Las pruebas de confiabilidad de los aspectos básicos del dispositivo dependen de los temporizadores de reactivación del sistema para reactivar el sistema desde los estados de suspensión durante las pruebas de administración de energía. Los temporizadores de reactivación defectuosos pueden impedir que el sistema de prueba se despierte automáticamente durante las ejecuciones de pruebas. Si el sistema de prueba no se despierta automáticamente de la suspensión, es posible que tenga que ponerse en contacto con el proveedor del BIOS para que libere una corrección del BIOS para solucionar los problemas del temporizador de reactivación o ejecutar pruebas en un sistema diferente en el que los temporizadores de reactivación funcionen según lo previsto.

El sistema también puede bloquearse permanentemente durante la encendido o apagado debido a errores del controlador. En este caso, debe volver a ejecutar la prueba mediante el sistema de pruebas conectado a un depurador de kernel y depurar el sistema se bloquea del depurador de kernel.

Consulte Configuración de Kernel-Mode depuración manualmente para obtener información sobre cómo configurar un depurador de kernel. Consulte Solución de problemas de errores de prueba HLK de Windows para obtener instrucciones generales sobre cómo solucionar problemas de bloqueos del sistema durante las ejecuciones de pruebas de HLK de Windows.

WirelessPlugin: ConnectToTestProfile(): no se pudo conectar al perfil de prueba. Cadena de motivo: "La red específica no está disponible". Mensaje de error

Las pruebas de aspectos básicos del dispositivo producirán este mensaje de error si los valores correctos para los parámetros Wpa2PskAesSid y Wpa2PskPassword no se proporcionan a la prueba en el momento de la programación de pruebas. Las pruebas requieren que proporciones información de conexión (SSID y contraseña) de una red inalámbrica de prueba si uno de los dispositivos sometidos a prueba es un adaptador WiFi. Consulte la sección parámetros de la página de documentación de la prueba con errores para obtener más información sobre estos parámetros de prueba.

WDTFSensorsPlugin: Open() - Sensor GPS no ha estado listo

Las pruebas de confiabilidad de los aspectos básicos del dispositivo requieren que los sistemas con un sensor GPS se prueben en un entorno en el que haya una señal GPS fuerte (para que las pruebas puedan probar la E/S en el dispositivo del sensor GPS). Este error indica que el sensor GPS del sistema de prueba no puede obtener una corrección gps. Considere la posibilidad de ejecutar las pruebas en una ubicación donde el sistema de prueba pueda obtener una señal GPS fuerte.

Mensaje de registro de prueba: el número de dispositivos encontrados después del reinicio (1) no es el mismo que antes del reinicio (2); Revise los registros para buscar los dispositivos que faltan.

Este mensaje indica que uno de los dispositivos no volvió después del reinicio. Para investigar este error, genere y analice los registros detallados de Setupapi para reinstalar, reiniciar y reiniciar pruebas mediante la ejecución de los pasos siguientes:

1. Para generar registros detallados de setupapi, establezca la clave del Registro KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup! LogLevel para 0x2000ffff
2. Vuelva a reproducir el problema y revise los registros de Setupapi en %windir%\inf\setupapi*
3. Para solucionar problemas de instalación de dispositivos de causa principal, consulte Solución de problemas mediante el archivo Setupapi.log.

Si el registro contiene un error que indica que falta el dispositivo o no se inició, ejecute !pnptriage desde el depurador y revise la salida. Para obtener más información sobre los errores de prueba de depuración, consulte Uso de la depuración de kernel para depurar errores de prueba de confiabilidad de los conceptos básicos del dispositivo.

Temas relacionados

Solución de problemas de pruebas de confiabilidad de los aspectos básicos del dispositivo mediante Windows HLK