Teste de inicialização do WindowsToGo
Esse teste valida se o armazenamento USB pode ser provisionado com uma imagem do Windows e os seguintes requisitos são atendidos:
Inicializar no Windows a partir do dispositivo.
Opera em SuperSpeed quando conectado a uma porta USB 3.0.
Insira e retome do sono S3.
Insira e retome da hibernação S4.
Observação
Essa é uma implementação específica do sistema de um teste existente. Para obter mais informações sobre esse teste, consulte Teste de inicialização de dispositivo WindowsToGo.
Detalhes do teste
Especificações |
|
Plataformas |
|
Versões com suporte |
|
Tempo de execução esperado (em minutos) | 45 |
Categoria | Cenário |
Tempo limite (em minutos) | 2700 |
Requer reinicialização | false |
Requer configuração especial | true |
Tipo | automático |
Documentação adicional
Os testes nessa área de recursos podem ter documentação adicional, incluindo pré-requisitos, configuração e informações de solução de problemas, que podem ser encontrados nos tópicos a seguir:
Executando o teste
Os requisitos de hardware são os seguintes:
O dispositivo deve ser USB 3.0 e certificado para Windows To Go.
O dispositivo em teste deve ser conectado a uma porta USB 3.0 para executar esse teste.
O computador que executa o teste não deve ter outros dispositivos de armazenamento USB anexados.
O computador que executa o teste não tem uma quantidade igual ou mais de memória do sistema do que o dispositivo certificado WTG (por exemplo, se o sistema tiver 32 Gb de RAM, você não poderá usar uma unidade WTG de 32 Gb).
Os requisitos de software são os seguintes:
- O usuário deve copiar um arquivo WIM (Imagem do Windows) válido para o computador de teste. Ele deve incluir todos os drivers necessários para usar o hardware do sistema.
Solucionando problemas
Para solucionar problemas genéricos de falhas de teste do HLK, consulte Solução de problemas de falhas de teste do Windows HLK.
Para obter informações de solução de problemas, consulte Solução de problemas de device.storage testing.
Se você não puder inicializar do dispositivo Windows To Go, use o seguinte para solucionar esse problema:
Verifique se a imagem do Windows não inclui nenhum drivers USB de terceiros.
Verifique se o sistema que você está usando para executar esse teste tem o firmware mais recente.
Se a inicialização foi interrompida por um erro de parada de INACESSIBLE_BOOT_DEVICE, o UFD provavelmente ficou sem resposta depois de receber uma determinada sequência de comandos. Faça um rastreamento USB para determinar o que fez com que a UFD não respondesse.
Se o sistema não tentou inicializar a unidade do Windows To Go, o UFD provavelmente não enumerou rapidamente o suficiente para o firmware do sistema. Faça um rastreamento USB para determinar o que fez com que o sistema anulasse sua tentativa de inicializar o UFD.
Se você tomou essas etapas de depuração e acredita que seu dispositivo está se comportando corretamente, execute o teste novamente com um dispositivo certificado e compare os resultados.
Se o dispositivo não puder entrar em suspensão S3, sua imagem WIM poderá não ter os drivers gráficos corretos instalados. Use as seguintes etapas para ver o que está bloqueando o sono S3:
Provisione um dispositivo Windows To Go com a mesma imagem que você usa com o teste e, em seguida, inicialize dele.
Abra um prompt de comando e execute o seguinte comando: powercfg a
Observe qual dispositivo está bloqueando a suspensão S3, adicione o driver apropriado ao arquivo WIM e execute o teste novamente.
Se o computador perdeu estado ao retomar a suspensão S3 ou hibernar S4, isso pode significar que o computador perdeu energia para o dispositivo Windows To Go antes que todos os dados em seu cache pudessem ser gravados.
Se o computador retomar para o sistema operacional host em vez do sistema operacional Windows To Go da hibernação, o computador teve um problema ao inicializar o dispositivo Windows To Go e o computador host foi inicializado. Faça um rastreamento USB para determinar o que fez com que o computador reverter de volta ao sistema operacional host.
Se você receber eventos de Remoção Surpresa durante o teste que não foram causados pelo dispositivo Windows To Go sendo desconectado e conectado novamente, o dispositivo Windows To Go pode não estar mantendo corretamente seu link para o sistema operacional host de acordo com a especificação USB 3.0 ou o dispositivo Windows To Go pode não estar salvando corretamente todos os dados em memória não volátil quando o sistema entra em um estado de suspensão. Faça um rastreamento USB para determinar o que causou os eventos de Remoção Surpresa.
Se o sistema for inicializado com êxito no sistema operacional Windows To Go, mas parecer travado por um longo período de tempo, reinicie manualmente o sistema. O seguinte aviso pode ser encontrado no arquivo de log do Te.wtl para a tarefa "Resultados do Teste de Processo":
Aviso: algo impediu que o sistema entrasse em suspensão (S3) ou em Espera Conectada. Quando inicializado da unidade WTG, abra um prompt de comando e execute "powercfg -a" e observe qual componente está listado como bloqueando o S3 ou o Modo de Espera Conectado. Isso geralmente é o resultado de drivers gráficos ausentes. Adicione todos os drivers ausentes para seu computador ao arquivo WIM que você está usando para este teste.
Observação
Se os logs mostrarem o teste como aprovado após a reinicialização manual, é aceitável enviar os resultados para certificação com esse aviso nos logs.
Mais informações
Lista de arquivos
Arquivo | Location |
---|---|
boottest.dll |
<\pw_device_logo\boottest.dll testbinroot> |
unattend.xml |
<\pw_device_logo\unattend.xml testbinroot> |
pwrtest.exe |
<\pwrtest\pwrtest.exe testbinroot> |
Parâmetros
Nome do parâmetro | Descrição do parâmetro |
---|---|
LLU_NetAccessOnly | |
LLU_LclAdminUsr | |
TestMode | |
WimPath | Caminho completo para um arquivo de imagem do Windows (WIM). Deve estar cheio do Windows, não do WinPE |
WimIndex | Imagem dentro do WIM a ser usado. Deve corresponder à arquitetura do computador host (x86/amd64) |
TAEFSource |