Como Ler Arquivos Minidump com WinDbg no Windows 11

Solução rápida: Instale o WinDbg pela Microsoft Store (gratuito), abra o arquivo minidump em C:\Windows\Minidump\*.dmp, defina o caminho de símbolos como srv*C:\symbols*https://msdl.microsoft.com/download/symbols e execute !analyze -v para obter o código de verificação de bug, o driver com falha e a pilha de chamadas.

Seu PC acabou de exibir a tela azul. Após reiniciar, o Windows pergunta se você deseja relatar a falha. Nos bastidores, o Windows gravou um pequeno arquivo de despejo de memória em C:\Windows\Minidump\. Cada arquivo tem cerca de 1 MB e contém a pilha do kernel no momento da falha — o suficiente para identificar o driver ou módulo do kernel causador. O WinDbg lê o arquivo e informa exatamente qual driver causou a BSOD.

O que causa isso

Quando o Windows exibe a tela azul, o kernel despeja uma pequena porção da memória (a pilha da thread que falhou mais a lista de drivers carregados) em C:\Windows\Minidump\. O arquivo é nomeado com um timestamp: 050926-12345-01.dmp. Para tornar o despejo útil, você precisa de símbolos — arquivos de informações de depuração (PDB) que mapeiam endereços de memória para nomes de funções. A Microsoft hospeda símbolos públicos para componentes do Windows em um servidor público; o WinDbg os baixa sob demanda.

Dois pré-requisitos para a geração de minidump: (1) o sistema deve estar configurado para gravar minidumps (Configurações → Sistema → Sobre → Configurações avançadas do sistema → Inicialização e Recuperação → Gravar informações de depuração = Despejo de memória pequeno (256 KB)), e (2) o arquivo de paginação deve estar habilitado em C:. Ambos são padrão no Windows 11.

Método 1: WinDbg da Microsoft Store (recomendado)

O caminho moderno. A versão da Store é a mesma do WinDbg Preview do Windows SDK, com uma interface de faixa de opções mais limpa.

1. Abra a Microsoft Store. Pesquise por WinDbg.
2. Instale. Fixe no Menu Iniciar.
3. Inicie o WinDbg. A faixa de opções Início mostra Iniciar depuração.
4. Clique em Abrir arquivo de despejo. Navegue até C:\Windows\Minidump\ e escolha o .dmp mais recente.
5. Após carregar, defina o caminho de símbolos: clique em Arquivo → Configurações → Configurações de depuração → Caminho de símbolos. Cole esta string exata:

   srv*C:\symbols*https://msdl.microsoft.com/download/symbols

   Isso armazena em cache os símbolos em C:\symbols no primeiro download.

6. Clique em Salvar. Na barra de comandos na parte inferior, digite:

   !analyze -v

   Pressione Enter.

7. O WinDbg baixa os símbolos (5–10 MB) e produz uma análise detalhada. Procure por:
   • BugCheck: o código hexadecimal de quatro dígitos (ex.: 0x0000007E)
   • BUGCHECK_STR: nome textual (ex.: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)
   • MODULE_NAME: driver com falha (geralmente o culpado)
   • STACK_TEXT: cadeia de chamadas de função que levou à falha

O MODULE_NAME é seu ponto de partida — se for um driver de terceiros, esse é o principal suspeito. Atualize ou reverta esse driver.

Método 2: BlueScreenView para triagem rápida

Para quando você quer uma visão geral mais rápida sem a curva de aprendizado do WinDbg.

1. Baixe o BlueScreenView da NirSoft (nirsoft.net/utils/blue_screen_view.html) — gratuito.
2. Extraia o ZIP e execute BlueScreenView.exe (não precisa instalar).
3. A ferramenta varre automaticamente C:\Windows\Minidump\ e lista todas as BSOD encontradas.
4. Clique em uma linha. O painel inferior mostra os drivers carregados no momento da falha. Drivers destacados em vermelho são provavelmente a causa.
5. Clique com o botão direito em uma entrada de driver → Propriedades. Mostra o caminho do arquivo, versão e nome do produto — útil para confirmar qual software de terceiros o instalou.
6. Faça referência cruzada com a saída do !analyze -v do WinDbg para confirmação.

O BlueScreenView é mais rápido, mas menos detalhado que o WinDbg. Use-o para triagem inicial quando tiver vários despejos para examinar.

Método 3: WhoCrashed para análise em linguagem simples

Para usuários que desejam a profundidade do WinDbg sem a interface de linha de comando.

1. Baixe o WhoCrashed da Resplendence Software (gratuito para uso doméstico).
2. Instale. Na primeira execução, ele pede para baixar as Ferramentas de Depuração da Microsoft — concorde.
3. Clique em Analisar. A ferramenta varre C:\Windows\Minidump\ e produz um relatório em linguagem simples.
4. Cada entrada de falha inclui: data, código de verificação de bug, o provável driver e uma classificação de confiança.
5. Clique em uma falha para expandir seu relatório completo — os mesmos dados que o WinDbg mostra com !analyze -v, mas pré-formatados.
6. Exporte o relatório como arquivo de texto via Salvar → Salvar como arquivo de texto. Útil para tickets de suporte.

WhoCrashed é a escolha certa se você está escrevendo um ticket de suporte e o técnico quer a análise sem que você precise aprender WinDbg.

Como verificar se a correção funcionou

• A saída do !analyze -v do WinDbg inclui uma linha Probably caused by: — geralmente aponta para um arquivo de driver específico (nvlddmkm.sys, iaStorA.sys, etc.).
• A saída também lista um FAILURE_BUCKET_ID — útil para pesquisar na Base de Conhecimento da Microsoft ou fóruns da web por correções conhecidas.
• Verifique C:\Windows\Minidump\ após aplicar a correção (atualização de driver, alteração de hardware). Se nenhum novo arquivo .dmp aparecer após uma semana de uso normal, a BSOD está resolvida.

Se nenhum desses funcionar

Se o WinDbg mostrar nt!KeBugCheckEx como a única entrada significativa na pilha e o MODULE_NAME for apenas nt (o kernel do Windows), o despejo não capturou contexto suficiente. Duas maneiras de obter um despejo mais rico: (1) aumente o tamanho do despejo para Despejo de memória do kernel via Configurações → Sistema → Sobre → Configurações avançadas do sistema → Inicialização e Recuperação → Gravar informações de depuração. Isso produz arquivos de ~1–2 GB em C:\Windows\MEMORY.DMP em vez dos minidumps pequenos. (2) Habilite o Driver Verifier em drivers suspeitos (verifier na caixa Executar) para que a próxima falha capture mais detalhes, ao custo de um tempo de execução mais lento. Para BSODs crônicos onde nenhum driver é consistentemente identificado, a causa geralmente é hardware: RAM com defeito (execute mdsched.exe), SSD com falha (verifique dados SMART via CrystalDiskInfo) ou superaquecimento (verifique temperaturas na BIOS ou via HWiNFO).

Resumo: WinDbg + !analyze -v + servidor de símbolos públicos da Microsoft lê minidumps e identifica o driver com falha em cerca de um minuto após os símbolos serem armazenados em cache. BlueScreenView é a alternativa rápida para triagem.