Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Esta secção contém descrições de códigos comuns de despejo dinâmico do kernel que podem ocorrer. Os despejos em tempo real não redefinem 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 bug, consulte Solucionar erros de tela azul.
Kernel live dump em comparação com a verificação de erros
Com uma verificação de erro tradicional, o PC é reiniciado e o trabalho do utilizador é interrompido. O objetivo do kernel live dump é reunir dados para solucionar problemas em uma situação anormal, mas permitir que o sistema operacional continue operando. 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 ao vivo do kernel são usados quando é possível recuperar o sistema operativo para um estado estável e conhecido. Por exemplo, uma reposição de hardware de um subsistema, como vídeo/ecrã, USB3 ou Wi-Fi pode permitir que esses sistemas regressem a um bom estado conhecido, com um impacto mínimo para o utilizador.
Um despejo ao vivo do kernel cria um instantâneo consistente da memória do kernel e guarda-o num ficheiro de despejo para análise futura. Para minimizar o impacto no desempenho, técnicas de cópia de memória são usadas para criar o arquivo de despejo em um curto período de tempo. Além disso, a coleta de despejos em tempo real é limitada, para que o impacto no utilizador seja minimizado.
Um live dump do kernel é eficaz para uma categoria de problemas em que algo está demorando muito tempo e, no entanto, nada está falhando tecnicamente. Um temporizador de vigilância 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 pode ser realizado. Em seguida, o despejo pode ser analisado atravessando a pilha de chamadas e a cadeia de espera relacionada para investigar por que a operação não está sendo concluída dentro do 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 vigilância 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 para a causa raiz específica da falha.
Conteúdo do ficheiro de despejo ao vivo do kernel
Semelhante aos dumps regulares, os live dumps podem conter minidumps (com dados secundários) e dumps de kernel completos, que também podem incluir a memória do modo de utilizador, semelhante aos dumps ativos. Para obter informações gerais sobre o conteúdo do arquivo de despejo, consulte Variedades de arquivos de despejo de Kernel-Mode. Alguns live dumps apenas tentam capturar minidumps, pois são projetados para capturar dados específicos relacionados ao hardware, enquanto outros podem tentar capturar um live dump maior do kernel.
Para desempenho, tamanho do arquivo e confiabilidade das capturas de dump, algumas informações não são incluídas, como páginas da lista de espera e caches de arquivos.
Ficheiros de despejo ao vivo geralmente contêm páginas de memória, tais como:
- KdDebuggerBlock
- Lista de módulos carregados
Para cada processador, as seguintes informações são capturadas em dumps do kernel:
- KiProcessorBlock
- PRCBs
- Pilha atual
- Tabela de diretório de página atual
- KI_USER_SHARED_DATA (Dados Partilhados do Utilizador)
- Imagem do NTOS Kernel
- Imagem HAL
Informações adicionais em dumps do kernel podem incluir:
- Estado de thread/memória
- Registo em memória
Alguns live dumps podem conter páginas de processo no modo de usuário.
Dados adicionais específicos do domínio, por exemplo, dados específicos de USB para falhas USB, podem ser incluídos para alguns dumps dinâmicos.
Despejo parcial ao vivo do arquivo do kernel
Um arquivo de despejo ao vivo parcial do kernel pode ser gerado em situações em que o live dump não pode capturar de forma confiável todas as páginas de memória pretendidas. As informações 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 sobre as páginas de usuário, quando o live dump inclui páginas de 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, a memória pode estar faltando 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ê pode 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 em tempo real
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 conhecimento dos registros de memória do processador e programação de montagem.
Para obter mais informações, consulte:
Usando o WinDbg para exibir informações de código de parada de despejo ao vivo
Se um código de despejo dinâmico específico 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> por um código de despejo ao vivo:
!analyze -show <code>
Inserir esse comando faz com que o WinDbg exiba informações sobre o código de despejo ao vivo especificado. Se a sua base numérica padrão (radix) não for 16, prefixo <code> com 0x.
Forneça os parâmetros do código de despejo ao vivo para o comando !analyze para exibir todas as informações de parâmetros disponíveis. Por exemplo, para exibir informações na verificação de bugs Bug Check 0x144 BUGCODE_USB3_DRIVER, com um valor de parâmetro 1 de 0x3003, use !analyze -show 0x144 0x3003 como está 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 baixar o WinDbg, consulte Ferramentas de depuração para Windows. Para saber mais sobre as ferramentas de desenvolvimento do WinDbg, consulte Introdução ao Windows Debugging.
Locais de arquivos de despejo em tempo real
Os live dumps por padrão são armazenados no diretório 'C:\WINDOWS\LiveKernelReports'.
Despejos completos: %systemroot%\LiveKernelReports\*.dmp
Minidumps: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Uma estrutura de diretórios é usada para armazenar os dumps ativos 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 do WER.
Usar o PowerShell para acionar manualmente um despejo dinâmico
Abra um prompt do PowerShell como administrador.
Obtenha o nome amigável do StorageSubsystem usando o comando Get-StorageSubSystem PowerShell.
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Use Get-StorageDiagnosticInfo para gerar um despejo dinâmico para o subsistema acima (junto 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 lixão estará dentro
[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 ficheiro de despejo indicaria que este é um código de despejo em tempo real de LIVE_SYSTEM_DUMP (161).
Códigos de despejo ao vivo do kernel
A tabela a seguir fornece links para códigos de dumps do kernel em tempo real.
Esses códigos de parada podem ser usados para despejos em tempo real ou para verificação de erros no dispositivo.
| Código | Nome |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |
Ver também
Referência de Código da Verificação de Erros