Teste de suporte do Crashdump (LOGO)
Esse teste verifica se o driver de miniporto de armazenamento no Windows dá suporte à criação de um arquivo de despejo de memória após ocorrer um erro de parada do sistema.
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:
- Documentação adicional device.storage
- Documentação adicional do System.Fundamentals
- Documentação adicional do System.Server
Executando o teste
Antes de executar o teste, conclua a configuração de teste descrita nos requisitos de teste para o tipo de controlador de armazenamento que você está testando. Para obter mais informações, consulte Visão geral do Adaptador de Armazenamento ou teste do controlador.
Este teste requer software e hardware adicionais:
Dispositivo a ser testado
Disco rígido com no mínimo 20 GB disponíveis na partição C:.
Antes de executar o teste, você também deve concluir os seguintes pré-requisitos:
Se o sistema de teste tiver uma conexão com a Internet, nenhuma ação precisará ser tomada.
Se o sistema de teste não tiver uma conexão com a Internet, crie uma pasta chamada C:\Symbols e baixe e instale símbolos do sistema operacional Windows. Para fazer isso, execute estas etapas:
Observação
Símbolos são necessários para analisar o arquivo de despejo. A falha ao instalar símbolos é o problema de configuração de teste mais comum que faz com que esse teste falhe. A versão dos símbolos deve corresponder à versão do sistema operacional instalada no computador de teste. Portanto, ele deve ser baixado externo ao kit.
Em um computador que tenha uma conexão com a Internet, baixe os pacotes de Símbolos do Windows. Para obter mais informações, consulte Baixar pacotes de símbolos do Windows.
Copie os arquivos de símbolo para o computador de teste para a pasta C:\Symbols . Como os símbolos podem ser grandes, você só precisa copiar ntkrnlmp.pdb (para x64 ou Arm) ou ntkrpamp.pdb (para x86).
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.
A mensagem de erro de logs de teste "Falha ao carregar os símbolos corretos"
Após a reinicialização, o teste examina o arquivo de despejo quanto à correção. O teste faz isso, assim como um desenvolvedor faria, usando o kd do depurador de kernel (consulte Baixar e instalar ferramentas de depuração para Windows). Para analisar um arquivo de despejo, o depurador precisa de acesso a símbolos (consulte Arquivos de Símbolo). Este é um dicionário para o despejo. Eles permitem que o depurador analise o conteúdo da memória (ou um arquivo crashdump) em módulos individuais (executáveis, bibliotecas, drivers etc),funções dentro desses módulos e estruturas de dados. Como regra geral, se você não puder examinar o arquivo de despejo usando o depurador de kernel, o teste não poderá ser aprovado.
Para que o teste funcione corretamente, ele precisa fornecer símbolos ao depurador. Quando não tiver símbolos adequados, ele registrará avisos durante as falhas de log durante a primeira fase de análise do teste. O mecanismo atual para fazer isso é baixar pacotes de símbolos públicos (consulte Baixar Pacotes de Símbolos do Windows) e instalá-los no computador de teste antes de executar o teste. Quando os símbolos não são instalados ou não correspondem ao sistema operacional em teste, a seguinte mensagem pode aparecer no log de teste:
(x) Falha ao carregar os símbolos corretos.
(i) Consulte a documentação do WDK sobre como instalar símbolos do sistema operacional.
(i) Seus símbolos também podem estar desatualizados, atualize os símbolos usando o Servidor de Símbolos da Microsoft.
Essa mensagem não faz com que o teste falhe porque, em alguns casos, o despejo ainda pode ser analisado com símbolos parcialmente correspondentes. Se o teste continuar e mais casos de teste falharem com mensagens como Erro ao recuperar endereços de ... ou Não é possível obter..., isso significa que o depurador não pode analisar o despejo devido a símbolos ausentes. Uma maneira de contornar um símbolo é complementar o símbolo instalado localmente empacotado com símbolos armazenados em cache de um servidor de símbolos da Internet. Siga estas etapas para armazenar os símbolos em cache localmente:
Verifique se você já criou um crashdump. A maneira mais fácil de fazer isso é executar o teste uma vez e deixá-lo falhar.
Verifique se você tem as ferramentas de depuração instaladas. Novamente, a maneira mais fácil de fazer isso é executar o teste uma vez. Ele instalará as ferramentas em C:\Depuradores.
Abra um prompt de comando com privilégios elevados.
Digite o comando a seguir
c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsIsso carrega o despejo no depurador de kernel usando o repositório de símbolos remoto na Microsoft e o diretório local C:\Symbols como o repositório downstream para armazenar em cache os símbolos.
Verifique se os símbolos podem ser encontrados para arquivos do sistema operacional, como NTOSKRNL e NTDLL. Esses arquivos são necessários para analisar o despejo. Não há problema se os erros aparecerem carregando símbolos para outros módulos, como drivers de terceiros.
Agora você deve ter um prompt 0: kd>. Neste prompt, digite o comando .reload /f. Esse comando força o depurador a carregar e armazenar em cache todos os símbolos para módulos carregados no despejo.
Para sair do depurador, pressione Ctrl-B e pressione Enter.
A mensagem de erro de logs de teste "O tamanho do arquivo de paginação é muito pequeno para fins de despejo completo"
No caso de uma falha, não há certeza de quais partes do sistema operacional ainda estarão funcionais. Os drivers de rede ou do sistema de arquivos podem ter causado a falha; por exemplo, impedir o acesso a estruturas do sistema de arquivos para criar um arquivo de despejo ou rede para armazenar o arquivo remotamente. O sistema operacional lida com isso usando um arquivo que ele já sabe que existe (o arquivo de página) e grava diretamente nas extensões de bloco lógico desse arquivo no disco. O processo de despejo grava o conteúdo da memória física no arquivo de página no disco do sistema (geralmente c:\pagefile.sys). O arquivo de página deve ser grande o suficiente para conter o despejo. O maior despejo é um despejo completo, que requer o tamanho da memória física (por exemplo, 4096) mais um megabyte extra para conter as informações de cabeçalho. O teste requer que o usuário configure o arquivo de página para um tamanho apropriado antes da execução. Se o tamanho do arquivo de página for insuficiente, o teste registrará o seguinte erro durante a fase de inicialização:
(i) Verificando o tamanho do arquivo de paginação.
(x) O tamanho do arquivo de paginação é muito pequeno para fins de despejo completo.
(i) Tamanho do arquivo de paginação: 330989568
(i) Tamanho da memória física: 1073094656
(i) Configure o tamanho mínimo do arquivo de paginação para o tamanho da RAM física + 1 MB.
Vejo o erro de parada do sistema (tela azul), mas o código de verificação de bugs não é E2
Após a validação de algumas configurações básicas, o teste instalará um driver usado para travar o sistema e reinicializar o sistema. Após a reinicialização, o teste altera as configurações de controle de falha (para despejo de memória completa), exclui todos os arquivos de despejo antigos e falha no sistema. No ponto da falha, o sistema exibirá uma tela de verificação de bugs (tela azul) com detalhes da natureza da falha. O tipo de verificação de bugs deve ser MANUALLY_INITIATED_CRASH (e2). Se algo mais aparecer aqui, isso significa que ocorreu uma segunda verificação de bug durante o processo de gravação do arquivo de despejo. Isso deve ser investigado conectando um depurador de kernel ao cliente de teste e depurando o driver do adaptador de armazenamento.
A mensagem de erro de logs de teste "O arquivo de despejo está sendo usado por outro processo. HRESULT: 0x80070020"
Depois que o arquivo de despejo for gravado, o computador de teste deverá ser reinicializado automaticamente. Após a inicialização após uma falha, o sistema operacional detectará a presença de informações de despejo no arquivo de página e iniciará o processo de gravação de um despejo. Esse processo ocorre de forma assíncrona enquanto o computador está inicializando e mesmo depois que o usuário faz logon. Durante esse processo, você pode exibir o progresso verificando o tamanho do arquivo de despejo (C:\windows\memory.dmp) ou exibindo o processo no gerenciador de tarefas (werfault.exe). O teste geralmente será executado ao mesmo tempo que esse processo, tentando acessar o mesmo arquivo de despejo. Se isso ocorrer, as seguintes mensagens aparecerão no log:
(i) Conectando-se ao DumpFile: C:\Windows\MEMORY. DMP
(i) O arquivo de despejo está sendo usado por outro processo. HRESULT: 0x80070020
(i) Normalmente memory.dmp ainda está sendo gravado devido a RAM grande, tente novamente após 5 minutos.
Em seguida, o teste deve tentar acessar novamente o arquivo. Se o código da mensagem de erro for diferente ou se ele for alterado (por exemplo, 0x80070002 : ERROR_FILE_NOT_FOUND), isso significa que o arquivo não pôde ser gravado em disco. O primeiro lugar para marcar informações valiosas de depuração é o log de eventos do sistema. Para exibir o log de eventos, clique em Iniciar, clique em Executar e digite Compmgmt.msc. Na janela gerenciamento do computador, selecione Gerenciamento de Computadores\Ferramentas do Sistema\Visualizador de Eventos\Sistema. Navegue pela lista de eventos de um evento que tenha o BugCheck de origem. A causa mais comum para um arquivo de despejo ausente é espaço livre insuficiente no disco. A chave do Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash contém informações sobre a última falha (antes de uma reinicialização), incluindo o arquivo de despejo parcial se um tiver sido criado. Isso pode ser útil ao tentar depurar outros problemas de despejo ausentes.
Mais informações
Crashdump é o mecanismo no qual o sistema operacional chama o driver do adaptador de armazenamento para gravar o conteúdo da memória em um arquivo de despejo após um erro de parada do sistema. Devido à natureza de um erro de parada do sistema, o sistema operacional não pode fazer nenhuma suposição sobre a estabilidade do sistema. Portanto, pouquíssimos serviços do sistema estão disponíveis para os drivers de armazenamento. O Teste de Suporte do Crashdump verifica se o driver do adaptador de armazenamento ainda pode operar nesses ambientes restritos e executar a E/S para gravar no despejo com êxito.
O sistema operacional Windows permite que três tipos diferentes de arquivos de despejo de memória sejam gerados:
Completo
Kernel
Mini
O teste testará os tipos de arquivo de despejo Kernel e Mini. Para obter mais informações sobre esses tipos de arquivo de despejo, consulte Arquivos de despejo no modo Kernel.
O teste concluirá a seguinte sequência de operações:
Instale as Ferramentas de Depuração para Windows no diretório %SystemDrive%\Depurggers e inicialize o sistema.
Instale o driver de teste para simular a falha.
Defina o tamanho do arquivo de página.
Simule erros de parada do sistema (tela azul) com o código de verificação de bugs 0x000000E2.
Reinicie o sistema e reinicie automaticamente o teste.
Examine a falha anterior analisando o arquivo de despejo de memória por meio do depurador de kernel e verifique se o despejo foi gravado corretamente.
Repita as etapas 4 a 6 para cada tipo de arquivo de despejo.
Sintaxe de comando
| Comando | Descrição |
|---|---|
Crashdumptest.exe -c |
Limpe todas as falhas passadas. |
crashdumptest.exe -dtm -y [SymbolsDirectory] -ypass |
Inicialize o teste. |
crashdumptest.exe -autorun -y [SymbolsDirectory] -dtm" |
Executa o teste. |
Lista de arquivos
| Opção de comando | Descrição |
|---|---|
Crashdumptest.exe |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
BugCheck.sys |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
Parâmetros
| Nome do parâmetro | Descrição do parâmetro |
|---|---|
| DebuggerDirectory | Diretório para o qual instalar depuradores. |
| SymbolsDirectory | Diretório em que os símbolos já estão instalados. |
| LLU_LclAdminUsr | Conta de usuário para executar o teste. |
| LLU_NetAccessOnly | Conta de usuário para acessar o compartilhamento de arquivos de teste. |
| PagefileSize | Tamanho do arquivo de página em MB (dá suporte ao formato mem+N) |