Condividi tramite

Esaminare gli errori comuni relativi all'affidabilità dei concetti fondamentali del dispositivo

  • Articolo

Questo argomento descrive gli errori di test comuni che è possibile riscontrare quando si eseguono test di affidabilità di Windows Hardware Lab Kit (Windows HLK).

Il test è contrassegnato come non riuscito in HLK Studio, ma il log te.wtl mostra solo i risultati superati

Se il test è contrassegnato come non riuscito in HLK Studio, ma il log te.wtl mostra solo i risultati superati, è possibile ottenere l'errore che ha causato l'errore eseguendo i passaggi seguenti:

  1. Fare clic con il pulsante destro del mouse sull'icona rossa Esegui test
  2. Selezionare l'errore

Verrà visualizzata una finestra di dialogo contenente una descrizione dell'errore che si è verificato.

Il test non è riuscito perché si è verificato un riavvio imprevisto durante il test

Se il testo dell'errore indica che si è verificato un riavvio imprevisto, è probabile che il dispositivo abbia causato il riavvio imprevisto del sistema operativo (BSOD). Per diagnosticare questo errore, collegare un debugger o configurare il computer di test per generare automaticamente dump di memoria completi ed esaminare il controllo dei bug. Per iniziare a eseguire il debug del kernel degli errori di test, vedere Usare il debug del kernel per eseguire il debug degli errori di test relativi all'affidabilità dei concetti fondamentali del dispositivo.

L'attività Controllo stato dispositivo non riesce durante l'installazione

Le attività controllo stato dispositivo spesso hanno esito negativo perché il dispositivo non è configurato correttamente con supporti o una connessione prima dell'avvio dei test. Per informazioni su come configurare correttamente un dispositivo per i test, vedere Prerequisiti di test di affidabilità Device.Fundamentals.

L'attività Controllo stato dispositivo è inclusa nella fase di configurazione di ogni processo di test di affidabilità Di base del dispositivo. Esegue uno strumento per verificare che il dispositivo sottoposto a test (DUT) sia in condizione di funzionamento. In caso di errore, viene creato un log che indica il problema con il dispositivo.

Ad esempio, per i dispositivi Bluetooth, è possibile che venga visualizzato l'errore seguente:

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

Questo messaggio di errore può indicare che, prima del test, è necessario connettersi al dispositivo Bluetooth usando il pannello Controllo audio.

Nell'esempio seguente il dispositivo di test segnala il codice di problema A - CM_PROB_FAILED_START stato. Dovrebbe segnalare il codice di problema 0 (nessun 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

Device Path Exerciser non riesce con "Il thread di test ha superato il limite di timeout. Errore di terminazione del thread"

Quando il test registra il limite di timeout superato il thread di test. Errore di thread irreversibile durante un test dell'esercizio del percorso del dispositivo, il test registra anche l'ultima operazione eseguita. Gli sviluppatori di driver devono determinare il motivo per cui l'ultima operazione registrata causerebbe il blocco del test. Ad esempio:

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

Il test di rimozione della sorpresa ha esito negativo e viene visualizzato il messaggio di errore "Non è stato possibile ricevere IRP_MN_REMOVE_DEVICE dopo la ricezione di IRP_MN_SURPRIedizione Standard_REMOVAL"

Il test del dispositivo DF - PNP Surprise Remove potrebbe non riuscire con il messaggio di errore seguente se il gestore PnP non invia l'IRP di rimozione allo stack di dispositivi di test dopo l'invio dell'IRP di rimozione della sorpresa:

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

Il gestore PnP non invia la richiesta di IRP_MN_REMOVE_DEVICE fino a quando non vengono chiusi tutti gli handle di file in sospeso al dispositivo. Ovvero, il gestore PnP non invia la richiesta di IRP_MN_REMOVE_DEVICE finché il conteggio dei riferimenti del PDO non raggiunge lo zero. Vedere Gestione di una richiesta di IRP_MN_SURPRIedizione Standard_REMOVAL per informazioni su come gestire correttamente IRP_MN_SURPRIedizione Standard_REMOVAL richiesta.

Per facilitare il debug di questo errore di test, è necessario determinare il modo in cui cambia il conteggio dei riferimenti dell'oggetto dispositivo fisico. Identificare il processo che modifica il conteggio dei riferimenti ed esaminare l'aspetto dello stack di chiamate quando viene modificato il conteggio dei riferimenti. Per il debug di questo errore è possibile usare i passaggi seguenti:

  1. Se non è già stato fatto, connettere un debugger del kernel al computer di test. Vedere Configurazione di un computer per la distribuzione, il test e il debug dei driver.

  2. Impostare un punto di interruzione ba (Break on Access) nella posizione in cui è archiviato il conteggio dei riferimenti del PDO del dispositivo di test. Per altre informazioni sui punti di interruzione di accesso, vedere Punti di interruzione processore (ba Breakpoints). Nell'esempio seguente il comando !devnode del debugger del kernel ottiene informazioni sul nodo devnode per il driver USBvideo. L'indirizzo del PDO per questo devnode è 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. Usare il comando !devobj nel PDO per visualizzare informazioni sul conteggio dei riferimenti (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. Esaminare l'oggetto dispositivo PDO usando il comando del debugger del kernel dt (Tipo di visualizzazione). ReferenceCount mostra il numero di handle aperti per il dispositivo associato all'oggetto dispositivo.

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

  5. Se il conteggio dei riferimenti è maggiore di 0 prima di avviare il test:

    • Impostare un punto di interruzione in cui viene creato il PDO.

    • Dopo aver creato il PDO, impostare l'interruzione nel punto di interruzione di accesso (ba) nella posizione in cui è archiviato il conteggio dei riferimenti del PDO.

      Ad esempio, il comando seguente imposta un punto di interruzione ba (Break on Access) nell'oggetto dispositivo (0x849e9648). Il punto di interruzione viene impostato per l'accesso in scrittura all'offset ReferenceCount (+4) con una dimensione di 4 byte (la dimensione di ReferenceCount).

      0: kd> ba w 4 849e9648+4

    • Se il conteggio dei riferimenti del PDO è uguale a 0 prima di avviare il test, è probabile che l'esecuzione del test sia ciò che fa sì che il conteggio dei riferimenti del PDO sia maggiore di zero al momento in cui il test esegue la rimozione a sorpresa del dispositivo. Ciò indica in genere una perdita di handle. Eseguire il test PNP Surprise Remove Device da una finestra del prompt dei comandi o da Visual Studio per riprodurre l'errore e acquisire le informazioni necessarie per risolvere il problema.

    Nota

    Se si imposta il parametro DoConcurrentIO su TRUE, il test apre centinaia di handle di file nel PDO. È consigliabile impostare questo parametro su FAL edizione Standard quando si riproduce questo errore.

  6. Quando si verifica l'interruzione nel punto di interruzione di accesso (ba), è possibile usare i comandi del debugger del kernel !thread e k (Display Stack Backtrace) per eseguire il debug dell'errore. Poiché il conteggio dei riferimenti può cambiare più volte durante l'esecuzione del test, come opzione, è possibile usare il parametro commandString del comando del debugger ba (Break on Access) per ottenere le informazioni necessarie per ogni modifica al conteggio dei riferimenti e continuare comunque a eseguire il test.

    Ad esempio, nell'interruzione seguente al comando di accesso, commandString è costituito da un comando !thread che identificherà il processo che causa la modifica del conteggio dei riferimenti e i comandi .reload ; k 100 che identificano lo stack di chiamate, un comando !devobj per stampare il conteggio dei riferimenti per ogni modifica e g comando per continuare dopo il punto di interruzione.

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

Esempio:

Nell'esempio seguente la chiamata di funzione CreateFile da un thread in esecuzione in cscript.exe causa un incremento al conteggio dei riferimenti. L'acquisizione di tutte le istanze in cui il conteggio dei riferimenti viene modificato durante l'esecuzione del test e l'analisi di questi stack di chiamate può aiutare a identificare le perdite di 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.

Errori di log dei plug-in SimpleIO

I test di affidabilità dei concetti fondamentali del dispositivo usano plug-in I/O semplici WDTF forniti per testare le operazioni di I/O nei dispositivi. I plug-in SimpleIO sono estensioni WDTF che testano funzionalità di I/O specifiche del dispositivo generiche. Se esiste un plug-in WDTF per il tipo di dispositivo da testare, il test usa l'interfaccia IWDTFSimpleIOStresAction2 per testare l'I/O nel dispositivo.

Gli errori registrati dai plug-in WDTF SimpleIO usano il tag WDTF_SIMPLE_IO nel file TestTextLog.log (vedere tag WDTF Object Name. Il messaggio di errore identifica sempre il dispositivo sottoposto a test e il motivo specifico dell'errore.

Esempio:

In questo esempio, il plug-in SimpleIO wireless ha registrato un errore che si sono verificati errori di I/O durante il test di un dispositivo scheda LAN wireless USB 802.11n. In particolare, il plug-in SimpleIO ha eseguito il ping dell'indirizzo del gateway usando una funzione IcmpSendEcho, che ha restituito un errore 11010. Questo errore si traduce in Errore a causa della mancanza di risorse.

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.

Il test di I/O in un determinato dispositivo si blocca in modo permanente e alla fine causa di un timeout

I test di affidabilità dei concetti fondamentali dei dispositivi sono test basati su scenari e combinano i test di I/O con scenari PNP e power test. I test in genere testeranno I/O per due minuti prima e dopo uno scenario. Ad esempio, il test DF - Sospensione con I/O prima e dopo esegue le operazioni seguenti:

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

Il test termina il test di I/O nei dispositivi più volte (una volta per ogni stato di sospensione) quando viene eseguito. Vedere Esaminare i file di log per informazioni su come visualizzare questo file nei file di log.

Uno degli errori comuni durante il test di I/O è che il test di I/O in un determinato dispositivo può bloccarsi in modo permanente. In questo modo, il test avrà esito negativo dopo un periodo di timeout del test(in genere ore). Vedere Risoluzione dei problemi relativi agli errori di test di Windows HLK per informazioni su come identificare gli errori causati dal timeout.

Nota

Windows HLK terminerà il processo bloccato dopo il periodo di timeout. Invece di attendere l'esito negativo del test a causa di un blocco permanente, è consigliabile analizzare il blocco mentre il processo bloccato è ancora in esecuzione nel sistema. Per informazioni su come risolvere i problemi relativi ai blocchi di test, vedere la sezione Relativa ai blocchi di test nell'argomento Risoluzione dei problemi relativi all'affidabilità dei concetti fondamentali del dispositivo tramite Windows HLK .

A seconda del numero di dispositivi su cui viene testato l'I/O, il dispositivo bloccato può essere identificato come segue:

  1. Se il numero di dispositivi su cui è in corso il test di I/O è uno, nella finestra di comando non verrà visualizzato alcun avanzamento per più di dieci minuti. L'ultima voce di log nella finestra di comando avrà un tag WDTF_SIMPLE_IO o WDTF_SIMPLEIO_STRESS e identificherà il dispositivo bloccato. Per altre informazioni su come leggere i file di log di test, vedere Esaminare i file di log.

  2. Se il numero di dispositivi in cui il test sta testando I/O è maggiore di uno, verrà visualizzata una ripetizione costante dei messaggi PerformIO(<Device Name>) Count ... per più di dieci minuti nella finestra di comando. Il test tenta di interrompere il test di I/O in un dispositivo alla volta dopo due minuti di test di I/O su di essi. Se l'operazione di arresto ha esito positivo per un determinato dispositivo, verrà visualizzato un messaggio "Arresta" seguito da un messaggio "Chiudi" per il dispositivo nei log. Se viene visualizzato il messaggio "Arresta", ma il messaggio "Chiudi" corrispondente non viene visualizzato per un dispositivo, significa che il test di I/O in questo dispositivo è bloccato.

Esempio:

Nel caso seguente, il dispositivo mobile broadband è il dispositivo problematico perché è presente un messaggio "Arresta", ma non è presente alcun messaggio "Chiudi" corrispondente. D'altra parte, il dispositivo I2C HID ha sia un messaggio "Stop" che un messaggio "Close", che implica che il test è stato in grado di arrestare l'I/O nel dispositivo senza problemi. Il test non ha mai avuto la possibilità di interrompere i test di I/O nei dispositivi Microsoft Basic Render Driver e Microsoft ACPI-Compliant System; pertanto, i messaggi "PerformIO" vengono visualizzati continuamente per questi dispositivi.

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

Il passaggio successivo consiste nell'esaminare le tracce dello stack dei thread nel processo di test per determinare il motivo per cui il test di I/O sul dispositivo mobile broadband è bloccato. Si scoprirà che uno dei thread nel processo di test viene usato per testare in modo specifico l'I/O nel dispositivo mobile broadband. Per altre informazioni sulla risoluzione dei problemi, vedere Usare il debug del debug di errori di test di affidabilità di Nozioni fondamentali sui dispositivi.

I test non riprendono dalla sospensione

I test di affidabilità dei concetti fondamentali del dispositivo si basano sui timer di riattivazione del sistema per riattivare il sistema di test dagli stati di sospensione durante i test di risparmio energia. I timer di riattivazione difettosi possono impedire al sistema di test di riattivarsi automaticamente durante le esecuzioni dei test. Se il sistema di test non viene riattivato automaticamente dalla sospensione, potrebbe essere necessario contattare il fornitore del BIOS per rilasciare una correzione BIOS per risolvere i problemi del timer di riattivazione o eseguire test in un sistema diverso in cui i timer di riattivazione funzionano come previsto.

Il sistema può anche bloccarsi in modo permanente durante l'accensione o il risparmio di energia a causa di bug del driver. In questo caso, è necessario eseguire nuovamente il test usando il sistema di test connesso a un debugger del kernel ed eseguire il debug del blocco del sistema dal debugger del kernel.

Per informazioni su come configurare un debugger del kernel, vedere Configurazione manuale del debug in modalità kernel. Vedere Risoluzione dei problemi relativi agli errori di test di Windows HLK per indicazioni generali su come risolvere i problemi di blocco del sistema durante le esecuzioni dei test di Windows HLK.

WirelessPlugin: Connessione ToTestProfile() - Impossibile connettersi al profilo di test. Stringa motivo: "La rete specifica non è disponibile". Messaggio di errore

I test dei concetti fondamentali del dispositivo avranno esito negativo con questo messaggio di errore se i valori corretti per i parametri Wpa2PskAesSsid e Wpa2PskPassword non vengono forniti al test in fase di pianificazione dei test. I test richiedono di fornire informazioni di connessione (SSID e password) di una rete wireless di test se uno dei dispositivi sottoposti a test è una scheda WiFi. Per altre informazioni su questi parametri, vedere la sezione parametri della pagina della documentazione del test non superato.

WDTFSensorsPlugin: Open() - Sensore GPS non è stato pronto

I test di affidabilità di Device Fundamentals richiedono che i sistemi con un sensore GPS vengano testati in un ambiente in cui è presente un segnale GPS forte (affinché i test siano in grado di testare l'I/O sul dispositivo del sensore GPS). Questo errore indica che il sensore GPS nel sistema di test non può ottenere una correzione GPS. Prendere in considerazione l'esecuzione dei test in una posizione in cui il sistema di test può ottenere un segnale GPS forte.

Messaggio di log di test: il numero di dispositivi trovati dopo il riavvio (1) non è uguale a prima del riavvio (2); Esaminare i log per trovare i dispositivi mancanti

Questo messaggio indica che uno dei dispositivi non è tornato dopo il riavvio. Per analizzare questo errore, generare e analizzare i log di Setupapi dettagliati per i test Reinstall, Restart e Reboot eseguendo i passaggi seguenti:

  1. Per generare log setupapi dettagliati, impostare la chiave del Registro di sistema KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup! Da LogLevel a 0x2000ffff
  2. Riprovare il problema e quindi esaminare i log setupapi in %windir%\inf\setupapi*
  3. Per la causa radice dei problemi di installazione del dispositivo, vedere Risoluzione dei problemi tramite il file Setupapi.log

Se il log contiene un errore che indica che il dispositivo è mancante o non è stato avviato, eseguire !pnptriage dal debugger ed esaminare l'output. Per altre informazioni sul debug degli errori di test, vedere Usare il debug del kernel per eseguire il debug degli errori di test di affidabilità di Nozioni fondamentali sui dispositivi.

Risoluzione dei problemi relativi ai test di affidabilità dei concetti fondamentali dei dispositivi tramite Windows HLK