Compartilhar via

Examinar falhas comuns de teste de confiabilidade de conceitos básicos do dispositivo

  • Artigo

Este tópico descreve falhas de teste comuns que você pode encontrar ao executar testes de Confiabilidade de Conceitos Básicos do Dispositivo windows HLK (Windows Hardware Lab Kit).

O teste é marcado como com falha no HLK Studio, mas o log do te.wtl mostra apenas os resultados aprovados

Se o teste for marcado como com falha no HLK Studio, mas o log do te.wtl mostrar apenas os resultados aprovados, você poderá obter o erro que causou a falha executando as seguintes etapas:

  1. Clique com o botão direito do mouse no ícone vermelho Executar Teste
  2. Selecionar Erro

Uma caixa de diálogo será exibida que contém uma descrição do erro ocorrido.

O teste falhou porque ocorreu uma reinicialização inesperada durante o teste

Se o texto de erro indicar que ocorreu uma reinicialização inesperada, isso provavelmente significa que o dispositivo fez com que o sistema operacional fosse reiniciado inesperadamente (BSOD). Para diagnosticar essa falha, anexe um depurador ou configure o computador de teste para gerar automaticamente despejos de memória completa e investigar o bug marcar. Para começar a usar a depuração de kernel de falhas de teste, consulte Usar a depuração de kernel para depurar falhas de teste de confiabilidade de conceitos básicos do dispositivo.

Falha na tarefa verificação de status do dispositivo durante a instalação

As tarefas de Verificação de Status do Dispositivo geralmente falham porque o dispositivo não está configurado corretamente com mídia ou uma conexão antes do início do teste. Para obter informações sobre como configurar corretamente um dispositivo para teste, consulte Pré-requisitos de teste de confiabilidade device.fundamentals.

A tarefa Verificação de Status do Dispositivo está incluída na fase de instalação de cada trabalho de teste de Confiabilidade de Conceitos Básicos do Dispositivo. Ele executa uma ferramenta para verificar se o dispositivo em teste (DUT) está em condições de trabalho. Se falhar, será criado um log que indica o problema com o dispositivo.

Por exemplo, para dispositivos Bluetooth, você pode receber o seguinte erro:

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

Essa mensagem de erro pode indicar que, antes do teste, você deve se conectar ao dispositivo Bluetooth usando o painel Controle de Áudio.

No exemplo a seguir, o dispositivo de teste relata o código de problema A – CM_PROB_FAILED_START status. Ele deve relatar o código do problema 0 (sem problemas).

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

O Device Path Exerciser falha com "O thread de teste excedeu o limite de tempo limite. Erro de terminação de thread"

Quando o teste registra o thread de teste excedeu o limite de tempo limite. Encerrando o erro de thread durante um teste de exercício de caminho do dispositivo, o teste também registra a última operação executada. Os desenvolvedores de driver devem determinar por que a última operação registrada faria com que o teste travasse. Por exemplo:

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

Falha ao remover teste surpresa com a mensagem de erro "Falha ao receber IRP_MN_REMOVE_DEVICE após receber IRP_MN_SURPRISE_REMOVAL"

O Teste de Dispositivo de Remoção Surpresa do DF – PNP poderá falhar com a seguinte mensagem de erro se o gerenciador PnP não enviar o IRP de remoção para a pilha de dispositivos de teste depois de enviar o IRP de remoção surpresa :

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

O gerenciador PnP não envia a solicitação IRP_MN_REMOVE_DEVICE até que todos os identificadores de arquivo pendentes para o dispositivo sejam fechados. Ou seja, o gerenciador PnP não envia a solicitação IRP_MN_REMOVE_DEVICE até que a contagem de referência do PDO atinja zero. Consulte Manipulando uma solicitação de IRP_MN_SURPRISE_REMOVAL para obter informações sobre como lidar corretamente com IRP_MN_SURPRISE_REMOVAL solicitação.

Para ajudar a depurar essa falha de teste, você deve determinar como a contagem de referência do PDO (objeto de dispositivo físico) é alterada. Identifique o processo que está alterando a contagem de referência e examine a aparência da pilha de chamadas quando a contagem de referência é alterada. As seguintes etapas podem ser usadas para depurar essa falha:

  1. Se você ainda não fez isso, conecte um depurador de kernel ao computador de teste. Consulte Configurando um computador para implantação, teste e depuração de driver.

  2. Defina um ponto de interrupção ba (Break on Access) no local em que a contagem de referência do PDO do dispositivo de teste é armazenada. Consulte Pontos de interrupção do processador (ba Pontos de interrupção) para obter mais informações sobre pontos de interrupção de acesso. No exemplo a seguir, o comando depurador de kernel !devnode obtém informações sobre o devnode para o driver USBvideo. O endereço do PDO para esse 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. Use o comando !devobj no PDO para exibir informações sobre a contagem de referência (RefCount) do 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 o objeto de dispositivo PDO usando o comando depurador de kernel dt (Tipo de Exibição ). ReferenceCount mostra o número de identificadores abertos para o dispositivo associado ao objeto do dispositivo.

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

  5. Se a contagem de referência for maior que 0 antes de iniciar o teste:

    • Defina um ponto de interrupção em que o PDO é criado.

    • Depois que o PDO for criado, defina o ponto de interrupção de acesso (ba) no local em que a contagem de referência do PDO é armazenada.

      Por exemplo, o comando a seguir define um ponto de interrupção ba (Break on Access) no objeto do dispositivo (0x849e9648). O ponto de interrupção é definido no acesso de gravação ao ReferenceCount (+4 deslocamento) com um tamanho de 4 bytes (o tamanho de ReferenceCount).

      0: kd> ba w 4 849e9648+4

    • Se a contagem de referência do PDO for igual a 0 antes de iniciar o teste, é provável que a execução do teste esteja fazendo com que a contagem de referência do PDO seja maior que zero no momento em que o teste executa a remoção surpresa do dispositivo. Isso geralmente indica um vazamento de identificador. Execute o teste Remover Dispositivo de Surpresa PNP de uma janela do Prompt de Comando ou do Visual Studio para reproduzir a falha e capturar as informações necessárias para solucionar o problema.

    Observação

    Se você definir o parâmetro DoConcurrentIO como TRUE, o teste abrirá centenas de identificadores de arquivo para o PDO. Recomendamos que você defina esse parâmetro como FALSE quando reproduzir essa falha.

  6. Quando o ponto de interrupção no acesso (ba) ocorrer, você poderá usar os comandos de depurador de kernel !thread e k (Exibir Backtrace de Pilha) para depurar a falha. Como a contagem de referências pode ser alterada várias vezes durante a execução do teste, como uma opção, você pode usar o parâmetro commandString do comando de depurador ba (Break on Access) para obter as informações necessárias em cada alteração na contagem de referência e ainda continuar a testar.

    Por exemplo, no seguinte comando break on access, o commandString consiste em um comando !thread que identificará o processo que causa a alteração da contagem de referência e os comandos .reload ; k 100 que identificarão a pilha de chamadas, um comando !devobj para imprimir a contagem de referência em cada alteração e o comando g para continuar após o ponto de interrupção.

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

Exemplo:

No exemplo a seguir, a chamada da função CreateFile de um thread em execução no cscript.exe causa um incremento na contagem de referência. Capturar todas as instâncias em que a contagem de referência é alterada durante a execução do teste e analisar essas pilhas de chamadas pode ajudar a identificar o identificador de vazamentos.

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.

Falhas de log de plug-ins do SimpleIO

Os testes de confiabilidade de conceitos básicos do dispositivo usam plug-ins de E/S simples do WDTF fornecidos para testar e/S em dispositivos. Plug-ins SimpleIO são extensões WDTF que testam a funcionalidade de E/S específica do dispositivo genérico. Se existir um plug-in WDTF para o tipo de dispositivo que está sendo testado, o teste usará a interface IWDTFSimpleIOStressAction2 para testar a E/S no dispositivo.

Os erros registrados por plug-ins do WDTF SimpleIO usam a marca WDTF_SIMPLE_IO no arquivo TestTextLog.log (confira Marcas de Nome do Objeto WDTF. A mensagem de erro sempre identifica o dispositivo em teste e o motivo específico da falha.

Exemplo:

Neste exemplo, o plug-in Wireless SimpleIO registrou uma falha em que ocorreram falhas de E/S durante o teste de um dispositivo 802.11n USB Wireless LAN Card. Especificamente, o plug-in SimpleIO executou ping no endereço do gateway usando uma função IcmpSendEcho, que retornou um erro 11010. Esse erro se traduz em Erro devido à 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.

O teste de E/S em um dispositivo específico trava permanentemente e, eventualmente, faz com que o teste falhe devido a um tempo limite

Os testes de Confiabilidade de Conceitos Básicos do Dispositivo são testes baseados em cenário e combinam testes de E/S com cenários de teste de energia PNP & . Normalmente, os testes testarão a E/S por dois minutos antes e depois de um cenário. Por exemplo, o teste DF – Sleep with IO Before and After faz o seguinte:

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

O teste acaba testando E/S em dispositivos várias vezes (uma vez para cada estado de suspensão) quando ele é executado. Consulte Examinar Arquivos de Log para obter informações sobre como ver isso nos arquivos de log.

Uma das falhas comuns ao testar e/S é que o teste de E/S em um dispositivo específico pode travar permanentemente. Isso faz com que o teste eventualmente falhe após um período de tempo limite de teste (que normalmente é horas). Consulte Solução de problemas de falhas de teste do Windows HLK para obter informações sobre como identificar falhas causadas pelo tempo limite.

Observação

O Windows HLK encerrará o processo suspenso após o período de tempo limite. Em vez de aguardar que o teste falhe por causa de um travamento permanente, recomendamos que você investigue o travamento enquanto o processo suspenso ainda está em execução no sistema. Consulte a seção Travamentos de Teste do Teste de Confiabilidade de Conceitos Básicos do Dispositivo de Solução de Problemas usando o tópico HLK do Windows para obter informações sobre como solucionar problemas de travamentos de teste.

Dependendo de quantos dispositivos a E/S está sendo testada, o dispositivo suspenso pode ser identificado da seguinte maneira:

  1. Se o número de dispositivos em que o teste está testando E/S for um, você não verá nenhum progresso na janela de comando por mais de dez minutos. A última entrada de log na janela de comando terá uma marca de WDTF_SIMPLE_IO ou WDTF_SIMPLEIO_STRESS e identificará o dispositivo suspenso. Consulte Examinar Arquivos de Log para obter mais informações sobre como ler os arquivos de log de teste.

  2. Se o número de dispositivos nos quais o teste está testando E/S for maior que um, você verá uma repetição constante de Mensagens PerformIO(<Nome> do Dispositivo) ... mensagens por mais de dez minutos na janela de comando. O teste tenta interromper o teste de E/S em um dispositivo de cada vez após dois minutos de teste de E/S neles. Se a operação de parada for bem-sucedida para um dispositivo específico, você deverá ver uma mensagem "Parar" seguida de uma mensagem "Fechar" para o dispositivo nos logs. Se a mensagem "Parar" for vista, mas a mensagem "Fechar" correspondente não for vista para um dispositivo, isso implicará que o teste de E/S para este dispositivo será travado.

Exemplo:

No caso a seguir, o dispositivo de banda larga móvel é o dispositivo problemático porque há uma mensagem "Parar", mas não há nenhuma mensagem "Fechar" correspondente. Por outro lado, o dispositivo I2C HID tem uma mensagem "Parar" e uma mensagem "Fechar", o que implica que o teste foi capaz de interromper a E/S no dispositivo sem problemas. O teste nunca teve a chance de parar de testar E/S nos dispositivos Microsoft Basic Render Driver e Microsoft ACPI-Compliant System; portanto, as mensagens "ExecutarIO" são vistas continuamente para esses 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
…
…

A próxima etapa é inspecionar os rastreamentos de pilha dos threads no processo de teste para determinar por que o teste de E/S para o dispositivo de banda larga móvel está travado. Você descobrirá que um dos threads no processo de teste é usado para testar especificamente a E/S no dispositivo de banda larga móvel. Confira Usar a depuração de kernel para depurar falhas de teste de confiabilidade de conceitos básicos do dispositivo para obter informações adicionais de solução de problemas.

Os testes não retomam do sono

Os testes de confiabilidade de conceitos básicos do dispositivo dependem de temporizadores de ativação do sistema para ativar o sistema de teste dos estados de suspensão durante o teste de gerenciamento de energia. Os temporizadores de ativação com falha podem impedir que o sistema de teste acorde automaticamente durante as execuções de teste. Se o sistema de teste não estiver acordando automaticamente do sono, talvez seja necessário entrar em contato com o fornecedor do BIOS para que eles liberem uma correção de BIOS para resolver os problemas do temporizador de ativação ou executar testes em um sistema diferente em que os temporizadores de ativação funcionem conforme o esperado.

O sistema também pode ficar permanentemente travado durante a ligar ou desligar devido a bugs de driver. Nesse caso, você deve executar novamente o teste usando o sistema de teste conectado a um depurador de kernel e depurar a trava do sistema do depurador de kernel.

Consulte Configurando Kernel-Mode depuração manualmente para obter informações sobre como configurar um depurador de kernel. Consulte Solução de problemas de falhas de teste do Windows HLK para obter diretrizes gerais sobre como solucionar problemas de travamentos do sistema durante as execuções de teste do Windows HLK.

WirelessPlugin: ConnectToTestProfile() – Falha ao se conectar ao perfil de teste. Cadeia de caracteres de motivo: "A rede específica não está disponível". Mensagem de erro

Os testes de Conceitos Básicos do Dispositivo falharão com essa mensagem de erro se os valores corretos para os parâmetros Wpa2PskAesSsid e Wpa2PskPassword não forem fornecidos ao teste no momento do agendamento de teste. Os testes exigem que você forneça informações de conexão (SSID e senha) de uma rede sem fio de teste se um dos dispositivos em teste for um adaptador WiFi. Consulte a seção parâmetros da página de documentação do teste com falha para obter mais informações sobre esses parâmetros de teste.

WDTFSensorsPlugin: Open() – O sensor GPS não foi para o estado pronto

Os testes de confiabilidade de conceitos básicos do dispositivo exigem que sistemas com um sensor GPS sejam testados em um ambiente em que haja um forte sinal de GPS (para que os testes possam testar a E/S no dispositivo de sensor GPS). Esse erro indica que o sensor GPS no sistema de teste não pode obter uma correção de GPS. Considere executar os testes em um local onde o sistema de teste pode obter um forte sinal de GPS.

Mensagem de log de teste: o número de dispositivos encontrados após a reinicialização (1) não é o mesmo que antes da reinicialização (2); examine os logs para localizar os dispositivos ausentes

Essa mensagem indica que um dos dispositivos não voltou após a reinicialização. Para investigar essa falha, gere e analise os logs detalhados de Setupapi para reinstalar, reiniciar e reinicializar testes executando as seguintes etapas:

  1. Para gerar logs de setupapi detalhados, defina a chave do Registro KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup! LogLevel para 0x2000ffff
  2. Reproduza o problema e examine os logs de Setupapi em %windir%\inf\setupapi*
  3. Para causar problemas de instalação do dispositivo, consulte Solução de problemas usando o arquivo Setupapi.log

Se o log contiver um erro informando que o dispositivo estava ausente ou não foi iniciado, execute !pnptriage do depurador e examine a saída. Para obter mais informações sobre falhas de teste de depuração, consulte Usar depuração de kernel para depurar falhas de teste de confiabilidade de conceitos básicos do dispositivo.

Solução de problemas de teste de confiabilidade de conceitos básicos do dispositivo usando o Windows HLK