Referência de código do despejo ao vivo de kernel
Esta seção contém descrições de códigos comuns de despejo ao vivo do kernel que podem ocorrer. Os despejos dinâmicos não reinicializam o sistema operacional, mas permitem a captura de informações de memória para situações anormais em que o sistema operacional pode continuar.
Observação
Este tópico é para programadores. Se você for um cliente cujo sistema exibiu uma tela azul com um código de verificação de bugs, consulte Solucionar problemas de erros de tela azul.
Despejo ao vivo do kernel em comparação com a verificação de bugs
Com uma verificação de bugs tradicional, o PC é reiniciado e o trabalho do usuário é interrompido. O objetivo do despejo ao vivo do kernel é coletar dados para solucionar problemas em uma situação anormal, mas permitir que o sistema operacional continue funcionando. Isso reduz o tempo de inatividade quando comparado a uma verificação de bugs para falhas e travamentos "não fatais", mas de alto impacto. Os despejos dinâmicos do kernel são usados quando é possível recuperar o sistema operacional para um bom estado conhecido. Por exemplo, uma redefinição de hardware de um subsistema, como vídeo/exibição, USB3 ou Wi-Fi, pode permitir que esses sistemas retornem a um estado bom conhecido, com impacto mínimo para o usuário.
Um despejo ao vivo do kernel cria um instantâneo consistente da memória do kernel e o salva em um arquivo de despejo para análise futura. Para minimizar o impacto no desempenho, são usadas técnicas de cópia de memória para criar o arquivo de despejo em um curto período de tempo. Além disso, a coleta de despejos dinâmicos é limitada, para que o impacto do usuário seja minimizado.
Um despejo ao vivo do kernel é eficaz para uma categoria de problemas em que algo está demorando muito, mas nada está falhando tecnicamente. Um temporizador de watchdog pode ser inicializado quando uma operação é iniciada. Se o watchdog expirar antes que a operação seja concluída no tempo esperado, um despejo ao vivo do sistema poderá ser feito. Em seguida, o despejo pode ser analisado percorrendo a pilha de chamadas e a cadeia de espera relacionada a essa operação para investigar por que ela não está sendo concluída no período de tempo esperado.
Os logs do sistema funcionam bem quando algo falha e o proprietário do código registrou a causa da falha e pode identificar a causa. Os despejos dinâmicos que usam temporizadores de watchdog tentam capturar caminhos de falha que não foram previstos e registrados. Mas, como em toda falha, os logs do sistema podem identificar outros problemas que podem fornecer pistas sobre a causa raiz específica da falha.
Conteúdo do arquivo de despejo ao vivo do kernel
Semelhante aos arquivos de despejo regulares, os arquivos de despejo ao vivo do kernel podem conter mini despejos (com dados secundários) e despejos completos do kernel, que também podem incluir a memória do modo de usuário, semelhante aos despejos ativos. Para obter informações gerais sobre o conteúdo do arquivo de despejo, consulte Variedades de arquivos de despejo no modo kernel. Alguns despejos dinâmicos tentam apenas capturar mini despejos, pois são projetados para capturar dados específicos relacionados ao hardware, enquanto outros podem tentar capturar um despejo ao vivo maior do kernel.
Para desempenho, tamanho do arquivo e confiabilidade das capturas de despejo, algumas informações não são incluídas, como páginas da lista de espera e caches de arquivos.
Os arquivos de despejo ao vivo geralmente contêm páginas de memória, como:
- KdDebuggerBlock
- Lista de módulo carregado
Para cada processador, as seguintes informações são capturadas em despejos de kernel:
- KiProcessorBlock
- PRCBs
- Pilha atual
- Tabela de diretórios da página atual
- KI_USER_SHARED_DATA
- Imagem do kernel NTOS
- HAL Image
Informações adicionais em despejos de kernel podem incluir:
- Thread / estado da memória
- Registro em log na memória
Alguns despejos em tempo real podem conter páginas de processo no modo de usuário.
Dados adicionais específicos de domínio, por exemplo, dados específicos de USB para falhas de USB, podem ser incluídos em alguns despejos em tempo real.
Arquivo parcial de despejo ao vivo do kernel
Um arquivo de despejo ao vivo do kernel parcial pode ser gerado em situações em que o despejo ao vivo não pode capturar de forma confiável todas as páginas de memória pretendidas. As informações que são capturadas em um despejo parcial são filtradas e priorizadas, capturando páginas que contêm dados importantes necessários para gerar um despejo válido antes de outras páginas. Por exemplo, as páginas do kernel são priorizadas em relação às páginas do usuário, quando o despejo ao vivo do kernel inclui páginas do usuário. Em algumas situações, não há recursos suficientes disponíveis para capturar todas as páginas de memória opcionais pretendidas, portanto, pode faltar memória no arquivo de despejo. O arquivo de despejo ainda deve ser reconhecido pelo depurador WinDbg, mas pode mostrar erros ao tentar despejar memória. Se o depurador mostrar um erro ao tentar despejar memória em um endereço, você poderá usar a extensão !pte para verificar se o PTE de um endereço é válido ou não. Isso pode ajudar a determinar se o endereço de memória é realmente inválido ou se a página é válida, mas simplesmente não está disponível no arquivo de despejo.
Analisando arquivos de despejo ao vivo
Quando ocorre um despejo ao vivo, o arquivo de despejo pode ser analisado usando as mesmas técnicas usadas para outros arquivos de despejo de memória. Para entender o conteúdo da memória durante uma falha, é necessário ter conhecimento dos registros de memória do processador e da programação em assembly.
Para saber mais, veja:
Usando o WinDbg para exibir informações de código de parada de despejo ao vivo
Se um código específico de despejo ao vivo não aparecer neste tópico, use a extensão !analyze no depurador do Windows (WinDbg) com a seguinte sintaxe (no modo kernel), substituindo <code> com um código de despejo ao vivo:
!analyze -show <code>
A inserção desse comando faz com que o WinDbg exiba informações sobre o código de despejo ao vivo especificado. Se a base numérica padrão (base) não for 16, prefixe <code> com 0x.
Forneça os parâmetros do código de despejo ao vivo ao comando !analyze para exibir qualquer informação de parâmetro disponível. Por exemplo, para exibir informações sobre a verificação de bugs 0x144 BUGCODE_USB3_DRIVER, com um valor de parâmetro 1 de 0x3003, use !analyze -show 0x144 0x3003 como mostrado aqui.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
Para fazer o download do WinDbg, consulte Ferramentas de depuração para Windows. Para saber mais sobre as ferramentas de desenvolvimento do WinDbg, consulte Introdução à depuração do Windows..
Locais de arquivos de despejo ao vivo
Por padrão, os despejos dinâmicos são armazenados no diretório 'C:\WINDOWS\LiveKernelReports'.
Despejos completos: %systemroot%\LiveKernelReports\*.dmp
Mini despejos: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Uma estrutura de diretório é usada para armazenar despejos dinâmicos para diferentes componentes.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Chaves de registro de despejo ao vivo
Para obter mais informações sobre opções de configuração para relatórios de kernel ao vivo gerados pelo sistema, consulte Configurações WER.
Use o PowerShell para acionar manualmente um despejo ao vivo
Abra o prompt do PowerShell como administrador.
Obtenha o nome amigável StorageSubsystem usando o comando do PowerShell Get-StorageSubSystem.
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Use Get-StorageDiagnosticInfo para gerar um despejo ao vivo para o subsistema acima (juntamente com outros logs de diagnóstico). Para obter mais informações, consulte Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- A saída indicará que as informações solicitadas estão sendo geradas.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- O despejo estará dentro de
[DestinationPath]\localhost.
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- Usar o depurador para executar !analyze no arquivo de despejo indicará que esse é um código de despejo ao vivo do LIVE_SYSTEM_DUMP (161).
Códigos de despejo ao vivo do kernel
A tabela a seguir fornece links para códigos de despejos dinâmicos do kernel.
Esses códigos de parada podem ser usados para despejos dinâmicos ou para verificação de bugs no dispositivo.
| Código | Nome |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |
Confira também
Referência de código de verificação de bugs