Windows Error Reporting no Windows 11: Como Descobrir Por Que um Programa Travou

setembro 8, 2026 admin Windows 11, Sistema Operacional, Software 0

Windows Error Reporting no Windows 11 com Monitor de Confiabilidade, Visualizador de Eventos, AppCrash, AppHang e Event ID 1000 e 1001.
Windows Error Reporting (WER) ajuda na investigação de programas que travam, fecham sozinhos ou deixam de responder no Windows 11.
72 / 100
Desenvolvido por Rank Math SEO
Pontuação de SEO

Você está usando normalmente um programa no Windows 11. De repente, a janela deixa de reagir. O mouse continua funcionando, outros aplicativos respondem, mas aquele programa parece congelado. Alguns segundos depois, o Windows pode indicar que o aplicativo “Não está respondendo”.

Em outra situação, o comportamento é diferente: o programa simplesmente desaparece da tela. Nenhuma mensagem clara explica o ocorrido. Quando você tenta abri-lo novamente, ele funciona como se nada tivesse acontecido.

Também pode aparecer uma mensagem informando que determinado aplicativo encontrou um problema e precisa ser fechado.

O que aconteceu?

Como o Windows percebe que um aplicativo deixou de responder? Quem registra a falha? Onde ficam as informações que podem ajudar a descobrir o motivo?

É aqui que entram diferentes mecanismos de diagnóstico do Windows, incluindo o Windows Error Reporting, conhecido pela sigla WER.

O WER faz parte da infraestrutura usada pelo Windows para lidar com falhas de aplicativos e do próprio sistema. Dependendo do tipo de problema e da configuração do computador, ele pode registrar informações que ajudam a identificar:

  • qual programa apresentou falha;
  • qual executável estava envolvido;
  • qual módulo apresentou erro;
  • versão do aplicativo;
  • código de exceção;
  • contexto da falha;
  • relatórios associados ao problema.

Mas existe uma distinção importante desde o começo:

um aplicativo travado, um aplicativo que fechou por falha e um aplicativo lento não representam necessariamente o mesmo tipo de problema.

Antes de procurar logs, precisamos entender essa diferença.

O que significa quando um programa “trava” no Windows 11?

No uso cotidiano, chamamos praticamente qualquer problema de aplicativo de “travamento”.

Tecnicamente, porém, existem comportamentos diferentes.

Um aplicativo pode:

  1. parar de responder à interface;
  2. continuar processando algo, mas parecer congelado;
  3. apresentar uma exceção e encerrar;
  4. ser encerrado por outro processo;
  5. ser finalizado pelo próprio usuário;
  6. encontrar um erro em um componente externo;
  7. fechar devido a uma incompatibilidade;
  8. consumir recursos demais e ficar extremamente lento.

Esses cenários podem produzir evidências diferentes.

É por isso que simplesmente dizer:

“O programa travou.”

não é informação suficiente para um diagnóstico técnico.

Precisamos descobrir como ele travou.

“Não está respondendo” não significa necessariamente que o programa fechou

Imagine que um aplicativo possua uma janela aberta e precise processar continuamente mensagens relacionadas à interface.

O Windows espera que essa interface continue respondendo adequadamente.

Se a aplicação passa tempo demais sem processar essas mensagens, a janela pode ser considerada sem resposta.

O usuário percebe isso como:

  • janela congelada;
  • cliques que não funcionam;
  • título indicando “Não está respondendo”;
  • dificuldade para mover ou interagir com a janela.

Isso é frequentemente chamado de hang.

Mas o processo pode continuar existindo.

Abra o Gerenciador de Tarefas e talvez você ainda encontre:

programa.exe

em execução.

Ou seja:

janela sem resposta
≠
processo necessariamente encerrado

Essa diferença será fundamental quando analisarmos os registros.

O programa pode estar trabalhando e ainda parecer travado

Também precisamos evitar outro erro comum.

Uma aplicação ocupada com uma operação pesada pode deixar sua interface temporariamente sem resposta.

Por exemplo:

  • processamento de milhares de registros;
  • conversão de vídeo;
  • carregamento de projeto muito grande;
  • consulta extensa em banco de dados;
  • acesso lento a um arquivo em rede;
  • espera por determinado recurso;
  • plug-in executando uma operação demorada.

Do ponto de vista do usuário:

“Travou.”

Do ponto de vista técnico, talvez o processo ainda esteja trabalhando.

Por isso, não é recomendável concluir imediatamente que existe corrupção no Windows ou defeito no programa.

Quando o programa fecha sozinho, temos outro cenário

Agora imagine:

Você abre o programa
        ↓
trabalha normalmente
        ↓
executa determinada função
        ↓
o aplicativo desaparece

Ao verificar o Gerenciador de Tarefas, o processo também não existe mais.

Aqui podemos estar diante de uma falha de aplicação, frequentemente chamada de application crash.

Esse cenário é diferente de um hang.

Simplificando:

HANG
↓
programa continua existindo,
mas deixa de responder adequadamente

CRASH
↓
programa sofre uma falha
e seu processo termina

Essa distinção ajuda muito na investigação.

O que é Windows Error Reporting?

Windows Error Reporting (WER) é uma infraestrutura do Windows relacionada à detecção, coleta e gerenciamento de informações sobre determinados problemas de software e sistema.

O nome pode sugerir apenas:

“serviço que envia erros para a Microsoft”.

Mas essa explicação é incompleta.

Para diagnóstico técnico, o mais interessante é entender que o Windows pode gerar informações relacionadas às falhas e organizá-las para análise.

Essas informações podem aparecer em diferentes locais e ferramentas do sistema.

Entre eles:

  • Visualizador de Eventos;
  • Monitor de Confiabilidade;
  • diretórios relacionados ao WER;
  • relatórios de problemas;
  • dumps, quando configurados ou gerados em determinados cenários.

WER não é a mesma coisa que Visualizador de Eventos

Essa confusão é muito comum.

O Windows Error Reporting é uma infraestrutura relacionada ao tratamento e relatório de problemas.

O Visualizador de Eventos é uma ferramenta utilizada para consultar eventos registrados pelo Windows e por diversos componentes.

Portanto:

WER
≠
Visualizador de Eventos

Mas informações relacionadas ao mesmo problema podem aparecer em ambos os contextos.

Isso significa que podemos usar várias fontes para reconstruir o que aconteceu.

O Monitor de Confiabilidade também não é o WER

O Windows possui outra ferramenta muito útil chamada Monitor de Confiabilidade.

Ela apresenta uma visão cronológica de eventos importantes, como:

  • falhas de aplicativos;
  • falhas do Windows;
  • instalações;
  • atualizações;
  • outros eventos relevantes.

Para o usuário comum, muitas vezes é mais fácil começar pelo Monitor de Confiabilidade do que pelo Visualizador de Eventos.

Ele responde rapidamente a perguntas como:

“Em que dia esse programa começou a falhar?”

ou:

“A falha começou depois da instalação de alguma atualização?”

Como abrir o Monitor de Confiabilidade

Uma maneira prática é pressionar:

Win + R

e executar:

perfmon /rel

O Windows abrirá o histórico de confiabilidade.

Também é possível localizar a ferramenta pesquisando por termos relacionados à confiabilidade no Windows.

O que significa o gráfico do Monitor de Confiabilidade?

A ferramenta organiza os acontecimentos em uma linha do tempo.

Dependendo dos eventos registrados, você poderá encontrar itens relacionados a:

  • falhas de aplicativos;
  • falhas do Windows;
  • avisos;
  • instalações bem-sucedidas;
  • atualizações.

Isso ajuda a estabelecer uma sequência.

Imagine:

segunda-feira
programa funcionando

terça-feira
instalação de atualização

quarta-feira
primeira falha

quinta-feira
três novas falhas

Essa correlação não prova automaticamente que a atualização causou o problema.

Mas cria uma pista que merece investigação.

Correlação não significa causa

Esse princípio é essencial no diagnóstico.

Se um aplicativo começou a falhar depois de uma atualização do Windows, isso não prova que o Windows Update seja responsável.

No mesmo período também podem ter ocorrido:

  • atualização do próprio aplicativo;
  • atualização de driver;
  • alteração de antivírus;
  • mudança de plug-in;
  • corrupção de configuração;
  • alteração em arquivo utilizado pelo programa.

O histórico ajuda a construir hipóteses.

Ele não substitui a investigação.

Visualizador de Eventos: onde procurar uma falha de aplicativo?

Pressione:

Win + R

e execute:

eventvwr.msc

No Visualizador de Eventos, um dos locais mais importantes para esse tipo de investigação é:

Logs do Windows
        ↓
Aplicativo

Ali podem existir eventos produzidos por diferentes componentes e programas.

Para falhas de aplicativos, frequentemente vale procurar registros relacionados a fontes como:

Application Error

e:

Windows Error Reporting

quando presentes.

Application Error e Windows Error Reporting não são necessariamente o mesmo evento

Uma mesma falha pode deixar mais de uma evidência.

Por exemplo:

programa falha
      ↓
Application Error
      ↓
informações sobre executável/módulo/exceção

e/ou

Windows Error Reporting
      ↓
informações relacionadas ao relatório do problema

Por isso, olhar apenas um evento isolado pode deixar informações importantes de fora.

O que procurar em um evento Application Error?

Dependendo da falha, podemos encontrar campos relacionados a:

  • nome do aplicativo com falha;
  • versão;
  • nome do módulo com falha;
  • versão do módulo;
  • código de exceção;
  • deslocamento da falha;
  • caminho do aplicativo;
  • caminho do módulo.

Os nomes exatos e as informações disponíveis variam.

Mesmo assim, alguns campos são extremamente úteis.

“Faulting application name”: qual programa caiu?

Imagine um evento contendo algo equivalente a:

Faulting application name: exemplo.exe

Essa informação identifica o executável associado à falha.

Parece óbvio, mas isso é importante em aplicações compostas por vários processos.

Um programa visualmente chamado:

Programa Empresa

pode executar internamente:

empresa.exe
helper.exe
updater.exe
service.exe

Descobrir qual executável falhou reduz bastante o campo de investigação.

“Faulting module name”: uma pista ainda mais interessante

Outro campo pode indicar o módulo relacionado à falha.

Exemplo conceitual:

Faulting application name:
programa.exe

Faulting module name:
biblioteca.dll

Isso não significa automaticamente:

“Essa DLL está corrompida.”

O módulo apenas aparece no contexto em que a falha foi registrada.

A causa real pode estar relacionada a:

  • bug do aplicativo;
  • parâmetros inválidos;
  • incompatibilidade;
  • plug-in;
  • driver;
  • componente de terceiros;
  • corrupção;
  • problema de memória;
  • interação entre módulos.

Portanto:

módulo com falha
≠
culpado comprovado

DLL do Windows aparecendo no erro significa Windows corrompido?

Não necessariamente.

Imagine que o evento cite:

ntdll.dll

ou outro componente do Windows.

É tentador concluir:

“A DLL do Windows está quebrada.”

Mas uma aplicação pode apresentar uma falha enquanto executa código que passa por uma biblioteca do sistema.

A presença dessa DLL no evento não demonstra, sozinha, corrupção do Windows.

Esse é um dos erros mais frequentes ao interpretar logs.

Código de exceção: o que ele representa?

Dependendo da falha, o evento pode apresentar um código de exceção.

Algo semelhante a:

0xc0000005

pode aparecer em determinados crashes.

Esse código está associado a uma violação de acesso à memória.

Mas novamente precisamos evitar uma conclusão precipitada.

Ele não responde sozinho:

“Qual peça está com defeito?”

Uma violação de acesso pode acontecer por diferentes motivos relacionados ao software e ao ambiente de execução.

O código ajuda a classificar a falha.

Não entrega automaticamente sua causa raiz.

O perigo de pesquisar apenas o código no Google

O usuário encontra:

0xc0000005

pesquisa na internet e encontra dezenas de respostas:

  • memória RAM;
  • antivírus;
  • Windows corrompido;
  • driver;
  • vírus;
  • atualização;
  • SSD;
  • programa defeituoso.

O problema é que o mesmo código pode aparecer em situações muito diferentes.

Precisamos combiná-lo com:

aplicativo
+
módulo
+
versão
+
momento
+
ação realizada
+
frequência
+
outros eventos

Essa combinação produz um diagnóstico muito melhor.

Um crash isolado é diferente de um padrão repetitivo

Imagine que determinado aplicativo falhou uma única vez em seis meses.

Isso é diferente de:

09:00 → falha
09:05 → falha
09:12 → falha
09:20 → falha

Quando os eventos se repetem, podemos comparar os registros.

Pergunte:

  • o executável é sempre o mesmo?
  • o módulo é sempre o mesmo?
  • o código de exceção se repete?
  • acontece sempre ao executar a mesma função?
  • começou na mesma data?

A repetição transforma eventos isolados em um padrão analisável.

O horário exato é uma das informações mais valiosas

Quando um usuário diz:

“O programa fechou agora.”

anote o horário.

Por exemplo:

14:37

Depois procure eventos próximos desse momento.

Isso evita analisar centenas de registros sem relação com o problema.

Um diagnóstico técnico eficiente trabalha com uma linha do tempo.

Crie uma linha do tempo da falha

Um exemplo:

14:32
programa aberto

14:35
arquivo carregado

14:37
programa fecha

14:37
Application Error registrado

14:37
Windows Error Reporting registrado

Agora temos eventos relacionados temporalmente.

Essa abordagem é muito mais eficiente do que simplesmente procurar qualquer erro vermelho no Visualizador de Eventos.

Nem todo erro vermelho importa

O Visualizador de Eventos pode assustar quem o abre pela primeira vez.

Mesmo computadores aparentemente saudáveis podem registrar:

  • erros;
  • avisos;
  • tentativas que falharam;
  • serviços temporariamente indisponíveis;
  • eventos que se resolvem posteriormente.

Por isso, não devemos tentar “corrigir todos os erros” encontrados.

A pergunta correta é:

Qual evento corresponde ao problema que estou investigando?

Esse princípio muda completamente a qualidade do diagnóstico.

Primeira regra para diagnosticar travamentos

Não comece executando aleatoriamente:

sfc /scannow

ou:

DISM

apenas porque um programa fechou.

Essas ferramentas possuem funções importantes, mas precisam responder a uma hipótese técnica.

Primeiro identifique:

  • o que falhou;
  • quando falhou;
  • como falhou;
  • qual módulo aparece;
  • se existe repetição;
  • quais mudanças ocorreram recentemente.

Depois escolha o teste adequado.

O Windows sabe que o programa falhou?

Em muitos casos, sim: o sistema consegue detectar ou receber informações sobre determinados tipos de falhas e registrar evidências úteis.

Mas o título deste artigo precisa ser entendido corretamente.

O Windows não funciona como um técnico que automaticamente descobre:

“O programa travou porque o plug-in X possui um bug na função Y.”

Ele registra evidências.

Cabe ao diagnóstico correlacioná-las.

Onde ficam os relatórios do Windows Error Reporting e como investigar AppCrash e AppHang

Na primeira parte, vimos que dizer apenas “o programa travou” não descreve suficientemente o problema.

Um aplicativo pode:

  • parar de responder;
  • encerrar inesperadamente;
  • apresentar uma exceção;
  • ficar ocupado durante muito tempo;
  • falhar somente ao executar determinada função.

Também vimos que o Windows pode deixar diferentes evidências sobre esses acontecimentos.

Agora vamos avançar para uma área menos conhecida do Windows 11: os próprios dados relacionados ao Windows Error Reporting (WER).

Onde o Windows Error Reporting guarda informações?

Dependendo da configuração do Windows, do tipo de falha e de como o problema foi processado, podemos encontrar dados relacionados ao WER em diretórios do sistema e do perfil do usuário.

Um caminho importante é:

C:\ProgramData\Microsoft\Windows\WER

Como ProgramData normalmente fica oculto, talvez seja necessário habilitar a visualização de itens ocultos no Explorador de Arquivos ou informar o caminho diretamente na barra de endereços.

Dentro da estrutura do WER podem existir diretórios como:

ReportArchive
ReportQueue

A presença, o conteúdo e a quantidade de informações podem variar de computador para computador.

Não devemos esperar que toda falha produza exatamente os mesmos arquivos.

O que é ReportArchive?

De forma simplificada, ReportArchive pode conter relatórios que o WER preservou depois do processamento de determinados problemas.

O caminho pode aparecer como:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive

Dentro dele, podemos encontrar subpastas com nomes que identificam categorias de problema e aplicativos.

Um nome pode trazer referências relacionadas a algo como:

AppCrash

Isso já oferece uma pista importante:

o problema registrado está relacionado ao encerramento inesperado de uma aplicação.

O que é ReportQueue?

Outro diretório que pode existir é:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue

Como o próprio nome sugere, ele está relacionado a relatórios mantidos na fila do mecanismo de relatório de erros.

A existência de um item nesse diretório não deve ser interpretada isoladamente como:

“Existe um defeito grave no computador.”

Estamos analisando dados utilizados pela infraestrutura de relatórios do Windows.

O valor técnico está em correlacionar essas informações com o problema real que estamos investigando.

Também podem existir dados do WER no perfil do usuário

Além da estrutura em ProgramData, informações relacionadas ao WER podem aparecer no perfil do usuário, por exemplo sob caminhos associados a:

%LOCALAPPDATA%\Microsoft\Windows\WER

O conteúdo disponível varia.

Por isso, em vez de decorar uma única pasta e imaginar que ela sempre conterá a resposta, devemos entender o WER como uma infraestrutura com diferentes formas de registrar e processar problemas.

O que significa AppCrash?

Quando encontramos uma referência como:

AppCrash

estamos lidando com uma categoria relacionada a uma aplicação que sofreu uma falha.

Imagine:

programa.exe
     ↓
ocorre uma falha
     ↓
processo termina
     ↓
Windows registra informações

Isso é diferente de uma aplicação que continua existindo, mas não responde adequadamente.

O que significa AppHang?

O termo:

AppHang

está associado a situações nas quais uma aplicação deixa de responder adequadamente.

Conceitualmente:

AppCrash
↓
aplicativo falhou e terminou

AppHang
↓
aplicativo deixou de responder

Essa diferença muda completamente o diagnóstico.

Por que diferenciar crash de hang?

Porque as perguntas técnicas são diferentes.

Em um crash, podemos perguntar:

  • qual exceção ocorreu?
  • qual módulo aparece no evento?
  • qual processo terminou?
  • existe dump da falha?

Em um hang, podemos perguntar:

  • o processo estava esperando outro recurso?
  • uma thread ficou bloqueada?
  • o programa aguardava disco, rede ou outro processo?
  • houve deadlock?
  • a interface ficou bloqueada enquanto outra operação continuava?

Um mesmo programa pode apresentar os dois problemas em momentos diferentes.

O que é deadlock?

Em termos simplificados, um deadlock pode ocorrer quando partes de um programa ficam esperando recursos umas das outras de uma maneira que impede o progresso.

Imagine:

Thread A
possui recurso 1
espera recurso 2

Thread B
possui recurso 2
espera recurso 1

Nenhuma consegue continuar.

Essa é uma explicação conceitual; aplicações reais podem ter situações muito mais complexas.

Para o usuário, o resultado pode simplesmente parecer:

“O programa congelou.”

Nem todo hang é deadlock

Essa distinção também importa.

Um programa pode deixar de responder porque:

  • está esperando uma operação muito demorada;
  • acessa um servidor indisponível;
  • tenta ler um arquivo problemático;
  • aguarda resposta de outro processo;
  • executa trabalho pesado na thread da interface;
  • um plug-in está demorando;
  • ocorreu algum bloqueio interno.

Portanto:

AppHang
≠
deadlock comprovado

O que podemos encontrar dentro de um relatório?

Dependendo do tipo e da versão do relatório, podem existir informações relacionadas a:

  • nome do aplicativo;
  • versão;
  • caminho;
  • identificadores do problema;
  • módulo;
  • versão do módulo;
  • código relacionado à falha;
  • informações do sistema;
  • assinatura do problema.

Um arquivo frequentemente associado a relatórios WER é:

Report.wer

Quando presente, ele pode fornecer informações textuais úteis para a investigação.

Report.wer pode ser aberto como texto?

Quando encontramos um Report.wer textual, podemos inspecioná-lo com um editor adequado.

O objetivo não é alterar o arquivo.

Queremos identificar campos que ajudem a responder:

Qual programa?
Qual versão?
Qual tipo de problema?
Quando?
Qual módulo?
Qual assinatura?

O conteúdo exato varia conforme o relatório.

Não edite os relatórios para “corrigir” o problema

Encontrar um arquivo WER não significa que devemos modificá-lo.

Ele representa evidência de diagnóstico.

Apagar ou editar:

Report.wer

não corrige a aplicação que falhou.

É semelhante a apagar o registro de uma ocorrência sem resolver aquilo que a causou.

Como correlacionar WER e Visualizador de Eventos

Aqui começa uma investigação realmente útil.

Imagine que o usuário diga:

“O programa fechou às 10:42.”

Primeiro registramos:

Horário aproximado: 10:42
Aplicativo: programa.exe
Comportamento: fechou sozinho

Depois verificamos:

Visualizador de Eventos
↓
Logs do Windows
↓
Aplicativo

Procuramos registros próximos de:

10:42

Se encontrarmos um evento de Application Error, anotamos as informações relevantes.

Depois procuramos eventos relacionados ao WER no mesmo intervalo.

Monte uma ficha da falha

Uma técnica simples é criar uma pequena ficha.

Por exemplo:

Data:
08/09/2026

Hora:
10:42

Aplicativo:
programa.exe

Versão:
x.x.x

Módulo citado:
biblioteca.dll

Código:
0xc0000005

Comportamento:
programa fechou sozinho

Ação executada:
abrir determinado arquivo

Agora temos dados comparáveis.

Repita o teste apenas quando for seguro e necessário

Se o problema puder ser reproduzido sem risco para dados importantes, observe se ele acontece novamente sob as mesmas condições.

Por exemplo:

Teste 1
abrir arquivo A
→ funciona

Teste 2
abrir arquivo B
→ programa fecha

Teste 3
abrir arquivo B
→ programa fecha novamente

Agora surge uma hipótese muito melhor:

o problema pode estar relacionado ao arquivo B ou à função utilizada para interpretá-lo.

Isso é muito mais útil do que concluir imediatamente que “o Windows está corrompido”.

Compare os eventos das falhas repetidas

Suponha que três falhas apresentem:

programa.exe
bibliotecaXYZ.dll
0xc0000005

sempre na mesma operação.

Esse padrão merece atenção.

Agora imagine que cada falha apresente:

falha 1 → moduloA.dll
falha 2 → moduloB.dll
falha 3 → moduloC.dll

A investigação pode seguir outra direção.

A consistência — ou falta dela — também é informação.

Um módulo de terceiros pode ser uma pista valiosa

Imagine um aplicativo que utiliza um plug-in:

programa.exe
     ↓
pluginABC.dll

Se todas as falhas começaram depois da atualização do plug-in e os eventos repetidamente apontam para o mesmo componente, temos uma hipótese interessante.

Ainda não é uma prova definitiva.

Mas agora existe algo concreto para testar:

  • versão do plug-in;
  • compatibilidade;
  • atualização;
  • configuração;
  • comportamento sem aquele componente, quando o próprio software oferecer uma forma segura de testá-lo.

E quando aparece ntdll.dll?

ntdll.dll é um componente fundamental do Windows e pode aparecer em muitos contextos de falha.

Encontrar:

Faulting module: ntdll.dll

não significa automaticamente:

“Substitua ntdll.dll.”

Muito menos devemos baixar DLLs aleatórias da internet.

A falha pode ter sido provocada anteriormente pelo próprio aplicativo ou por outro componente e apenas se manifestar enquanto código do sistema participa da execução.

E kernelbase.dll?

O mesmo cuidado vale para componentes do Windows como:

KERNELBASE.dll

A presença no evento não prova que o arquivo esteja corrompido.

Precisamos investigar:

  • aplicação;
  • exceção;
  • padrão;
  • atualização;
  • módulos carregados;
  • circunstâncias da falha.

Quando SFC e DISM entram na investigação?

Depois que houver motivos para suspeitar de problemas em componentes do Windows.

Por exemplo, se vários aplicativos diferentes apresentarem comportamentos anormais envolvendo componentes do sistema e existirem outras evidências de corrupção, verificações do Windows podem fazer sentido.

Mas:

um aplicativo falhou uma vez

não é, sozinho, evidência suficiente para concluir:

Windows corrompido

E se apenas um programa apresenta o problema?

Isso muda a prioridade das hipóteses.

Se:

Word funciona
Chrome funciona
Explorer funciona
outros programas funcionam

Programa X
↓
falha repetidamente

faz sentido investigar primeiro aspectos específicos do Programa X:

  • atualização;
  • plug-ins;
  • configurações;
  • arquivos utilizados;
  • dependências;
  • compatibilidade.

Não significa que o Windows esteja automaticamente inocentado, mas ajuda a ordenar o diagnóstico.

E se vários programas diferentes começam a falhar?

Agora o cenário muda.

Se aplicativos sem relação aparente começam a apresentar crashes, podemos ampliar a investigação para elementos compartilhados, como:

  • componentes do sistema;
  • drivers;
  • memória;
  • armazenamento;
  • segurança;
  • alterações recentes no Windows;
  • bibliotecas compartilhadas.

O importante é ampliar as hipóteses com base nas evidências, não por tentativa aleatória.

O que é um dump?

Um dump é uma captura de informações do estado de um processo ou do sistema em determinado momento.

Dependendo do tipo, pode conter informações úteis sobre:

  • threads;
  • módulos;
  • pilhas de chamadas;
  • exceções;
  • memória do processo.

Para um diagnóstico mais avançado, um dump pode mostrar muito mais do que uma simples linha no Visualizador de Eventos.

Todo crash gera um arquivo DMP?

Não.

A existência de um dump depende de fatores como:

  • configuração;
  • tipo de falha;
  • mecanismo que capturou o problema;
  • aplicativo;
  • políticas do sistema.

Portanto, não espere encontrar automaticamente:

programa.dmp

para toda aplicação que fecha inesperadamente.

Onde entram ferramentas como WinDbg?

O WinDbg é uma ferramenta de depuração utilizada para análise avançada.

Com símbolos adequados e um dump útil, um técnico ou desenvolvedor pode investigar informações muito mais profundas do que aquelas apresentadas pelo Visualizador de Eventos.

Podemos imaginar três níveis:

Nível 1
Monitor de Confiabilidade
↓
Quando e qual programa falhou?

Nível 2
Visualizador de Eventos + WER
↓
Aplicativo, módulo, exceção e padrão

Nível 3
Dump + depurador
↓
Análise interna da execução

Nem todo problema precisa chegar ao terceiro nível.

Comece pela ferramenta mais simples que responde à pergunta

Esse princípio evita desperdício de tempo.

Se o objetivo é descobrir:

“Qual aplicativo está falhando?”

o Monitor de Confiabilidade pode bastar.

Se queremos:

“Qual módulo e código aparecem?”

o Visualizador de Eventos pode ajudar.

Se precisamos descobrir:

“Em qual cadeia de chamadas a aplicação estava quando falhou?”

talvez seja necessário analisar um dump.

WER não substitui depuração

O Windows Error Reporting fornece evidências importantes, mas não deve ser confundido com um depurador completo.

Ele pode ajudar a identificar e classificar o problema.

A investigação profunda de um bug pode exigir:

  • dump;
  • símbolos;
  • código-fonte;
  • depurador;
  • conhecimento da aplicação.

Para um usuário doméstico ou técnico de suporte, entretanto, os dados do WER já podem reduzir enormemente o número de hipóteses.

Exemplo prático de diagnóstico

Imagine:

Um programa de contabilidade fecha sempre que o usuário abre determinado relatório.

Primeiro registramos:

Aplicativo:
contabilidade.exe

Ação:
abrir relatório mensal

Resultado:
programa fecha

No Monitor de Confiabilidade aparecem falhas repetidas do mesmo aplicativo.

No Visualizador de Eventos, os horários coincidem.

Os eventos apresentam repetidamente o mesmo módulo.

Agora temos:

mesmo programa
+
mesma função
+
mesmo módulo
+
mesmo comportamento

Isso é uma evidência muito mais forte do que:

“O computador está com problema.”

Agora altere apenas uma variável por vez

Essa é outra regra importante.

Se você simultaneamente:

  • reinstalar o programa;
  • atualizar drivers;
  • remover antivírus;
  • alterar configurações;
  • executar reparos;
  • atualizar o Windows;

e o problema desaparecer, você não saberá qual mudança resolveu.

Um diagnóstico melhor trabalha assim:

hipótese
↓
um teste
↓
resultado
↓
próxima hipótese

Isso transforma tentativa e erro em diagnóstico.

O WER pode ajudar mesmo quando não há mensagem na tela

Esse é um dos maiores benefícios dessa investigação.

O usuário pode dizer:

“Não apareceu erro nenhum. O programa só sumiu.”

A ausência de uma caixa de diálogo não significa ausência de evidências.

Podem existir registros no:

  • Monitor de Confiabilidade;
  • Visualizador de Eventos;
  • WER;
  • logs do próprio aplicativo.

Por isso, o primeiro passo após um fechamento inesperado é registrar o horário exato.

O horário conecta todas as fontes

Podemos pensar assim:

10:42
│
├── usuário percebe o crash
├── Application Error
├── Windows Error Reporting
├── log do aplicativo
└── possível relatório/dump

O horário funciona como um ponto de correlação.

Essa técnica é simples, mas extremamente poderosa.

Como descobrir por que um programa trava ou fecha sozinho no Windows 11

Encontrar um evento de erro é relativamente fácil.

A parte difícil é interpretar corretamente o que ele significa.

Um dos maiores erros durante o diagnóstico do Windows 11 acontece quando o técnico encontra a primeira mensagem aparentemente relacionada ao problema e imediatamente a transforma em causa.

Por exemplo:

Faulting module name: KERNELBASE.dll

e conclui:

“KERNELBASE.dll está corrompida.”

Ou encontra:

Exception code: 0xc0000005

e conclui:

“A memória RAM está com defeito.”

Nenhuma dessas conclusões pode ser feita apenas com essas informações.

Logs fornecem evidências.

O diagnóstico surge da correlação dessas evidências.

Event ID 1000: Application Error

Em crashes de aplicativos, um evento frequentemente importante no log Aplicativo é o Event ID 1000, normalmente associado à fonte Application Error.

Ele pode apresentar informações como:

Faulting application name
Faulting application version
Faulting module name
Faulting module version
Exception code
Fault offset
Faulting application path
Faulting module path

Esses campos permitem criar uma espécie de identidade da falha.

Não procure apenas pelo Event ID

O Event ID ajuda, mas não deve ser analisado isoladamente.

Precisamos responder:

  • qual aplicativo?
  • em qual horário?
  • qual módulo?
  • qual código?
  • qual versão?
  • aconteceu novamente?
  • o usuário estava fazendo o quê?

O objetivo não é encontrar:

“um evento 1000”.

É encontrar:

o evento correspondente à falha que o usuário acabou de observar.

Eventos relacionados ao Windows Error Reporting

Próximo ao evento de falha, também podem aparecer registros relacionados à fonte:

Windows Error Reporting

Um Event ID frequentemente encontrado nesse contexto é o 1001.

Dependendo do problema e da versão/configuração do Windows, esse registro pode conter informações adicionais relacionadas ao relatório.

Portanto, uma sequência possível é:

10:42:15
Application Error
Event ID 1000

10:42:17
Windows Error Reporting
Event ID 1001

Essa proximidade temporal é uma pista de que estamos observando informações relacionadas ao mesmo incidente.

Não confunda Event ID 1000 com “erro 1000”

Outro cuidado:

1000 nesse contexto é um identificador de evento.

Não significa necessariamente que o programa retornou um “código de erro 1000”.

Da mesma maneira:

Event ID 1000

e:

Exception code 0xc0000005

representam informações diferentes.

Como filtrar o log Aplicativo

O log Aplicativo pode conter milhares de registros.

Em vez de procurar manualmente linha por linha:

  1. abra eventvwr.msc;
  2. entre em Logs do Windows;
  3. abra Aplicativo;
  4. utilize Filtrar Log Atual.

Você pode restringir a investigação por:

  • período;
  • nível;
  • fontes;
  • IDs de evento.

Mas evite criar um filtro tão restritivo que esconda eventos relacionados.

Comece pelo horário, não pelo erro vermelho

Imagine que o usuário diga:

“Travou exatamente às 15:26.”

Use inicialmente um intervalo próximo:

15:24
até
15:28

Procure o que aconteceu nesse período.

Isso é melhor que procurar todos os erros registrados durante uma semana.

Por que o horário é melhor que procurar “qualquer erro”?

Porque computadores registram muitos eventos que não possuem relação com a reclamação atual.

Você pode encontrar um erro às:

09:15

e o aplicativo ter falhado às:

15:26

Mesmo que o erro das 09:15 pareça assustador, talvez não tenha nenhuma relação.

Crie uma assinatura informal da falha

Depois de encontrar o evento correto, anote:

Aplicativo:
editor.exe

Versão:
12.4.1

Módulo:
pluginXYZ.dll

Código:
0xc0000005

Ação:
exportar PDF

Horário:
15:26

Repita o teste quando isso puder ser feito com segurança.

Se a próxima falha apresentar os mesmos elementos, começamos a construir um padrão.

O que significa 0xc0000005?

Um código bastante conhecido em falhas do Windows é:

0xc0000005

Ele está associado a access violation, ou violação de acesso.

Em termos simplificados, algum código tentou realizar um acesso à memória que não era permitido naquele contexto.

Isso pode envolver tentativas inadequadas de:

  • leitura;
  • gravação;
  • execução.

Mas aqui está o ponto mais importante:

0xc0000005 descreve o tipo de falha, não necessariamente sua causa raiz.

0xc0000005 significa RAM defeituosa?

Não necessariamente.

Um bug no próprio software pode gerar uma violação de acesso.

Outras possibilidades também podem existir.

Portanto:

0xc0000005
      ↓
violação de acesso

não deve virar automaticamente:

0xc0000005
      ↓
RAM defeituosa

Para suspeitar seriamente de memória física, precisamos de outras evidências.

Quando a RAM começa a entrar na investigação?

A hipótese de hardware ganha força quando encontramos um padrão mais amplo.

Por exemplo:

Programa A falha
Programa B falha
Programa C falha
jogos falham
arquivos apresentam comportamento anormal
erros variam aparentemente de forma aleatória

Esse cenário é muito diferente de:

somente Programa A
↓
sempre ao abrir arquivo X
↓
sempre no mesmo módulo

No segundo caso, investigar primeiro o aplicativo e sua operação específica costuma ser mais lógico.

E o armazenamento?

Problemas de armazenamento também podem produzir comportamentos estranhos, especialmente quando dados necessários não podem ser lidos ou gravados corretamente.

Mas, novamente, não devemos culpar SSD ou HD porque um aplicativo fechou uma vez.

Procure outras evidências:

  • erros relacionados ao armazenamento;
  • corrupção recorrente;
  • problemas em múltiplos arquivos;
  • falhas de leitura;
  • alertas SMART relevantes;
  • comportamento anormal fora daquele único aplicativo.

Um módulo recorrente é uma pista forte?

Pode ser uma excelente pista.

Imagine cinco crashes:

Crash 1 → pluginABC.dll
Crash 2 → pluginABC.dll
Crash 3 → pluginABC.dll
Crash 4 → pluginABC.dll
Crash 5 → pluginABC.dll

Agora compare com:

Crash 1 → componenteA.dll
Crash 2 → componenteB.dll
Crash 3 → componenteC.dll
Crash 4 → componenteD.dll

O primeiro conjunto apresenta uma consistência muito maior.

Isso justifica investigar pluginABC.dll e o software responsável por ele.

Descubra quem instalou a DLL

Quando aparece uma DLL desconhecida, observe o caminho.

Exemplo:

C:\Program Files\ProgramaX\Plugins\pluginABC.dll

O próprio caminho já sugere que estamos analisando um plug-in do Programa X.

Compare com:

C:\Windows\System32\KERNELBASE.dll

O segundo é um componente do Windows.

O caminho ajuda a identificar a origem do módulo.

DLL de antivírus ou software de segurança aparecendo repetidamente

Alguns softwares adicionam componentes que interagem com outros processos.

Se um módulo de terceiros aparece consistentemente nos crashes, isso pode justificar investigar:

  • versão;
  • compatibilidade;
  • atualização;
  • histórico da instalação.

Mas evite simplesmente remover ferramentas de segurança como primeiro teste.

Primeiro reúna evidências e utilize procedimentos suportados pelo fornecedor quando uma alteração for realmente necessária.

Driver pode causar crash de aplicativo?

Em determinados cenários, sim.

Aplicativos podem depender de drivers para:

  • vídeo;
  • áudio;
  • impressão;
  • dispositivos especializados;
  • aceleração de hardware.

Imagine um editor gráfico que só falha quando ativa aceleração de GPU.

Agora temos uma pista muito mais específica:

aplicativo funciona
      ↓
ativa determinada função de GPU
      ↓
falha

Isso justifica investigar a cadeia gráfica e o driver correspondente.

Aceleração de hardware é um excelente teste comparativo

Alguns aplicativos oferecem uma configuração própria para ativar ou desativar aceleração de hardware.

Quando o fabricante oferece essa opção, comparar o comportamento pode ajudar:

aceleração ligada
→ falha

aceleração desligada
→ funciona

Isso não prova sozinho que a GPU está defeituosa.

Pode indicar:

  • driver;
  • incompatibilidade;
  • bug do aplicativo;
  • recurso gráfico específico.

Mas reduz o espaço de investigação.

E se a falha começou depois de uma atualização?

Precisamos primeiro descobrir qual atualização.

Pode ter sido:

Windows
aplicativo
driver
plug-in
antivírus
runtime

Por isso, anote a primeira data em que a falha ocorreu.

O Monitor de Confiabilidade é especialmente útil para visualizar essa linha do tempo.

Antes e depois

Imagine:

01/09
Programa funciona

02/09
Driver atualizado

03/09
Primeiro crash

04/09
Novo crash

05/09
Novo crash

Isso torna a atualização do driver uma hipótese.

Mas ainda não uma prova.

A pergunta seguinte é:

Existe uma forma segura e suportada de comparar o comportamento com outra versão?

Diagnóstico é exatamente isso: transformar uma correlação em uma hipótese testável.

Logs do próprio programa podem ser ainda melhores

Não limite a investigação ao Windows.

Muitos aplicativos possuem seus próprios:

  • logs;
  • relatórios;
  • diagnósticos;
  • históricos;
  • arquivos de sessão.

Imagine que o Windows diga apenas:

programa.exe falhou

mas o log do aplicativo mostre que segundos antes houve erro ao carregar:

pluginXYZ

Agora temos outra evidência para correlacionar.

Compare os horários dos dois logs

Exemplo:

15:26:02
log do aplicativo:
falha ao inicializar componente X

15:26:04
Application Error:
programa.exe

15:26:06
Windows Error Reporting

Essa sequência é muito mais informativa que qualquer linha isolada.

Process Monitor pode ajudar?

Em alguns casos, sim.

O Process Monitor, da suíte Sysinternals da Microsoft, registra uma enorme quantidade de atividades relacionadas a processos, sistema de arquivos, Registro e outras operações.

Ele pode ajudar quando suspeitamos, por exemplo, que o programa tenta acessar:

  • arquivo inexistente;
  • configuração;
  • determinada chave do Registro;
  • caminho específico;
  • recurso local.

Mas existe um problema:

o Process Monitor produz uma quantidade enorme de informações.

“NAME NOT FOUND” no Process Monitor não significa automaticamente problema

Essa é uma armadilha clássica.

Programas frequentemente procuram diferentes locais até encontrar o recurso desejado.

Você pode ver:

NAME NOT FOUND
NAME NOT FOUND
NAME NOT FOUND
SUCCESS

Isso pode fazer parte do funcionamento normal do aplicativo.

Portanto, não tente “corrigir” cada resultado que não seja SUCCESS.

Process Monitor é melhor quando existe uma pergunta

Uma pergunta ruim:

“Vou abrir o Process Monitor e procurar alguma coisa errada.”

Uma pergunta melhor:

“O programa falha quando tenta carregar este arquivo específico; quero descobrir quais caminhos ele consulta imediatamente antes da falha.”

Agora temos um objetivo.

E o ProcDump?

Outra ferramenta conhecida da suíte Sysinternals é o ProcDump.

Ela pode ser utilizada em cenários de diagnóstico para capturar dumps de processos sob determinadas condições.

Isso pode ser útil quando:

  • o programa fecha rápido demais;
  • precisamos capturar informações da falha;
  • queremos entregar um dump para o desenvolvedor;
  • o suporte do fabricante solicitou uma captura.

ProcDump entra em uma etapa mais avançada do diagnóstico.

Não comece pelo ProcDump se o Event Viewer já responde à pergunta

Se você só precisa descobrir:

“Qual programa está falhando?”

não há necessidade de começar com captura avançada.

A ordem pode ser:

1. reproduzir/observar
2. anotar horário
3. Monitor de Confiabilidade
4. Visualizador de Eventos
5. WER
6. logs do aplicativo
7. ferramentas avançadas se necessário

Essa progressão mantém o diagnóstico eficiente.

Dump não é relatório de texto comum

Um dump pode conter informações do estado do processo e exige ferramentas apropriadas para análise.

É importante também lembrar que dumps podem conter partes da memória de um processo e, portanto, potencialmente informações que estavam sendo processadas naquele momento.

Ao compartilhar dumps com terceiros, considere a privacidade e envie-os apenas a destinatários confiáveis quando isso for necessário para suporte.

Process Monitor e ProcDump resolvem problemas diferentes

Simplificando:

Process Monitor
↓
O que o processo está acessando/fazendo no sistema?

ProcDump
↓
Como capturar o estado do processo em determinada condição?

WinDbg
↓
Como analisar profundamente um dump?

Não são ferramentas intercambiáveis.

E o Gerenciador de Tarefas?

Não subestime a ferramenta mais simples.

Quando um programa está “travado”, verifique se o processo ainda existe.

Observe:

  • CPU;
  • memória;
  • disco;
  • atividade do processo;
  • estado apresentado pela interface.

Um processo utilizando CPU intensamente pode estar realizando trabalho.

Um processo aparentemente parado pode estar esperando alguma coisa.

Esses dados não resolvem o diagnóstico sozinhos, mas ajudam a descrever o cenário.

Crash e hang exigem estratégias diferentes

Se o programa fecha

Procure:

Monitor de Confiabilidade
Application Error
Windows Error Reporting
logs do aplicativo
eventual dump

Se continua aberto sem responder

Investigue:

estado do processo
atividade
dependências
recursos aguardados
logs
eventuais dumps de hang

Não use exatamente o mesmo roteiro para os dois casos.

Fluxograma prático de diagnóstico

Podemos resumir a investigação assim:

PROGRAMA APRESENTOU PROBLEMA
            ↓
Ele fechou?
      ↙            ↘
    SIM             NÃO
     ↓               ↓
   CRASH         Continua aberto?
                     ↓
                    SIM
                     ↓
                   HANG

Para crash:

Anotar horário
      ↓
Monitor de Confiabilidade
      ↓
Event Viewer
      ↓
Application Error / WER
      ↓
Comparar módulo e exceção
      ↓
Ver logs do aplicativo
      ↓
Reproduzir com segurança
      ↓
Identificar padrão

Para hang:

Anotar horário
      ↓
Verificar processo
      ↓
Observar atividade
      ↓
Identificar operação que causou o hang
      ↓
Logs
      ↓
Reproduzir com segurança
      ↓
Ferramentas avançadas se necessário

Como separar problema do aplicativo de problema do Windows?

Não existe uma regra perfeita, mas podemos trabalhar com padrões.

Cenário A

somente um aplicativo falha
+
sempre na mesma função
+
sempre com o mesmo módulo próprio

Prioridade:

investigar o aplicativo.

Cenário B

vários aplicativos diferentes falham
+
comportamentos aparentemente aleatórios
+
outros problemas no sistema

Prioridade:

ampliar a investigação para elementos compartilhados.

Cenário C

programa falha somente ao usar GPU

Prioridade:

investigar aplicativo + cadeia gráfica + driver.

Cenário D

programa falha somente com um arquivo

Prioridade:

investigar o arquivo e a função que o interpreta.

Não reinstale o Windows antes de entender o problema

Reinstalar o Windows pode fazer uma falha desaparecer em alguns cenários, mas também destrói evidências e não explica a causa.

Pior:

se o problema estiver em:

  • arquivo;
  • aplicativo;
  • plug-in;
  • conta;
  • configuração sincronizada;
  • driver reinstalado posteriormente;

a falha pode voltar.

Uma reinstalação deve ser uma decisão técnica, não a primeira resposta para qualquer crash.

Reinstalar o aplicativo também não deve ser automático

A reinstalação pode corrigir arquivos ausentes ou uma instalação problemática.

Mas pode não alterar:

  • perfil do usuário;
  • configurações preservadas;
  • plug-ins;
  • arquivos de projeto;
  • dados externos.

Por isso, quando uma reinstalação não resolve, isso também fornece informação.

O valor de reproduzir o problema

Um problema reproduzível é muito mais fácil de diagnosticar.

Compare:

“Às vezes fecha.”

com:

“Sempre fecha quando clico em Exportar e escolho PDF.”

O segundo relato define um teste.

Podemos repetir:

abrir programa
↓
abrir projeto
↓
Exportar
↓
PDF
↓
crash

Agora conseguimos comparar cada tentativa.

Escreva o procedimento de reprodução

Uma ficha técnica pode ficar assim:

Aplicativo:
Programa X 5.2

Problema:
fecha sozinho

Passos:
1. abrir Programa X
2. abrir projeto Y
3. clicar em Exportar
4. escolher PDF

Resultado esperado:
PDF criado

Resultado obtido:
programa fecha

Horário:
16:08

Event ID:
1000

Módulo:
pluginPDF.dll

Isso já é material muito mais útil para o suporte do desenvolvedor.

O objetivo não é “zerar o Event Viewer”

Essa ideia merece ser repetida.

O objetivo de um técnico não deve ser transformar o Visualizador de Eventos em uma tela sem avisos ou erros.

O objetivo é:

resolver o problema que o usuário relatou e usar os eventos relevantes como evidência.

Tentar eliminar cada registro do Windows pode criar mais problemas do que soluções.

O melhor diagnóstico responde quatro perguntas

Ao final da investigação, tente responder:

1. O que aconteceu?

Crash ou hang?

2. Quando aconteceu?

Data e horário.

3. Em qual contexto?

Qual ação estava sendo executada?

4. O padrão se repete?

Mesmo aplicativo, módulo, arquivo ou função?

Essas quatro respostas eliminam grande parte do “achismo”.

Depois de entender o Windows Error Reporting, o Monitor de Confiabilidade, o Visualizador de Eventos e as diferenças entre crash e hang, podemos transformar todo esse conhecimento em um procedimento prático.

A ideia central deste artigo é simples:

não tente corrigir o problema antes de descobrir exatamente o que está acontecendo.

Quando um programa fecha sozinho ou mostra “Não está respondendo”, o Windows 11 pode deixar pistas suficientes para reduzir bastante o número de hipóteses.

O segredo está em procurar as evidências certas e correlacioná-las.

Checklist: programa fecha sozinho no Windows 11

Quando um aplicativo simplesmente desaparece da tela, siga esta sequência.

1. Anote o horário

Registre a hora aproximada em que o programa fechou.

Exemplo:

Aplicativo: Programa X
Horário: 14:32
Comportamento: fechou sozinho

Essa informação será usada para correlacionar diferentes registros.

2. Descubra exatamente o que o usuário estava fazendo

Não registre apenas:

Programa travou.

Prefira:

Programa fechou ao clicar em
Arquivo > Exportar > PDF.

Quanto mais reproduzível for o comportamento, melhor.

3. Consulte o Monitor de Confiabilidade

Execute:

perfmon /rel

Procure a falha do aplicativo no horário correspondente.

Observe se existem ocorrências anteriores do mesmo programa.

4. Consulte o Visualizador de Eventos

Execute:

eventvwr.msc

Acesse:

Logs do Windows
→ Aplicativo

Procure eventos no mesmo horário.

5. Verifique Application Error

Quando existir um evento correspondente, observe informações como:

Faulting application name
Faulting module name
Exception code
Fault offset
Application path
Module path

6. Procure registros relacionados ao WER

Verifique se existem eventos próximos relacionados ao:

Windows Error Reporting

Eles podem complementar a investigação.

7. Compare ocorrências

Não analise apenas um crash quando o problema acontece repetidamente.

Compare:

Crash 1
Crash 2
Crash 3
Crash 4

Pergunte:

  • mesmo executável?
  • mesmo módulo?
  • mesma exceção?
  • mesma ação?
  • mesmo arquivo?

8. Consulte os logs do próprio programa

Se o software mantém registros próprios, compare os horários.

9. Verifique mudanças recentes

Procure alterações próximas ao início do problema:

  • atualização do programa;
  • atualização de plug-in;
  • driver;
  • Windows Update;
  • software de segurança;
  • mudança de configuração.

10. Avance para ferramentas especializadas somente quando necessário

Se os registros básicos não forem suficientes, ferramentas como ProcDump, Process Monitor e WinDbg podem entrar na investigação.

Checklist: programa mostra “Não está respondendo”

O roteiro muda um pouco quando o aplicativo continua aberto.

Primeiro confirme:

processo continua existindo?

Depois observe:

  • CPU;
  • memória;
  • disco;
  • operação em execução;
  • duração do comportamento;
  • recurso que estava sendo acessado.

Pergunte também:

O programa realmente parou ou está executando uma operação demorada?

Essa diferença é essencial.

Espere ou finalize o programa?

Não existe uma resposta universal.

Se o aplicativo estiver processando:

  • arquivo grande;
  • projeto complexo;
  • banco de dados;
  • conversão;
  • operação pesada;

encerrá-lo imediatamente pode interromper trabalho válido e provocar perda de dados ainda não salvos.

Por outro lado, um processo realmente bloqueado pode não voltar a responder.

Por isso, observe o contexto antes de clicar em:

Finalizar tarefa

Crash versus hang: resumo rápido

SituaçãoComportamento típico
Crashaplicativo encerra inesperadamente
Hangprocesso permanece, mas a interface deixa de responder
Lentidãoprograma responde, porém lentamente
Operação pesadapode parecer congelado enquanto trabalha
Encerramento normalprograma termina de maneira esperada

Essa classificação deve acontecer antes da tentativa de reparo.

Qual ferramenta usar?

Cada ferramenta responde melhor a uma pergunta diferente.

FerramentaPrincipal utilidade
Monitor de Confiabilidadevisualizar histórico e frequência das falhas
Visualizador de Eventosconsultar eventos detalhados
Windows Error Reportinginformações e relatórios relacionados às falhas
Gerenciador de Tarefasobservar o estado atual do processo
Process Monitorinvestigar atividades do processo no sistema
ProcDumpcapturar dumps em condições específicas
WinDbganalisar dumps de maneira avançada

Não existe motivo para abrir todas elas em todo diagnóstico.

Comece pelo Monitor de Confiabilidade

Para usuários menos técnicos, perfmon /rel costuma ser um excelente ponto inicial.

Ele responde rapidamente:

  • quando começou;
  • qual programa falhou;
  • quantas vezes aconteceu;
  • quais outros eventos ocorreram no período.

Depois, quando necessário, aprofundamos a análise.

Depois vá ao Event Viewer

O Visualizador de Eventos oferece uma quantidade muito maior de informações.

Mas isso também significa mais ruído.

A melhor estratégia é chegar ao Event Viewer já sabendo:

programa
+
horário
+
comportamento

Assim, você procura um incidente específico.

WER complementa a investigação

O Windows Error Reporting pode fornecer dados adicionais relacionados à falha.

Dependendo do cenário, podemos encontrar informações sob:

C:\ProgramData\Microsoft\Windows\WER

incluindo estruturas relacionadas a:

ReportArchive
ReportQueue

Também podem existir informações associadas ao perfil do usuário.

A disponibilidade varia conforme o problema e a configuração do sistema.

Quando o Process Monitor faz sentido?

Use-o quando houver uma pergunta específica relacionada às operações realizadas pelo processo.

Por exemplo:

“Quero descobrir quais arquivos o programa tenta acessar imediatamente antes de falhar.”

Isso é muito diferente de abrir o Process Monitor e tentar interpretar milhares de linhas aleatórias.

Quando ProcDump faz sentido?

O ProcDump pode ser útil quando precisamos capturar o estado de um processo para investigação mais aprofundada.

Por exemplo:

  • crash difícil de capturar;
  • problema reproduzível;
  • necessidade de dump para suporte;
  • investigação avançada.

A análise posterior pode exigir ferramentas de depuração e conhecimento técnico adicional.

Quando WinDbg faz sentido?

O WinDbg entra quando os registros básicos já não respondem à pergunta.

Com um dump adequado, um profissional pode investigar elementos como:

  • exceções;
  • módulos;
  • threads;
  • pilhas de chamadas.

Para a maioria dos usuários domésticos, essa etapa não será necessária.

Tabela rápida: informações importantes de um crash

Ao documentar uma falha, tente registrar:

InformaçãoPor que importa
Data e horapermite correlacionar logs
Aplicativoidentifica o processo
Versãoajuda a encontrar problemas específicos da versão
Módulofornece uma pista sobre onde a falha apareceu
Código de exceçãoclassifica aspectos da falha
Caminhoajuda a identificar a origem do executável/módulo
Ação realizadaajuda a reproduzir
Arquivo utilizadopode revelar problema específico de conteúdo
Frequênciadiferencia incidente isolado de padrão
Mudanças recentesajuda a criar hipóteses

Essa ficha pode economizar muito tempo.

Os erros mais comuns ao diagnosticar programas travando

Erro 1 — Culpar a DLL mostrada no evento

Encontrar:

ntdll.dll

não significa automaticamente que ela esteja corrompida.

O mesmo vale para outros componentes do sistema.

Erro 2 — Baixar DLL de qualquer site

Nunca trate um evento citando uma DLL como autorização para substituir arquivos do Windows por cópias obtidas em sites aleatórios.

Além de poder não resolver nada, isso pode introduzir:

  • versão incorreta;
  • incompatibilidade;
  • arquivo modificado;
  • risco de segurança.

Erro 3 — Culpar a RAM por causa de 0xc0000005

O código:

0xc0000005

indica uma violação de acesso.

Ele não identifica sozinho o componente responsável.

Erro 4 — Executar SFC e DISM para qualquer crash

Essas ferramentas possuem aplicações legítimas, mas não devem substituir o diagnóstico.

Primeiro procure evidências de problema nos componentes do Windows.

Erro 5 — Atualizar tudo ao mesmo tempo

Se você altera cinco componentes simultaneamente e o problema desaparece, perde a capacidade de identificar qual mudança teve efeito.

Prefira:

uma hipótese
↓
uma alteração
↓
um teste

Erro 6 — Tentar eliminar todos os erros do Event Viewer

Nem todo erro registrado representa a causa da reclamação atual.

Trabalhe com:

horário
+
aplicativo
+
comportamento
+
evento correspondente

Erro 7 — Reinstalar o Windows cedo demais

Uma formatação pode apagar as evidências sem revelar a causa.

Se o problema estiver no aplicativo, plug-in, arquivo ou configuração, ele ainda pode retornar depois.

Quando devemos suspeitar do próprio aplicativo?

A hipótese ganha força quando:

  • apenas aquele programa falha;
  • a falha é reproduzível;
  • acontece sempre na mesma função;
  • o mesmo módulo do aplicativo aparece repetidamente;
  • começou após atualização específica do software;
  • outros programas funcionam normalmente.

Isso não constitui prova absoluta, mas orienta a prioridade.

Quando investigar um plug-in?

Imagine:

programa funciona sem problema
↓
recurso do plug-in é utilizado
↓
programa fecha

e os eventos repetidamente mencionam um módulo pertencente ao plug-in.

Agora existe uma hipótese concreta.

Consulte:

  • versão;
  • compatibilidade;
  • atualização;
  • documentação do fabricante.

Quando investigar drivers?

Drivers entram com maior força quando a falha aparece associada ao uso de determinado hardware ou recurso.

Exemplos:

aplicativo falha ao usar GPU

programa falha ao inicializar dispositivo específico

problema começou depois de atualização de driver

Ainda assim, mantenha a investigação baseada em evidências.

Quando considerar corrupção do Windows?

A suspeita se torna mais relevante quando os problemas deixam de ser específicos de um único aplicativo.

Por exemplo:

  • vários componentes do sistema apresentam falhas;
  • diferentes aplicativos sofrem problemas;
  • existem outras evidências de corrupção;
  • funções do Windows também apresentam comportamento anormal.

Nesse contexto, ferramentas de verificação e reparo do Windows podem fazer mais sentido.

Quando considerar hardware?

Hardware deve entrar seriamente na investigação quando o comportamento ultrapassa um único programa e surgem evidências independentes.

Exemplos:

  • crashes aparentemente aleatórios em diferentes programas;
  • erros de memória detectados por testes apropriados;
  • problemas de armazenamento;
  • falhas gráficas associadas a diferentes aplicações;
  • instabilidade geral.

Evite trocar componentes apenas por causa de um único Event ID.

Quando procurar o desenvolvedor do programa?

Considere acionar o suporte do fabricante quando:

  • o problema é reproduzível;
  • ocorre somente naquele software;
  • a aplicação está atualizada;
  • existe um padrão claro;
  • os logs apontam repetidamente para componentes do produto;
  • você possui dados suficientes para descrever o problema.

Em vez de enviar:

“O programa não funciona.”

envie algo semelhante a:

Versão: 5.2.1
Windows 11
Falha reproduzível ao exportar PDF
Horário: 14:32
Event ID: 1000
Módulo registrado: pluginPDF.dll
Código de exceção: 0xc0000005

Esse relato possui muito mais valor técnico.

FAQ — Windows Error Reporting e programas travando no Windows 11

O que é Windows Error Reporting?

O Windows Error Reporting, ou WER, é uma infraestrutura do Windows utilizada no tratamento e relatório de determinados problemas de software e sistema. Dependendo do cenário, informações relacionadas às falhas podem ajudar no diagnóstico.

O que significa WER no Windows 11?

WER é a sigla de:

Windows Error Reporting

Ele faz parte dos mecanismos utilizados pelo Windows para lidar com informações relacionadas a erros e falhas.

Onde ficam os relatórios do WER?

Um dos locais que podem conter dados relacionados ao WER é:

C:\ProgramData\Microsoft\Windows\WER

A estrutura e os arquivos disponíveis variam conforme a configuração e o tipo de problema.

O que é ReportArchive?

É uma área da estrutura do WER na qual podem existir relatórios preservados relacionados a problemas que foram processados.

Nem todo computador apresentará os mesmos itens.

O que é ReportQueue?

ReportQueue está relacionado à fila de relatórios do WER. Sua existência não significa, por si só, que o computador possua um problema grave.

O que é AppCrash?

AppCrash está relacionado a situações em que uma aplicação sofre uma falha e encerra inesperadamente.

O que é AppHang?

AppHang está relacionado a situações em que uma aplicação deixa de responder adequadamente.

O processo pode continuar existindo mesmo quando a interface parece congelada.

Qual a diferença entre crash e hang?

Em um crash, normalmente o processo termina inesperadamente.

Em um hang, o processo permanece ativo, mas deixa de responder adequadamente.

O que é Event ID 1000?

No contexto do log Aplicativo, o Event ID 1000 associado a Application Error aparece frequentemente em registros de falhas de aplicações.

Ele pode trazer dados sobre executável, módulo e exceção.

O que é Event ID 1001?

Eventos com ID 1001 podem aparecer em diferentes contextos; quando a fonte é Windows Error Reporting, podem trazer informações relacionadas ao relatório de um problema. O ID sozinho não deve ser interpretado sem verificar a fonte e o conteúdo do evento.

O que significa “Faulting module name”?

É o módulo registrado no contexto da falha.

Isso fornece uma pista, mas não prova automaticamente que o módulo esteja corrompido ou seja a causa raiz.

O que significa 0xc0000005?

Esse código está associado a uma violação de acesso à memória.

Ele classifica a exceção, mas não determina sozinho se a causa é software, driver ou hardware.

ntdll.dll no erro significa Windows corrompido?

Não necessariamente.

ntdll.dll participa de inúmeras operações do Windows e pode aparecer no contexto de falhas causadas por diferentes fatores.

KERNELBASE.dll significa que preciso reinstalar o Windows?

Não.

A presença de KERNELBASE.dll em um evento não prova que o Windows esteja corrompido.

Analise o restante das evidências.

Como abrir o Monitor de Confiabilidade?

Pressione:

Win + R

e execute:

perfmon /rel

Como abrir o Visualizador de Eventos?

Pressione:

Win + R

e execute:

eventvwr.msc

Depois consulte:

Logs do Windows
→ Aplicativo

Todo crash gera um arquivo DMP?

Não.

A criação de dumps depende do tipo de falha, das configurações e dos mecanismos envolvidos na captura.

O que é ProcDump?

ProcDump é uma ferramenta da suíte Sysinternals utilizada em diagnósticos de processos, incluindo cenários nos quais é necessário capturar dumps sob determinadas condições.

Para que serve o Process Monitor?

O Process Monitor permite observar uma grande quantidade de operações executadas por processos, incluindo acessos ao sistema de arquivos e ao Registro.

Ele funciona melhor quando o técnico possui uma pergunta específica para investigar.

Para que serve o WinDbg?

WinDbg é uma ferramenta de depuração que pode ser utilizada para análises avançadas de dumps e falhas.

Devo formatar o Windows quando um programa fecha sozinho?

Não como primeira medida.

Primeiro determine se o problema está restrito ao aplicativo, se é reproduzível e quais evidências aparecem nos registros.

Conclusão

Quando um programa trava no Windows 11, o sistema pode saber muito mais sobre o acontecimento do que aquilo que aparece na tela.

Uma aplicação pode simplesmente desaparecer, mostrar “Não está respondendo” ou apresentar uma mensagem genérica. Nos bastidores, porém, podemos encontrar informações no Monitor de Confiabilidade, Visualizador de Eventos, Windows Error Reporting e nos próprios logs do aplicativo.

O mais importante não é encontrar o maior número possível de erros.

É encontrar o erro correspondente ao problema real.

Comece anotando o horário.

Descubra exatamente o que o usuário estava fazendo.

Determine se houve crash ou hang.

Compare ocorrências.

Observe aplicativo, módulo, exceção e caminho.

Depois construa hipóteses e teste uma variável por vez.

Esse método evita conclusões precipitadas como:

“É a RAM.”

“É o SSD.”

“É o Windows.”

“Essa DLL está corrompida.”

Um bom diagnóstico não começa com a solução.

Ele começa com evidências.

E ferramentas como o Windows Error Reporting ajudam justamente a transformar o simples relato “meu programa travou” em informações técnicas que podem revelar onde vale a pena investigar.

Precisa de ajuda para descobrir por que um programa está travando?

Se um aplicativo fecha sozinho, deixa de responder ou apresenta falhas frequentes no Windows 11, a VMIA – Manutenção e Configuração pode ajudar no diagnóstico.

A investigação pode incluir análise do Windows, programas, drivers, configurações, registros de eventos e outros elementos relacionados ao problema, de acordo com cada caso.

A VMIA atende mediante agendamento, com suporte técnico remoto e atendimento presencial na região de São Paulo.

VMIA – Manutenção e Configuração
Vila Mariana – São Paulo – SP
Telefone e WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br

Antes de formatar o computador ou trocar componentes sem saber a causa, vale descobrir o que realmente está falhando.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*