Você está usando um programa normalmente e, de repente, ele fecha sozinho.
Em alguns casos aparece uma mensagem dizendo que o aplicativo parou de responder. Em outros, a janela simplesmente desaparece.
Depois disso, ao abrir o Gerenciador de Tarefas, você pode encontrar um processo chamado:
WerFault.exe
Para muita gente, esse nome parece suspeito.
Alguns usuários pensam que se trata de vírus.
Outros acreditam que o próprio WerFault.exe provocou o travamento.
Mas, na maioria das vezes, ocorre justamente o contrário:
WerFault.exe aparece porque outro programa apresentou uma falha.
Essa diferença é fundamental.
O processo faz parte da infraestrutura conhecida como:
Windows Error Reporting — WER.
Em português, podemos interpretar como:
Relatório de Erros do Windows.
O Windows utiliza essa infraestrutura para registrar informações sobre falhas, travamentos e determinados problemas de aplicativos e componentes do sistema.
Isso permite que o próprio Windows, administradores, desenvolvedores e técnicos obtenham pistas sobre perguntas como:
- qual programa falhou;
- em qual horário;
- qual módulo estava envolvido;
- qual tipo de exceção ocorreu;
- qual versão do aplicativo estava em execução;
- se existe um padrão recorrente;
- se diferentes computadores apresentam a mesma falha.
Por isso, ao diagnosticar programas que fecham sozinhos, WerFault.exe não deve ser tratado automaticamente como culpado.
Frequentemente ele é apenas uma das consequências visíveis do problema.
Primeiro: o que é WerFault.exe?
WerFault.exe é um componente legítimo do Windows relacionado ao Windows Error Reporting.
Quando determinado aplicativo apresenta uma falha, o Windows pode iniciar componentes da infraestrutura WER para coletar informações sobre o erro.
Dependendo do tipo de falha e da configuração do sistema, essas informações podem ser utilizadas para:
- criar relatórios;
- registrar eventos;
- gerar dados de diagnóstico;
- produzir dumps em determinados cenários;
- correlacionar falhas;
- auxiliar na investigação técnica.
O nome WerFault possui uma lógica
Podemos separar:
WER
de:
Fault
WER:
Windows Error Reporting
Fault:
falha
Ou seja, o nome está diretamente relacionado ao tratamento de falhas detectadas pelo Windows.
Onde fica o WerFault.exe legítimo?
Em um Windows legítimo, o executável do sistema fica associado às pastas protegidas do Windows, normalmente em:
C:\Windows\System32\WerFault.exe
Em sistemas Windows de 64 bits também podem existir componentes correspondentes utilizados conforme a arquitetura do processo envolvido.
O ponto mais importante é:
não basta olhar apenas para o nome do arquivo.
Se existir suspeita de malware, devemos observar:
- caminho;
- assinatura digital;
- propriedades;
- contexto;
- comportamento.
Um arquivo chamado WerFault.exe em uma pasta aleatória não deve ser automaticamente considerado legítimo só por possuir o mesmo nome.
WerFault.exe é vírus?
O arquivo legítimo faz parte do Windows.
Portanto:
WerFault.exe = vírus
é uma conclusão errada.
Entretanto, malware pode tentar utilizar nomes parecidos com processos conhecidos.
Por isso, em caso de dúvida, confirme:
- localização do arquivo;
- assinatura;
- editor;
- comportamento.
WerFault.exe faz o programa travar?
Normalmente não.
Esta é provavelmente a dúvida mais importante do artigo.
Em muitos casos temos esta sequência:
Aplicativo está funcionando
↓
Aplicativo encontra uma falha
↓
Processo encerra ou fica instável
↓
Windows detecta o problema
↓
WER entra em ação
↓
WerFault.exe aparece
Isso significa que WerFault.exe pode surgir depois da falha.
Cuidado com causa e consequência
Esse erro de interpretação acontece bastante no diagnóstico do Windows.
O usuário vê:
Programa fecha
e imediatamente depois:
WerFault.exe
Então conclui:
“WerFault.exe derrubou o programa.”
Mas a ordem real pode ser:
o programa falhou primeiro e WerFault.exe apareceu porque o Windows tentou registrar o problema.
O que significa “fault”?
Em computação, “fault” pode indicar uma condição de falha.
Nem toda falha possui a mesma causa.
Podemos ter problemas relacionados a:
- acesso inválido à memória;
- biblioteca incompatível;
- módulo com defeito;
- driver;
- corrupção de arquivos;
- plugin;
- dados inválidos;
- configuração;
- atualização problemática;
- dependência ausente.
WerFault.exe não explica sozinho a causa
Encontrar o processo apenas diz que a infraestrutura de relatório de erros pode estar envolvida.
Para descobrir o motivo real, precisamos analisar outros dados.
O primeiro lugar para procurar pistas
Uma das ferramentas mais úteis é o:
Monitor de Confiabilidade.
Execute:
perfmon /rel
O que o Monitor de Confiabilidade mostra?
Ele apresenta uma linha do tempo do sistema com informações sobre:
- falhas de aplicativos;
- falhas do Windows;
- instalações;
- atualizações;
- outros eventos importantes.
Por que ele é tão útil?
Porque mostra o problema de forma cronológica.
Imagine:
10:20 — atualização do programa
10:35 — primeira falha
11:10 — segunda falha
14:30 — terceira falha
Esse padrão já fornece uma pista importante.
Clique na falha
Dependendo do evento, podemos encontrar informações como:
- nome do aplicativo;
- versão;
- módulo com falha;
- código de exceção;
- caminho.
“Aplicativo com falha”
Um dos campos que pode aparecer é equivalente a:
Faulting Application Name
Ou:
Nome do aplicativo com falha.
Esse campo identifica o executável que apresentou o problema.
Exemplo
app.exe
Isso significa que o processo app.exe encontrou uma falha.
“Faulting Module”
Outro campo muito importante:
Faulting Module Name
Ou:
Nome do módulo com falha.
O que é um módulo?
Pode ser, por exemplo:
- EXE;
- DLL;
- componente carregado pelo processo.
Isso muda completamente a investigação
Imagine:
Aplicativo com falha: app.exe
Módulo com falha: plugin.dll
Agora temos uma pista muito mais específica.
O problema pode não estar no EXE principal
Pode estar em:
- plugin;
- biblioteca;
- driver;
- runtime;
- integração.
Exemplo
Um editor de imagens fecha toda vez que abre determinado recurso.
O evento mostra:
Faulting Module: gpuplugin.dll
Isso direciona a investigação para outra camada.
Código de exceção
Outro campo importante pode aparecer como:
Exception Code
ou:
Código de exceção.
O que é uma exceção?
Uma exceção representa uma condição anormal detectada durante a execução do programa.
Nem todo código significa a mesma coisa
O código pode ajudar a identificar a categoria do problema.
Mas:
não devemos interpretar o código isoladamente.
Precisamos analisar:
- aplicativo;
- módulo;
- horário;
- versão;
- padrão.
Um código conhecido
Um dos códigos que aparece com frequência em falhas de aplicações é:
0xc0000005
Ele costuma estar associado a violação de acesso.
O que significa isso de forma simples?
O programa tentou acessar memória de uma forma que não era permitida.
Isso prova RAM com defeito?
Não.
Essa é uma confusão comum.
Uma violação de acesso pode ter várias causas, como:
- bug no aplicativo;
- DLL;
- plugin;
- driver;
- corrupção;
- incompatibilidade;
- software de segurança.
Memória RAM física é apenas uma das possibilidades
Não deve ser a primeira conclusão automática.
Outro erro comum
Usuário vê:
0xc0000005
e imediatamente executa:
- CHKDSK;
- SFC;
- teste de RAM;
- reinstala Windows.
Isso pode desperdiçar tempo.
Primeiro precisamos descobrir o padrão
Pergunte:
- acontece só em um programa?
- acontece em vários?
- sempre no mesmo módulo?
- começou após atualização?
- ocorre somente ao abrir determinada função?
Se apenas um programa falha
A investigação deve começar pelo ecossistema daquele aplicativo.
Se vários programas diferentes falham
Agora o universo aumenta.
Podemos considerar:
- driver;
- memória;
- sistema;
- software de segurança;
- hardware;
- biblioteca compartilhada.
Event Viewer
Outra ferramenta fundamental é:
eventvwr.msc
O Visualizador de Eventos registra informações mais detalhadas sobre muitos problemas.
Onde procurar?
Um caminho comum é:
Logs do Windows
↓
Aplicativo
Application Error
Podemos encontrar eventos com origem relacionada a:
Application Error
Esses eventos podem registrar
- nome do aplicativo;
- versão;
- módulo com falha;
- endereço;
- código de exceção;
- identificadores adicionais.
Windows Error Reporting
Também podem existir eventos associados ao:
Windows Error Reporting.
Esses registros ajudam a correlacionar a falha com a infraestrutura WER.
Application Error e Windows Error Reporting não são a mesma coisa
Isso é importante.
Um evento pode representar a falha do aplicativo.
Outro pode representar o processamento do relatório de erro.
Linha do tempo novamente
Podemos encontrar:
14:32:01 — Application Error
e depois:
14:32:03 — Windows Error Reporting
Isso reforça a ideia de:
falha
↓
relatório
WerFault.exe pode aparecer rapidamente e desaparecer
Sim.
Isso pode ser completamente normal.
Por quê?
O processo pode executar a tarefa de tratamento do erro e encerrar.
WerFault.exe aparecendo várias vezes é problema?
Depende.
Se vários aplicativos estão falhando continuamente, o Windows pode iniciar repetidamente a infraestrutura de relatórios.
Então o problema real pode estar nos aplicativos que estão caindo.
Exemplo
Você observa:
WerFault.exe
dez vezes em poucos minutos.
A pergunta não deve ser apenas:
“Por que WerFault aparece?”
Pergunte:
“Qual aplicativo está falhando repetidamente?”
WerFault.exe usando muita CPU
Na maioria dos sistemas, ele não deveria permanecer indefinidamente consumindo grande quantidade de recursos.
Se isso acontecer, precisamos investigar.
Possibilidades
- aplicativo entrando em ciclo de falha;
- geração repetida de relatórios;
- processo instável;
- muitos crashes em sequência;
- componente externo interferindo.
Primeiro passo
Abra o Monitor de Confiabilidade:
perfmon /rel
Veja se existem várias falhas no mesmo período.
Segundo passo
Abra:
eventvwr.msc
Compare os horários.
Terceiro passo
Descubra qual aplicativo aparece repetidamente.
Não finalize WerFault como solução definitiva
Encerrar o processo pode apenas remover o sintoma momentaneamente.
Se outro aplicativo continuar falhando, ele poderá reaparecer.
Windows Error Reporting
Agora precisamos entender o WER com mais profundidade.
WER não serve apenas para mostrar uma mensagem de erro
Ele faz parte de uma infraestrutura criada para coletar informações estruturadas sobre falhas.
Por que isso é importante?
Imagine milhões de computadores executando o mesmo aplicativo.
Se muitos apresentarem a mesma falha:
mesmo programa
mesma versão
mesmo módulo
mesmo código
isso forma um padrão.
Desenvolvedores também podem usar esses dados
Em ambientes apropriados, relatórios de falha podem ajudar a identificar bugs recorrentes.
O Windows precisa classificar os problemas
Por isso vemos conceitos como:
- Application Name;
- Application Version;
- Faulting Module;
- Exception Code;
- Fault Offset.
Fault Offset
Outro campo técnico que pode aparecer é:
Fault Offset.
O que significa?
Representa uma posição relacionada ao local onde a falha ocorreu dentro do módulo.
Ele é útil para usuários comuns?
Normalmente não diretamente.
Para desenvolvedores?
Pode ser muito mais útil quando combinado com símbolos de depuração e informações da versão correta do binário.
Para manutenção técnica comum
Os campos mais úteis geralmente são:
- aplicativo;
- módulo;
- código de exceção;
- horário.
Versão importa muito
Imagine:
Programa 5.2.1 → falha
Depois atualiza para:
Programa 5.2.2 → não falha
Isso aponta para correção específica da aplicação.
O contrário também acontece
5.2.1 → funciona
5.2.2 → começa a falhar
Agora a atualização vira uma forte candidata.
Por isso registre versões
Não anote apenas:
“Outlook trava.”
Anote:
- versão do Outlook;
- versão do Windows;
- horário;
- módulo;
- ação que provoca o erro.
Falha reproduzível
Este conceito é extremamente valioso.
Uma falha é reproduzível quando conseguimos repetir o problema seguindo passos parecidos.
Exemplo
- Abrir aplicativo.
- Abrir menu X.
- Selecionar arquivo Y.
- Aplicativo fecha.
Se isso acontece sempre, temos um cenário muito melhor para investigação.
Falha aleatória
Muito mais difícil.
Pode exigir:
- linha do tempo;
- logs;
- monitoramento;
- comparação.
WerFault.exe e “programa não está respondendo”
Travamento e crash não são exatamente a mesma coisa.
Crash
O processo encontra uma falha e pode encerrar.
Hang
O processo continua existindo, mas deixa de responder adequadamente.
O Windows pode detectar ambos
Dependendo da situação, diferentes mecanismos podem entrar em ação.
“Não está respondendo”
Isso geralmente significa que a interface não está processando mensagens como esperado.
Isso não significa necessariamente que o programa morreu
Ele pode estar:
- bloqueado;
- esperando recurso;
- preso em operação;
- aguardando rede;
- em deadlock.
WerFault.exe e dumps
Em determinadas configurações e cenários, o Windows Error Reporting pode gerar dumps.
O que é um dump?
Um dump contém informações sobre o estado de um processo no momento de uma falha.
É muito útil para desenvolvedores
Porque permite análise mais profunda.
Para usuário comum
Não precisamos abrir dumps sem necessidade.
Para técnico avançado
Eles podem ajudar a identificar:
- thread com falha;
- módulo envolvido;
- call stack;
- exceção.
Mas isso já entra em depuração avançada
Para diagnóstico cotidiano, comece pelos logs.
LocalDumps
O Windows possui mecanismos que podem ser configurados para coleta local de dumps de aplicativos em cenários de diagnóstico.
Mas isso deve ser utilizado de maneira planejada, principalmente porque dumps podem ocupar espaço e conter dados da memória do processo.
Não ative coleta indiscriminadamente
Use apenas quando realmente necessário.
Process Monitor
Outra ferramenta extremamente útil é:
Process Monitor, da Sysinternals.
O que ele mostra?
Atividade de:
- arquivos;
- Registro;
- processos;
- outras operações do sistema.
Quando é útil?
Imagine que um programa sempre trava ao tentar abrir uma configuração.
O Process Monitor pode mostrar o que ocorreu imediatamente antes da falha.
Exemplo conceitual
app.exe
↓
tenta abrir config.dll
↓
NAME NOT FOUND
↓
tenta outro caminho
↓
ACCESS DENIED
↓
processo falha
Mas cuidado:
NAME NOT FOUND não significa automaticamente erro fatal
Programas procuram arquivos em vários caminhos.
É normal existirem operações que retornam:
NAME NOT FOUND
durante uma busca.
ACCESS DENIED também precisa de contexto
Muitos aplicativos tentam acessar recursos opcionais e seguem funcionando mesmo quando recebem negação.
ProcMon exige interpretação
Não transforme qualquer linha vermelha em causa do problema.
Process Explorer
Process Explorer ajuda a examinar:
- processo;
- módulos carregados;
- árvore de processos;
- caminho;
- assinatura.
Módulos carregados podem ajudar
Se um aplicativo carrega extensões, plugins ou DLLs de terceiros, uma dessas bibliotecas pode estar relacionada ao crash.
Exemplo
Aplicativo:
programa.exe
carrega:
pluginA.dll
pluginB.dll
antivirusHook.dll
graphicsExtension.dll
Se a falha sempre aponta para um módulo específico, temos uma pista valiosa.
Módulo com falha não significa culpado absoluto
Isso também é importante.
Uma DLL pode ser o local onde a falha se manifesta sem ser a origem verdadeira.
Exemplo
Dados inválidos enviados por outro componente podem causar a exceção dentro de uma DLL.
Portanto use:
Faulting Module como pista, não como sentença.
Reliability Monitor versus Event Viewer
O Monitor de Confiabilidade é excelente para visão cronológica.
O Visualizador de Eventos fornece mais detalhes técnicos.
Use os dois juntos
Primeiro:
perfmon /rel
Depois:
eventvwr.msc
Uma sequência eficiente
- Descobrir o horário.
- Identificar o aplicativo.
- Confirmar a repetição.
- Abrir o evento correspondente.
- Ver módulo e código.
Só depois faça alterações
Essa ordem evita “atirar para todos os lados”.
WerFault.exe e atualizações do Windows
Se as falhas começaram imediatamente após uma atualização, registre isso.
Mas cuidado:
correlação não prova causalidade.
Pergunte
O problema começou exatamente depois?
Ou foi apenas percebido depois?
Atualização do aplicativo também importa
Muitas vezes o usuário culpa o Windows porque houve atualização recente, mas quem mudou foi:
- navegador;
- driver;
- plugin;
- antivírus;
- aplicativo.
Linha do tempo resolve muita coisa
WerFault.exe e driver de vídeo
Aplicativos gráficos podem travar por problemas relacionados a:
- driver;
- GPU;
- aceleração por hardware;
- plugins gráficos.
Mas nem todo crash gráfico é culpa do driver
Investigue o módulo envolvido.
WerFault.exe e Office
Programas do Office podem apresentar falhas relacionadas a:
- suplemento;
- arquivo;
- perfil;
- driver de impressão;
- integração;
- atualização.
Se apenas Word falha
Não comece formatando o Windows.
Se Word falha somente ao imprimir
A investigação pode mudar para:
- driver de impressora;
- spooler;
- integração de impressão.
Se Word falha apenas ao abrir um documento
Talvez o arquivo ou conteúdo específico esteja envolvido.
Esse raciocínio vale para qualquer aplicativo
Pergunte:
Em qual ação exata ele cai?
Primeira sequência de diagnóstico WerFault.exe
1. Não trate WerFault.exe como culpado automaticamente
2. Abra o Monitor de Confiabilidade
perfmon /rel
3. Localize o horário do crash
4. Identifique o aplicativo
5. Verifique o módulo com falha
6. Anote o código de exceção
7. Verifique se o problema se repete
8. Compare a versão do aplicativo
9. Verifique atualização recente
10. Teste o cenário que provoca a falha
11. Observe se acontece em outro usuário
12. Teste o aplicativo em modo seguro, se ele possuir essa opção
13. Avalie plugins e integrações
14. Use Process Explorer ou Process Monitor quando necessário
15. Só então considere reparo, reinstalação ou investigação do sistema
O ponto central da Parte 1
Quando você vê WerFault.exe, não pense imediatamente:
“Esse processo está causando erro.”
Pense:
“Qual aplicativo falhou e por que o Windows precisou iniciar o relatório de erro?”
Essa simples mudança de raciocínio melhora muito o diagnóstico.
Windows Error Reporting por dentro: Application Error, AppCrash, AppHang, dumps e ferramentas de diagnóstico
Na Parte 1 vimos a ideia mais importante deste artigo:
WerFault.exe normalmente aparece porque alguma outra coisa falhou.
Agora vamos aprofundar o que o Windows Error Reporting registra e como interpretar essas informações sem cair no erro de culpar automaticamente a primeira DLL ou processo que aparece no relatório.
O que é Windows Error Reporting?
O Windows Error Reporting, abreviado como:
WER
é a infraestrutura do Windows responsável por coletar e organizar informações sobre determinados erros de aplicativos e componentes.
Em vez de apenas registrar:
“o programa fechou”
o Windows pode reunir dados que ajudam a responder:
- qual aplicativo falhou;
- qual versão estava em execução;
- qual módulo estava envolvido;
- qual exceção ocorreu;
- em qual ponto do módulo;
- quando aconteceu;
- quantas vezes se repetiu.
Por que isso é melhor do que uma mensagem genérica?
Porque duas falhas visualmente iguais podem ter causas completamente diferentes.
Imagine:
programa.exe fechou sozinho
Isso poderia significar:
- plugin defeituoso;
- DLL incompatível;
- bug do programa;
- driver;
- arquivo corrompido;
- perfil problemático;
- problema gráfico;
- biblioteca compartilhada.
Sem detalhes, tudo parece igual.
WerFault.exe e WerMgr.exe
Dependendo da versão, configuração e cenário, diferentes componentes relacionados ao WER podem aparecer.
Entre os nomes historicamente associados à infraestrutura estão:
WerFault.exe
e:
WerMgr.exe
Não é necessário que ambos apareçam em toda falha.
O que importa no diagnóstico?
Mais do que decorar processos, precisamos identificar:
qual evento ocorreu primeiro e qual aplicativo estava envolvido.
Application Error
No Visualizador de Eventos, uma origem muito importante é:
Application Error
Ela pode registrar informações relacionadas ao crash de um aplicativo.
Abra o Visualizador de Eventos
Execute:
eventvwr.msc
Depois navegue para:
Logs do Windows
↓
Aplicativo
Procure o horário exato da falha
Se o usuário disser:
“o programa fechou aproximadamente às 16:20”
comece pelos eventos próximos desse horário.
Não procure pelo dia inteiro
Quanto menor a janela de tempo, melhor.
Campos comuns em um Application Error
Dependendo do evento, podemos encontrar algo semelhante a:
- Faulting application name;
- Faulting application version;
- Faulting module name;
- Faulting module version;
- Exception code;
- Fault offset;
- Process ID;
- Application start time;
- Application path;
- Module path.
Faulting Application Name
Esse campo identifica o aplicativo que apresentou a falha.
Exemplo:
photoshop.exe
Faulting Module Name
Indica o módulo onde a exceção foi registrada.
Exemplo:
plugin.dll
ou:
ntdll.dll
ou:
ucrtbase.dll
Aqui existe uma armadilha importante
Se o relatório mostra:
ntdll.dll
isso não significa automaticamente:
“ntdll.dll está com defeito.”
Por que?
Porque ntdll.dll participa de muitas operações internas do Windows.
Uma falha originada por outro componente pode terminar aparecendo dentro dela.
O mesmo vale para outras DLLs do sistema
Por exemplo:
KERNELBASE.dll;ucrtbase.dll;VCRUNTIME;- outras bibliotecas comuns.
Módulo com falha é pista, não condenação
Sempre combine:
Faulting Module
com:
Exception Code
ação executada
versão do aplicativo
repetição do problema
Exception Code
O código de exceção ajuda a classificar a falha.
Um exemplo comum:
0xc0000005
Violação de acesso
Esse código geralmente está associado a uma tentativa inválida de acesso à memória.
Mas ele não responde sozinho:
quem causou a situação?
Possíveis origens de 0xc0000005
Podemos encontrar:
- bug do aplicativo;
- plugin;
- DLL;
- driver;
- corrupção de dados;
- erro de memória;
- incompatibilidade;
- software interferindo no processo.
Portanto
0xc0000005 = RAM defeituosa
é uma conclusão precipitada.
Fault Offset
O relatório também pode mostrar um deslocamento dentro do módulo.
Exemplo conceitual:
Fault Offset: 0x0000000000123456
Para que serve?
Pode ajudar desenvolvedores e analistas que possuem símbolos e binários correspondentes.
Para manutenção comum, costuma ser menos útil que:
- aplicativo;
- módulo;
- código;
- versão;
- horário.
AppCrash
Você também pode encontrar referências a:
AppCrash
Esse tipo de identificação é usado para representar determinado padrão de falha de aplicativo.
AppCrash não é um programa
É uma classificação de problema.
AppHang
Outro conceito:
AppHang
Aqui a situação é diferente.
O aplicativo pode continuar aberto, mas parar de responder.
Crash versus Hang
Crash
O processo sofre falha e pode terminar.
Hang
O processo continua existindo, mas sua execução fica bloqueada ou sem responder adequadamente.
Exemplo simples
Crash:
programa.exe fecha
Hang:
programa.exe continua aberto com "Não está respondendo"
O diagnóstico também muda
Um crash pode apontar mais diretamente para exceção e módulo.
Um hang pode exigir investigar:
- thread bloqueada;
- espera por recurso;
- rede;
- disco;
- deadlock;
- extensão.
Windows Error Reporting também pode registrar hangs
Dependendo do cenário, sim.
Monitor de Confiabilidade
O Monitor de Confiabilidade simplifica bastante essa investigação.
Execute:
perfmon /rel
Por que ele é tão útil?
Porque organiza os eventos por dia e horário.
Você pode visualizar:
- falhas de aplicativo;
- falhas do Windows;
- instalações;
- atualizações.
Exemplo de linha do tempo
Segunda-feira
- instalação de atualização;
- primeira falha.
Terça-feira
- três falhas do mesmo programa.
Quarta-feira
- nova atualização;
- nenhuma falha.
Esse padrão vale ouro no diagnóstico.
Ver detalhes técnicos
Ao clicar em uma falha, o Monitor de Confiabilidade pode mostrar detalhes parecidos com os registrados pelo WER.
Reliability Monitor e Event Viewer se complementam
Use:
perfmon /rel
para enxergar o padrão.
Depois:
eventvwr.msc
para aprofundar o evento.
O que é um crash dump?
Um dump é uma captura de informações sobre o estado do processo no momento da falha.
Ele pode incluir
Dependendo do tipo:
- threads;
- registradores;
- módulos;
- memória;
- stack;
- contexto da exceção.
Existem diferentes níveis de dump
Podemos pensar de forma geral em:
- dump menor;
- dump mais completo.
MiniDump
Um dump pequeno guarda informações suficientes para algumas análises sem copiar toda a memória do processo.
Full Dump
Um dump completo pode conter uma quantidade muito maior de memória do processo.
Quanto mais completo, maior o arquivo
Um aplicativo usando vários gigabytes de RAM pode gerar um dump grande.
Dumps podem conter dados sensíveis
Essa observação é importante.
A memória de um processo pode conter:
- documentos abertos;
- URLs;
- partes de mensagens;
- informações temporárias;
- dados internos do aplicativo.
Portanto não compartilhe dumps indiscriminadamente.
LocalDumps
O Windows possui suporte para configurar coleta local de dumps de determinados aplicativos.
Isso pode ser útil quando:
- o problema é reproduzível;
- o evento não explica a causa;
- o desenvolvedor precisa analisar a falha.
Mas não ative coleta geral sem necessidade
Especialmente Full Dumps.
Você pode rapidamente:
- ocupar muito espaço;
- coletar dados desnecessários;
- dificultar a análise.
ProcDump
A ferramenta ProcDump, da Sysinternals, também pode ser utilizada em diagnóstico avançado de falhas e travamentos.
Para que serve?
Ela pode capturar dumps quando certas condições ocorrem.
Isso é útil quando
- o programa trava aleatoriamente;
- o crash é difícil de reproduzir manualmente;
- precisamos registrar o momento exato.
Mas ainda precisamos saber o que procurar
Gerar dezenas de dumps sem uma hipótese técnica apenas cria mais dados.
O melhor fluxo
Primeiro:
Monitor de Confiabilidade
Depois:
Event Viewer
Depois:
Process Explorer / Process Monitor
Somente então:
dump
se realmente necessário.
Process Explorer
O Process Explorer permite visualizar:
- árvore de processos;
- executáveis;
- módulos carregados;
- assinatura;
- caminho;
- PID.
Isso ajuda muito em programas extensíveis
Imagine um programa que carrega:
- 20 plugins;
- codecs;
- shell extensions;
- módulos gráficos.
Se o problema começou depois de instalar um plugin, a árvore e módulos podem ajudar a confirmar o cenário.
Process Monitor
Process Monitor é ainda mais detalhado.
Ele mostra operações em tempo real.
Exemplos
- arquivo sendo aberto;
- DLL procurada;
- chave de Registro acessada;
- processo criado;
- operação negada.
Filtrar pelo processo é fundamental
Sem filtro, o ProcMon gera milhares de eventos.
Exemplo conceitual
Filtre por:
Process Name is programa.exe
Agora execute a ação que provoca o crash.
Procure o que acontece imediatamente antes
Talvez o programa tente:
Load Image pluginX.dll
e segundos depois caia.
Isso vira uma pista.
Mas cuidado novamente
Correlação temporal não prova causalidade absoluta.
O plugin pode estar envolvido
ou apenas ser carregado normalmente.
Process Monitor e DLL ausente
Uma linha:
NAME NOT FOUND
não é prova de defeito.
Programas frequentemente procuram o mesmo arquivo em vários diretórios
Exemplo:
C:\Program Files\App\arquivo.dll
NAME NOT FOUND
depois:
C:\Windows\System32\arquivo.dll
SUCCESS
Isso pode ser normal.
ACCESS DENIED também pode ser esperado
O sistema possui várias barreiras de segurança.
Nem todo acesso negado derruba o aplicativo.
ProcMon precisa de contexto
O melhor uso é comparar:
execução que funciona
versus:
execução que falha
Comparação A/B
Esse método é poderoso.
Exemplo:
Usuário A → programa funciona
Usuário B → programa trava
Agora compare:
- perfil;
- AppData;
- Registro por usuário;
- plugins;
- configurações.
Outro teste
Modo normal → trava
Modo seguro do aplicativo → funciona
Agora plugins e integrações entram como suspeitos fortes.
Outro
Aceleração por hardware ligada → trava
Aceleração desligada → funciona
Agora GPU/driver/camada gráfica merece atenção.
Outro
Arquivo A → abre
Arquivo B → trava
Agora investigue o conteúdo do arquivo B.
Outro
Imprimir → trava
Abrir/salvar → funciona
Agora investigue a pilha de impressão.
Outro
Rede conectada → trava
Offline → funciona
Agora existe possível dependência de rede.
O segredo é reduzir variáveis
Sempre que possível, mude uma coisa por vez.
Faulting Module aponta para DLL de terceiro
Isso costuma ser uma pista forte.
Exemplo:
addon123.dll
Se a DLL pertence a um plugin recém-instalado, vale:
- desabilitar o plugin;
- atualizar;
- testar sem ele.
Faulting Module aponta para driver
Também pode acontecer.
Principalmente em aplicações que usam:
- GPU;
- áudio;
- câmera;
- impressora;
- dispositivos externos.
Faulting Module aponta para ntdll.dll
Esse caso exige mais cuidado.
Não substitua ntdll.dll manualmente
Nunca baixe DLL do sistema em sites aleatórios.
Primeiro investigue o aplicativo
Pergunte:
- só ele falha?
- todos falham?
- existe plugin?
- existe módulo de terceiro?
- começou após atualização?
Se apenas um aplicativo falha
A chance de problema específico daquele aplicativo costuma ser maior.
Se dezenas de aplicativos falham
A investigação precisa ampliar.
Podemos considerar:
- memória;
- armazenamento;
- sistema;
- driver;
- hardware.
WerFault.exe e antivírus
Softwares de segurança podem injetar ou integrar módulos a processos.
Em alguns casos, incompatibilidades podem contribuir para crashes.
Como testar?
Primeiro veja se existe correlação clara com instalação ou atualização do software.
Não desligue proteções indiscriminadamente.
WerFault.exe e driver gráfico
Aplicativos que usam aceleração por hardware podem apresentar falhas após:
- atualização de driver;
- alteração de GPU;
- mudança de configuração gráfica.
Um teste útil
Se o próprio aplicativo oferece opção de desabilitar aceleração por hardware, um teste A/B pode fornecer pista.
WerFault.exe e impressoras
Sim, impressão também pode causar crash.
Um aplicativo pode carregar:
- driver;
- interface de impressão;
- componentes de terceiros.
Exemplo
Word funciona normalmente
mas:
Ctrl + P → Word fecha
Isso muda completamente o diagnóstico.
Agora examine
- impressora padrão;
- driver;
- spooler;
- porta;
- software da impressora.
WerFault.exe e codecs
Players e editores multimídia podem carregar codecs de terceiros.
Um codec incompatível pode provocar falhas apenas com determinado formato.
Exemplo
MP4 → funciona
MKV específico → trava
Isso é uma pista.
WerFault.exe e shell extensions
Até o Explorador de Arquivos pode carregar extensões de terceiros.
Isso explica casos em que:
- botão direito trava;
- Explorer reinicia;
- pasta específica fecha.
A falha pode aparecer no WER
E o módulo envolvido pode apontar para extensão externa.
WerFault.exe e perfil de usuário
Se o programa funciona em outro usuário, o perfil merece investigação.
Possibilidades
- configuração em AppData;
- cache;
- plugin;
- chave HKCU;
- arquivo de preferências.
Não apague AppData inteiro
Primeiro identifique qual aplicação e qual pasta estão envolvidas.
WerFault.exe e arquivos de configuração
Aplicativos podem travar ao carregar uma configuração corrompida.
Teste seguro
Se o fornecedor documenta um método para redefinir preferências, use-o.
Evite simplesmente excluir pastas aleatórias.
WerFault.exe e runtimes
Alguns aplicativos dependem de:
- .NET;
- Visual C++ Runtime;
- WebView2;
- Java;
- outros frameworks.
Se o módulo aponta para runtime
Não conclua imediatamente que “o Windows está quebrado”.
Pode existir incompatibilidade entre:
- versão do programa;
- runtime;
- plugin;
- dependência.
WerFault.exe e .NET
Aplicativos .NET podem registrar também eventos específicos relacionados ao runtime.
Portanto procure eventos correlacionados
Não observe apenas Application Error.
WerFault.exe e atualização
Se tudo começou depois de atualizar o programa:
- registre a versão antiga;
- registre a nova;
- confirme se o crash começou após a mudança;
- procure notas do fornecedor;
- teste atualização corretiva quando disponível.
Se começou após atualização do Windows
Faça a mesma linha do tempo.
Mas evite assumir automaticamente que o Windows causou o problema.
Pode existir também
- atualização simultânea de driver;
- atualização do aplicativo;
- reinicialização que ativou mudança pendente.
O que é Bucket?
Em relatórios do WER podem aparecer referências a identificadores usados para agrupar falhas semelhantes.
Por que isso existe?
Porque milhares de falhas podem pertencer ao mesmo padrão.
Exemplo conceitual
Mesmo:
- aplicativo;
- versão;
- módulo;
- exceção.
Podem ser agrupados para análise.
Isso ajuda desenvolvedores
Principalmente em cenários de telemetria e diagnóstico em escala.
Para técnico local
O mais importante continua sendo:
repetição + módulo + código + ação.
Fluxo de diagnóstico aprofundado
Etapa 1 — Reproduza o problema
Quando possível.
Etapa 2 — Registre o horário
Etapa 3 — Abra perfmon /rel
Etapa 4 — Identifique o evento
Etapa 5 — Abra eventvwr.msc
Etapa 6 — Confira Application Error
Etapa 7 — Anote Faulting Application
Etapa 8 — Anote Faulting Module
Etapa 9 — Anote Exception Code
Etapa 10 — Verifique versão
Etapa 11 — Compare com mudanças recentes
Etapa 12 — Teste outro usuário
Etapa 13 — Teste sem plugins
Quando o aplicativo possuir modo suportado.
Etapa 14 — Teste outro arquivo ou função
Etapa 15 — Avalie Process Explorer
Etapa 16 — Avalie ProcMon
Etapa 17 — Faça teste A/B
Etapa 18 — Gere dump apenas se necessário
Etapa 19 — Corrija a camada suspeita
Etapa 20 — Repita o teste
O que não fazer ainda
Nesta fase evite:
- formatar o Windows;
- substituir DLLs manualmente;
- apagar System32;
- remover runtimes aleatoriamente;
- desabilitar segurança sem motivo;
- mexer em Registro sem evidência;
- instalar “DLL fixer”.
“DLL fixer” merece atenção especial
Programas que prometem corrigir qualquer DLL com um clique podem piorar o sistema.
Uma DLL precisa combinar com:
- versão correta;
- arquitetura;
- componente;
- dependências.
Substituição aleatória não é diagnóstico.
Quando SFC entra?
Se vários aplicativos falham e os eventos apontam repetidamente para componentes do Windows, pode fazer sentido verificar integridade do sistema.
Mas isso vem depois
Não antes de identificar o padrão.
Quando DISM entra?
Se houver evidências de corrupção da imagem do Windows ou problemas que SFC não consegue reparar adequadamente.
Quando testar RAM?
Se:
- vários programas sem relação falham;
- códigos variam;
- crashes são aleatórios;
- existem outros sinais de instabilidade.
Quando investigar SSD?
Se também aparecem:
- erros de leitura;
- corrupção de arquivos;
- lentidão;
- problemas SMART;
- eventos de armazenamento.
Um único AppCrash não prova hardware
Esse ponto é importante.
A arquitetura completa do diagnóstico
Podemos resumir:
Aplicativo falha
↓
Windows registra o evento
↓
WER processa informações
↓
WerFault.exe pode aparecer
↓
Monitor de Confiabilidade mostra padrão
↓
Event Viewer fornece detalhes
↓
Process Explorer/ProcMon aprofundam
↓
Dump, se necessário
↓
Causa real
O maior erro continua o mesmo
Parar em:
WerFault.exe
O verdadeiro objetivo
Descobrir:
qual componente falhou primeiro.
Casos práticos: WerFault.exe toda hora, CPU alta, ntdll.dll, KERNELBASE.dll, 0xc0000005, plugins, drivers e falhas por perfil
Agora vamos transformar toda a teoria das Partes 1 e 2 em situações práticas.
O objetivo é responder à pergunta que realmente interessa quando o usuário vê WerFault.exe:
qual programa está falhando e por quê?
A partir daqui, o diagnóstico precisa abandonar soluções genéricas e seguir evidências.
Caso 1 — WerFault.exe aparece toda hora
Se WerFault.exe surge repetidamente, não olhe apenas para ele.
Abra:
perfmon /rel
e verifique se existe um aplicativo falhando várias vezes.
Se o Monitor de Confiabilidade mostra:
app.exe
em vários horários próximos, o foco deve ser esse aplicativo.
Caso 2 — WerFault.exe usa muita CPU
Isso pode acontecer enquanto o Windows processa uma sequência de falhas.
Pergunte:
- existe um aplicativo entrando em loop de crash?
- algum serviço reinicia e falha novamente?
- vários processos estão caindo?
- o uso cai quando o aplicativo problemático é fechado?
Caso 3 — WerFault.exe reaparece logo depois de ser finalizado
Isso sugere que outra falha está ocorrendo novamente.
Encerrar WerFault não elimina a origem.
O processo volta porque o Windows volta a precisar registrar o erro.
Caso 4 — programa fecha somente ao imprimir
Esse cenário muda totalmente a investigação.
Se o programa funciona para:
- abrir;
- editar;
- salvar;
mas fecha em:
Ctrl + P
investigue a pilha de impressão.
Possíveis áreas:
- driver da impressora;
- spooler;
- módulo de impressão;
- extensão de terceiro;
- impressora padrão.
Caso 5 — programa fecha apenas ao abrir um arquivo específico
Agora o problema pode estar no conteúdo do arquivo.
Teste:
arquivo A → abre
arquivo B → trava
Isso sugere uma relação forte com:
- formato;
- estrutura interna;
- conteúdo;
- codec;
- parser;
- plugin.
Caso 6 — qualquer arquivo causa crash
Agora a hipótese muda.
Pode envolver:
- instalação do aplicativo;
- perfil;
- runtime;
- integração do sistema.
Caso 7 — só arquivos de uma extensão travam
Exemplo:
.docx → funciona
.doc antigo → trava
ou:
.mp4 → funciona
.mkv → trava
Isso aponta para:
- codec;
- importador;
- filtro;
- biblioteca específica.
Caso 8 — crash começou depois da atualização do aplicativo
Anote:
- versão anterior;
- versão atual;
- data;
- horário da primeira falha.
Se a correlação é forte, procure correção do próprio fornecedor antes de mexer no Windows.
Caso 9 — crash começou depois da atualização do Windows
Também registre a linha do tempo.
Mas não conclua automaticamente que a atualização é a causa.
Verifique se no mesmo período também mudaram:
- drivers;
- antivírus;
- runtimes;
- aplicativos.
Caso 10 — Faulting Module é ntdll.dll
Esse é um dos diagnósticos mais mal interpretados.
ntdll.dll participa de muitas operações internas.
Se aparece como Faulting Module, isso não significa que a DLL esteja corrompida.
Primeiro investigue:
- aplicativo;
- plugin;
- driver;
- sequência que causa o crash.
Caso 11 — Faulting Module é KERNELBASE.dll
Mesma cautela.
KERNELBASE.dll também aparece em muitos crashes porque diversos aplicativos passam por APIs do sistema.
O módulo pode ser o ponto onde a falha foi detectada, não a causa inicial.
Caso 12 — Faulting Module é ucrtbase.dll
Pode existir relação com:
- runtime;
- aplicação;
- código do programa;
- biblioteca carregada.
Não substitua a DLL manualmente.
Caso 13 — Exception Code 0xc0000005
Esse código costuma indicar violação de acesso.
Pode envolver:
- bug;
- ponteiro inválido;
- DLL;
- plugin;
- driver;
- memória física;
- corrupção.
A pergunta correta não é:
“A RAM está ruim?”
É:
“em qual contexto o 0xc0000005 acontece?”
Caso 14 — 0xc0000005 acontece só em um programa
Isso torna problema específico do aplicativo mais provável.
Caso 15 — 0xc0000005 aparece em vários programas sem relação
Agora amplie a investigação.
Considere:
- memória;
- driver;
- hardware;
- corrupção do sistema;
- software que injeta módulos em vários processos.
Caso 16 — Faulting Module é uma DLL de plugin
Esse é um sinal interessante.
Exemplo:
addonvideo.dll
Se o problema começou após instalar um plugin, faça teste A/B sem ele.
Caso 17 — modo seguro do aplicativo funciona
Muitos programas possuem um modo que inicia com menos extensões ou recursos.
Se:
modo normal → trava
modo seguro → funciona
plugins e integrações entram como suspeitos fortes.
Caso 18 — outro usuário do Windows não apresenta falha
Isso aponta para o perfil.
Possíveis causas:
- AppData;
- HKCU;
- cache;
- preferência;
- plugin por usuário.
Caso 19 — todos os usuários apresentam a mesma falha
Agora pense em algo compartilhado:
- instalação;
- driver;
- runtime;
- serviço;
- sistema.
Caso 20 — crash acontece só com aceleração gráfica ativada
Desativar aceleração por hardware, quando o próprio aplicativo oferece essa opção, pode ser um bom teste.
Se o crash desaparece, investigue:
- driver gráfico;
- GPU;
- renderização;
- módulo específico.
Caso 21 — navegador trava somente ao reproduzir vídeo
Pode envolver:
- aceleração de hardware;
- codec;
- driver;
- DRM;
- extensão.
Caso 22 — navegador funciona em janela anônima, mas não no perfil normal
Isso pode indicar:
- extensão;
- cache;
- perfil;
- configuração.
Caso 23 — Outlook fecha sozinho ao abrir determinado e-mail
Investigue:
- conteúdo;
- suplemento;
- visualização;
- integração;
- perfil;
- OST/PST.
Caso 24 — Word fecha ao abrir determinado documento
Pode existir:
- conteúdo corrompido;
- macro;
- suplemento;
- objeto incorporado;
- fonte problemática.
Caso 25 — Excel fecha ao calcular planilha pesada
Pode existir:
- add-in;
- fórmula;
- memória;
- integração;
- driver gráfico;
- bug específico.
Caso 26 — Explorer.exe trava ao clicar com botão direito
Shell extensions entram na investigação.
Esse é um clássico.
Extensões de terceiros podem se integrar ao menu de contexto.
Caso 27 — Explorer.exe trava ao abrir determinada pasta
Pode envolver:
- thumbnail handler;
- preview handler;
- codec;
- arquivo problemático;
- extensão de shell.
Caso 28 — aplicativo trava apenas ao abrir pasta de rede
Agora investigue também:
- SMB;
- latência;
- credenciais;
- timeout;
- extensão de shell;
- antivírus.
Caso 29 — programa fecha quando a rede cai
Pode existir dependência mal tratada de:
- servidor;
- API;
- arquivo remoto;
- banco de dados;
- licença.
Caso 30 — aplicativo trava só conectado à VPN
Isso aponta para:
- rota;
- DNS;
- serviço remoto;
- autenticação;
- software da VPN.
Caso 31 — Faulting Module é DLL do antivírus
Isso pode indicar interferência ou integração profunda do software de segurança.
Verifique:
- versão;
- atualização recente;
- documentação do fornecedor;
- comportamento em outros PCs.
Não desative proteção de forma permanente sem necessidade.
Caso 32 — Faulting Module é DLL de driver gráfico
Isso pode ocorrer em aplicativos que usam GPU.
Investigue:
- versão do driver;
- atualização recente;
- outro aplicativo gráfico;
- hardware acceleration.
Caso 33 — crash ocorre em jogo específico
Pode envolver:
- engine;
- driver;
- overlay;
- anti-cheat;
- plugin;
- arquivo do jogo.
Caso 34 — vários jogos caem, aplicativos comuns não
Agora GPU, driver e memória gráfica ganham peso.
Caso 35 — vários programas gráficos caem
Pense em:
- driver de vídeo;
- GPU;
- aceleração;
- hardware.
Caso 36 — programas de áudio caem ou travam
Considere:
- driver de áudio;
- APO;
- plugin;
- interface USB;
- sample rate.
Caso 37 — aplicativo trava ao iniciar câmera
Possíveis áreas:
- driver;
- framework de câmera;
- permissão;
- software virtual de câmera;
- integração.
Caso 38 — software trava ao detectar impressora
Pode envolver:
- driver;
- WSD;
- SNMP;
- rede;
- software do fabricante.
Caso 39 — WebView2 aparece perto do crash
Aplicativos modernos podem incorporar conteúdo web com Microsoft Edge WebView2.
Se msedgewebview2.exe aparece, isso não significa automaticamente que ele seja culpado.
Mas pode indicar que a falha está em uma camada web embarcada.
Caso 40 — programa .NET fecha sozinho
Procure também por eventos relacionados ao runtime .NET.
Às vezes Application Error não é a única pista útil.
Caso 41 — aplicativo exige Visual C++ Runtime
Não baixe DLLs avulsas.
Use os redistribuíveis oficiais adequados quando o fornecedor indicar essa dependência.
Caso 42 — programa só funciona depois de reinstalar
Isso pode indicar:
- arquivos da aplicação corrompidos;
- dependência;
- configuração;
- atualização mal aplicada.
Mas se o problema volta, a reinstalação tratou o sintoma, não necessariamente a causa.
Caso 43 — reparar o aplicativo resolve
Bom sinal.
Isso sugere problema relacionado à instalação ou configuração.
Caso 44 — reset do aplicativo resolve
Em aplicativos que oferecem redefinição, isso pode indicar problema no estado do app ou nos dados de configuração.
Caso 45 — reinstalar Windows resolve
Isso é uma solução ampla demais para servir como diagnóstico.
Ela remove muitas variáveis ao mesmo tempo.
Não ajuda a saber qual era a causa original.
Caso 46 — SFC encontra corrupção
Agora existe evidência de problema em arquivos protegidos do sistema.
Mas ainda verifique se o crash desaparece depois do reparo.
Caso 47 — SFC não encontra problemas
Isso não prova que o aplicativo está perfeito.
A falha pode estar totalmente fora dos arquivos protegidos do Windows.
Caso 48 — DISM não resolve
Isso pode ser esperado se o problema for:
- plugin;
- perfil;
- driver;
- aplicativo.
Caso 49 — CHKDSK não encontra erro
Também não elimina causas de aplicação.
Caso 50 — MemTest passa, mas o programa ainda trava
RAM é apenas uma hipótese.
O resultado direciona a investigação para outras camadas.
Caso 51 — crash ocorre sempre depois de 20 minutos
Padrão temporal pode indicar:
- memória aumentando;
- recurso vazando;
- timeout;
- atividade programada.
Caso 52 — memória do programa sobe até ele fechar
Pode existir memory leak.
Observe:
- Working Set;
- Commit;
- Private Bytes.
O Gerenciador de Tarefas ajuda, mas ferramentas mais avançadas podem mostrar tendências com mais precisão.
Caso 53 — programa cai quando Commit fica próximo do limite
Agora a investigação envolve memória virtual e Commit Limit, não apenas RAM física.
Caso 54 — aplicativo trava somente quando disco está em 100%
Pode estar aguardando I/O ou sofrendo com latência extrema.
Mas o disco em 100% pode ser causa ou consequência.
Caso 55 — crash acompanha erros de armazenamento no Event Viewer
Agora SSD/HDD/controlador entram fortemente na investigação.
Caso 56 — crash ocorre somente depois de retornar do modo de suspensão
Considere:
- driver;
- dispositivo;
- GPU;
- estado de energia.
Caso 57 — reiniciar resolve, desligar e ligar não
Fast Startup pode mudar o estado reinicializado.
Esse padrão é relevante.
Caso 58 — desabilitar um plugin resolve completamente
Temos um excelente A/B.
Agora procure:
- versão atualizada;
- compatibilidade;
- substituto.
Caso 59 — reinstalar plugin não resolve
Pode existir configuração por perfil ou conflito com outra extensão.
Caso 60 — WerFault aparece, mas não existe crash visível
Pode existir um processo em segundo plano falhando.
Use:
perfmon /rel
e:
eventvwr.msc
para identificar o executável.
Método das cinco perguntas
Antes de qualquer reparo, responda:
1. Quem falhou?
Qual EXE?
2. Onde falhou?
Qual módulo?
3. Como falhou?
Qual Exception Code?
4. Quando falhou?
Qual horário e o que aconteceu antes?
5. Em qual condição falha?
Sempre? Só ao imprimir? Só em um usuário? Só com GPU?
Essas cinco respostas normalmente reduzem muito o problema.
Matriz rápida de diagnóstico
| Sintoma | Primeira direção |
|---|---|
| só um programa cai | aplicativo/plugin |
| vários programas caem | sistema/driver/hardware |
| só um usuário | perfil |
| só ao imprimir | driver/spooler |
| só com GPU | driver/aceleração |
| só um arquivo | conteúdo/parser |
| após atualização | versão/compatibilidade |
| Faulting Module de terceiro | módulo/plugin |
| ntdll/KERNELBASE | investigar causa anterior |
| 0xc0000005 em vários apps | ampliar para memória/driver/hardware |
Fluxo de diagnóstico completo
1. Reproduza o crash
2. Anote o horário exato
3. Abra perfmon /rel
4. Identifique o executável
5. Abra eventvwr.msc
6. Localize Application Error
7. Anote Faulting Module
8. Anote Exception Code
9. Registre a versão
10. Descubra a ação que causa a falha
11. Teste outro arquivo
12. Teste outro usuário
13. Teste modo seguro do app
14. Teste sem plugins
15. Teste aceleração gráfica, se aplicável
16. Revise atualizações recentes
17. Use Process Explorer
18. Use Process Monitor se necessário
19. Gere dump apenas quando houver motivo
20. Corrija a camada provável
21. Repita o teste
22. Confirme que o crash não retorna
O princípio que evita diagnósticos errados
Se o evento diz:
Faulting Module: ntdll.dll
não conclua:
“vou substituir ntdll.dll.”
Se diz:
0xc0000005
não conclua:
“vou trocar a RAM.”
Se aparece:
WerFault.exe
não conclua:
“WerFault está quebrado.”
O diagnóstico técnico exige correlação.
Depois de entender como WerFault.exe aparece, como o Windows Error Reporting registra falhas e como interpretar Faulting Application, Faulting Module e Exception Code, podemos fechar o diagnóstico com uma regra simples:
WerFault.exe é frequentemente o mensageiro da falha, não o culpado.
Se um programa fecha sozinho no Windows 11, a investigação precisa começar no aplicativo que falhou e nas circunstâncias que antecederam o problema.
WerFault.exe versus Windows Error Reporting
Esses dois nomes estão relacionados, mas não significam exatamente a mesma coisa.
Windows Error Reporting
É a infraestrutura de relatório de erros do Windows.
Também aparece abreviada como:
WER
WerFault.exe
É um dos executáveis relacionados a essa infraestrutura.
Portanto:
WER ≠ apenas WerFault.exe
WerFault.exe versus Application Error
Outro ponto que merece atenção.
Um evento:
Application Error
pode registrar a falha propriamente dita.
Depois, a infraestrutura WER pode processar informações relacionadas ao problema.
Podemos imaginar:
programa.exe
↓
falha
↓
Application Error
↓
Windows Error Reporting
↓
WerFault.exe
Essa sequência é conceitual e pode variar conforme o tipo de falha.
WerFault.exe versus Monitor de Confiabilidade
O Monitor de Confiabilidade não é o WerFault.
Ele funciona como uma excelente interface para visualizar uma linha do tempo de problemas.
Abra com:
perfmon /rel
Para diagnóstico cotidiano, essa costuma ser uma das primeiras ferramentas que vale consultar.
WerFault.exe versus Event Viewer
O Visualizador de Eventos também não é o WER propriamente dito.
Ele permite consultar diversos logs do Windows.
Abra:
eventvwr.msc
Em problemas de aplicativos, uma área importante é:
Logs do Windows > Aplicativo
WerFault.exe versus Process Explorer
Process Explorer serve para observar processos com muito mais profundidade do que o Gerenciador de Tarefas.
Pode ajudar a analisar:
- árvore de processos;
- caminho do executável;
- assinatura;
- PID;
- módulos carregados.
Não substitui o WER.
Complementa a investigação.
WerFault.exe versus Process Monitor
Process Monitor observa operações realizadas pelos processos.
Pode mostrar atividade relacionada a:
- arquivos;
- Registro;
- processos;
- carregamento de imagens;
- outros recursos do sistema.
Ele é especialmente útil quando precisamos descobrir:
“o que o aplicativo tentou fazer imediatamente antes do crash?”
WerFault.exe versus ProcDump
ProcDump permite capturar dumps em condições específicas.
É uma ferramenta de diagnóstico mais avançada.
O fluxo correto normalmente não começa por ela.
Primeiro precisamos saber:
- qual processo falha;
- quando;
- como;
- se conseguimos reproduzir.
Tabela de ferramentas
| Ferramenta | Melhor uso inicial |
|---|---|
| Gerenciador de Tarefas | CPU, RAM, processos e PID |
| Monitor de Confiabilidade | Linha do tempo das falhas |
| Event Viewer | Detalhes técnicos dos eventos |
| Process Explorer | Processos, módulos e assinaturas |
| Process Monitor | Arquivos, Registro e operações |
| ProcDump | Captura planejada de dumps |
| SFC | Integridade de arquivos protegidos do Windows |
| DISM | Integridade da imagem/component store |
| CHKDSK | Estrutura do sistema de arquivos |
| Diagnóstico de memória | Investigação de possível instabilidade de RAM |
Qual ferramenta usar primeiro?
Para um programa que simplesmente fecha sozinho:
1. Monitor de Confiabilidade
perfmon /rel
2. Visualizador de Eventos
eventvwr.msc
3. Testes A/B
Outro usuário, outro arquivo, sem plugin, outra configuração.
4. Process Explorer
Quando precisamos observar módulos e processos.
5. Process Monitor
Quando precisamos investigar a sequência anterior à falha.
6. Dump
Quando as informações anteriores não bastam.
Quando usar SFC?
Execute SFC quando houver motivo para suspeitar de corrupção de arquivos protegidos do Windows.
O comando conhecido é:
sfc /scannow
Mas SFC não é:
“corrigir qualquer programa que fecha sozinho”.
Quando usar DISM?
DISM pode ajudar quando existem problemas relacionados à integridade da imagem do Windows e seus componentes.
Um comando utilizado em reparos é:
DISM /Online /Cleanup-Image /RestoreHealth
Isso não significa que devemos executá-lo automaticamente para todo AppCrash.
Quando usar CHKDSK?
CHKDSK verifica aspectos do sistema de arquivos e do volume.
Ele pode fazer sentido quando existem indícios relacionados a:
- erros do volume;
- corrupção;
- problemas de armazenamento.
Não é ferramenta específica para WerFault.
Quando testar memória RAM?
RAM merece investigação quando encontramos um padrão mais amplo, por exemplo:
- vários programas diferentes falhando;
- erros aparentemente aleatórios;
- instabilidade geral;
- outros sinais relacionados à memória.
Um único aplicativo falhando sempre no mesmo plugin é um cenário completamente diferente.
Quando investigar SSD?
Procure evidências adicionais:
- erros de armazenamento;
- arquivos corrompidos;
- SMART preocupante;
- problemas de leitura;
- travamentos relacionados a I/O.
Não culpe o SSD porque um programa fechou uma vez.
Quando investigar GPU?
A investigação gráfica ganha força quando:
- programas 3D falham;
- jogos caem;
- aplicativos travam com aceleração;
- módulos gráficos aparecem nos eventos;
- existem outros sintomas de vídeo.
Quando investigar driver de impressora?
Quando o padrão é:
aplicativo funciona
↓
abre impressão
↓
aplicativo fecha
Essa sequência é muito mais valiosa do que simplesmente saber que houve um AppCrash.
Quando investigar plugin?
Quando:
- modo seguro funciona;
- modo normal falha;
- Faulting Module aponta para extensão;
- problema começou após instalar plugin.
Quando investigar perfil?
Quando:
Usuário A → falha
Usuário B → funciona
Esse teste é extremamente poderoso.
Quando reinstalar o programa?
Depois de identificar que o problema está provavelmente na instalação ou nos componentes específicos do aplicativo.
Reinstalar pode ser válido.
Mas faça isso de forma consciente.
Quando reparar o aplicativo?
Se o fornecedor ou o Windows oferece uma função de reparo, ela pode ser uma tentativa menos agressiva do que remover tudo.
Quando redefinir?
Alguns aplicativos oferecem:
Redefinir
Isso pode apagar dados/configurações locais do aplicativo.
Por isso, verifique o impacto antes.
Quando formatar o Windows?
Formatação não deve ser o primeiro passo para um programa que apresenta crash.
Se apenas um aplicativo falha e todos os outros funcionam, reinstalar o sistema inteiro é uma resposta desproporcional antes de investigar o programa.
20 erros comuns ao diagnosticar WerFault.exe
1. Culpar WerFault.exe
É o erro principal.
2. Finalizar WerFault e considerar resolvido
O processo pode reaparecer na próxima falha.
3. Culpar ntdll.dll imediatamente
Ela pode apenas ser o local onde a falha apareceu.
4. Culpar KERNELBASE.dll imediatamente
Mesmo problema.
5. Interpretar 0xc0000005 como RAM defeituosa
Existem várias outras causas possíveis.
6. Baixar DLL de um site qualquer
Pode criar incompatibilidade ou risco de segurança.
7. Rodar CHKDSK sem evidência
Não é solução universal para crash.
8. Rodar SFC como primeira etapa
Primeiro descubra quem falhou.
9. Rodar DISM para qualquer aplicativo
DISM não corrige automaticamente plugins ou perfis.
10. Formatar o Windows
É uma medida extrema.
11. Ignorar o horário da falha
O horário permite correlacionar eventos.
12. Ignorar Faulting Module
Ele pode fornecer uma pista importante.
13. Tratar Faulting Module como culpado definitivo
Também é erro.
14. Ignorar a versão do aplicativo
Uma atualização pode mudar completamente o diagnóstico.
15. Alterar várias coisas simultaneamente
Você perde a capacidade de saber o que resolveu.
16. Desativar segurança permanentemente
Não é diagnóstico adequado.
17. Apagar AppData inteiro
Pode destruir configurações e dados desnecessariamente.
18. Gerar dezenas de dumps sem objetivo
Mais dados não significam automaticamente melhor diagnóstico.
19. Ignorar diferenças entre usuários
O teste de perfil pode ser decisivo.
20. Não tentar reproduzir a falha
Uma falha reproduzível é muito mais fácil de investigar.
15 mitos sobre WerFault.exe
Mito 1 — WerFault.exe é vírus
O executável legítimo faz parte do Windows.
Mito 2 — WerFault.exe causa os crashes
Frequentemente ele aparece em resposta a uma falha.
Mito 3 — Posso desativá-lo para impedir programas de travar
Isso não corrige a causa do crash.
Mito 4 — ntdll.dll no evento significa ntdll corrompida
Não necessariamente.
Mito 5 — KERNELBASE.dll significa Windows corrompido
Também não.
Mito 6 — 0xc0000005 sempre significa RAM ruim
Não.
Mito 7 — qualquer ACCESS DENIED no ProcMon é a causa
Não.
Mito 8 — qualquer NAME NOT FOUND é arquivo ausente obrigatório
Não.
Mito 9 — SFC corrige qualquer crash
Não.
Mito 10 — DISM reinstala o programa problemático
Não.
Mito 11 — CHKDSK corrige DLL
Não é essa sua função.
Mito 12 — reinstalar o programa sempre remove todas as configurações
Muitos programas mantêm dados no perfil.
Mito 13 — se reinstalar Windows resolveu, descobrimos a causa
Não. Apenas removemos muitas variáveis.
Mito 14 — todo dump pode ser compartilhado publicamente
Não. Dumps podem conter dados da memória do processo.
Mito 15 — o Gerenciador de Tarefas é suficiente para descobrir todo crash
Geralmente precisamos de logs e correlação.
FAQ — Perguntas frequentes sobre WerFault.exe
1. O que é WerFault.exe?
É um executável legítimo relacionado ao Windows Error Reporting.
2. O que significa WER?
Windows Error Reporting.
3. WerFault.exe faz parte do Windows 11?
Sim.
4. WerFault.exe é malware?
O executável legítimo não. Arquivos maliciosos podem tentar usar nomes semelhantes, por isso caminho e assinatura importam.
5. Onde fica o WerFault.exe legítimo?
Normalmente associado ao diretório de sistema do Windows, como C:\Windows\System32.
6. WerFault.exe causa travamentos?
Normalmente aparece como consequência de uma falha que o Windows está processando.
7. Por que ele aparece depois que um programa fecha?
Porque o Windows pode iniciar a infraestrutura WER para tratar e registrar a falha.
8. Posso finalizar WerFault.exe?
Finalizar o processo não corrige o aplicativo que está falhando.
9. Por que ele volta?
Porque uma nova falha pode iniciar novamente o processamento do erro.
10. WerFault.exe pode usar CPU?
Pode durante o processamento de erros. Uso persistente merece investigação.
11. Como descubro qual programa está provocando isso?
Comece pelo Monitor de Confiabilidade e pelo Visualizador de Eventos.
12. Como abro o Monitor de Confiabilidade?
Execute:
perfmon /rel
13. Como abro o Visualizador de Eventos?
Execute:
eventvwr.msc
14. Onde procurar erros de aplicativos?
Em:
Logs do Windows > Aplicativo
15. O que é Faulting Application?
É o aplicativo associado à falha registrada.
16. O que é Faulting Module?
É o módulo onde a falha foi registrada.
17. Faulting Module é sempre o culpado?
Não.
18. O que é Exception Code?
É um código que ajuda a identificar a categoria da exceção.
19. O que significa 0xc0000005?
Normalmente está associado a uma violação de acesso.
20. 0xc0000005 significa RAM defeituosa?
Não necessariamente.
21. Pode ser bug do programa?
Sim.
22. Pode ser plugin?
Sim.
23. Pode ser driver?
Sim.
24. Pode ser memória física?
Também é uma possibilidade em determinados padrões de instabilidade.
25. O que é Fault Offset?
É um deslocamento relacionado ao ponto da falha dentro do módulo.
26. O que é AppCrash?
Uma classificação relacionada a falha de aplicativo.
27. O que é AppHang?
Refere-se a um aplicativo que deixa de responder adequadamente.
28. Crash e hang são iguais?
Não. Um crash normalmente encerra ou falha; um hang pode deixar o processo existente, porém sem resposta adequada.
29. O que é um dump?
É uma captura de informações sobre o estado do processo.
30. Para que serve um dump?
Para análises mais profundas de falhas.
31. Dump pode conter dados privados?
Sim. Ele pode conter informações presentes na memória do processo.
32. O que é MiniDump?
Um dump com conjunto mais limitado de informações.
33. O que é Full Dump?
Um dump com quantidade muito maior de dados da memória do processo.
34. Full Dump ocupa muito espaço?
Pode ocupar.
35. O que é ProcDump?
Uma ferramenta da Sysinternals utilizada para captura planejada de dumps em cenários de diagnóstico.
36. Preciso de ProcDump para todo crash?
Não.
37. O que é Process Explorer?
Uma ferramenta avançada para observar processos, módulos e outras propriedades.
38. O que é Process Monitor?
Uma ferramenta para acompanhar atividades de processos, arquivos e Registro, entre outras operações.
39. NAME NOT FOUND no ProcMon significa problema?
Não necessariamente.
40. ACCESS DENIED significa a causa?
Também não necessariamente.
41. ntdll.dll aparece no meu crash. Devo substituí-la?
Não.
42. Posso baixar ntdll.dll na internet?
Não é uma prática adequada.
43. KERNELBASE.dll aparece no erro. Windows está corrompido?
Isso sozinho não prova corrupção.
44. O aplicativo só trava ao imprimir. O que investigar?
Driver, spooler e componentes da pilha de impressão são boas áreas iniciais.
45. Só um documento trava. O programa está corrompido?
Não necessariamente. O próprio arquivo pode estar envolvido.
46. Só um usuário apresenta o problema. O que isso indica?
Configurações específicas do perfil ganham importância.
47. Outro usuário funciona. Preciso formatar?
Normalmente não seria uma primeira medida razoável.
48. O modo seguro do aplicativo funciona. O que isso sugere?
Plugins, extensões ou recursos desativados nesse modo podem estar envolvidos.
49. Desativar aceleração por hardware resolve. O que investigar?
Driver gráfico, GPU e camada de renderização.
50. Vários programas diferentes travam. O que fazer?
Amplie a investigação para sistema, drivers, memória e hardware.
51. SFC serve para WerFault.exe?
SFC verifica arquivos protegidos do Windows; não é uma ferramenta específica para WerFault.
52. Quando devo usar SFC?
Quando existem indícios de corrupção de componentes do Windows.
53. Quando usar DISM?
Quando a integridade da imagem/componentes do Windows precisa ser investigada ou reparada.
54. Quando testar RAM?
Quando o padrão de falhas aponta para instabilidade mais ampla, especialmente em vários aplicativos.
55. Quando verificar SSD?
Quando existem sintomas e eventos adicionais relacionados ao armazenamento.
56. Reinstalar aplicativo resolve?
Pode resolver problemas da instalação, mas não todos os tipos de crash.
57. Reparar é melhor que reinstalar?
Depende da causa, mas é frequentemente uma tentativa menos invasiva quando o aplicativo oferece reparo suportado.
58. WerFault.exe aparecendo sempre significa vários crashes?
Pode existir um aplicativo ou processo em segundo plano falhando repetidamente.
59. Como descobrir um crash invisível?
Use perfmon /rel e eventvwr.msc para procurar falhas no mesmo horário.
60. Qual é a regra principal para diagnosticar WerFault.exe?
Descubra primeiro qual aplicativo falhou.
Roteiro definitivo — programa fecha sozinho no Windows 11
Se um aplicativo fecha sozinho, siga esta sequência:
Programa fecha
↓
Anote o horário
↓
Abra:
perfmon /rel
↓
Encontre o aplicativo com falha
↓
Abra:
eventvwr.msc
↓
Localize o evento correspondente
↓
Anote:
Faulting Application
Faulting Module
Exception Code
↓
Pergunte:
A falha é reproduzível?
↓
Teste:
- outro arquivo;
- outro usuário;
- modo seguro;
- sem plugins;
- configuração gráfica diferente, quando aplicável.
↓
Verifique:
- atualização recente;
- driver;
- runtime;
- integração de terceiros.
↓
Se necessário:
Process Explorer
↓
Depois:
Process Monitor
↓
E somente quando realmente necessário:
Crash Dump
↓
Corrija a camada responsável
↓
Reproduza novamente o cenário
↓
Confirme que a falha desapareceu.
Conclusão
WerFault.exe é um ótimo exemplo de como o Gerenciador de Tarefas pode induzir a um diagnóstico errado quando analisamos apenas o nome de um processo.
O usuário vê um programa fechar e, logo depois, encontra WerFault.exe.
É natural imaginar:
“Encontrei o processo que causou o problema.”
Mas frequentemente aconteceu justamente o contrário.
O aplicativo falhou primeiro.
Depois, o Windows Error Reporting entrou em ação para registrar e processar informações sobre essa falha.
Por isso, o melhor diagnóstico não começa tentando remover, desativar ou finalizar WerFault.exe.
Começa perguntando:
Qual aplicativo falhou?
Depois:
Qual módulo aparece no evento?
Em seguida:
Qual código de exceção foi registrado?
E finalmente:
Em qual condição o problema acontece?
Quando combinamos o Monitor de Confiabilidade, Visualizador de Eventos, testes A/B, Process Explorer, Process Monitor e, quando realmente necessário, dumps, conseguimos transformar um simples “programa fecha sozinho” em uma investigação técnica baseada em evidências.
Também evitamos conclusões perigosamente rápidas.
ntdll.dll no relatório não significa automaticamente que a DLL está corrompida.
KERNELBASE.dll não prova que o Windows precisa ser reinstalado.
0xc0000005 não prova sozinho defeito na memória RAM.
E WerFault.exe aparecendo no Gerenciador de Tarefas não significa que ele provocou o crash.
No Windows 11, um bom diagnóstico depende menos de tentar muitas soluções e mais de descobrir qual componente falhou primeiro e em qual contexto isso aconteceu.
Seu programa fecha sozinho no Windows 11?
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores e notebooks Windows, incluindo problemas de programas que fecham sozinhos, falhas depois de atualizações, conflitos de drivers, erros de aplicativos, problemas de perfil, lentidão, impressão e outros comportamentos anormais do sistema.
O atendimento pode ser realizado por acesso remoto ou por visita técnica agendada em São Paulo.
Site: https://vmia.site
Blog técnico: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
VMIA – Manutenção e Configuração
Diagnóstico técnico com linguagem clara, investigação cuidadosa e solução direcionada à verdadeira origem do problema.
Faça um comentário