Explorador de Arquivos reinicia sozinho no Windows 11 com módulo responsável pela falha do explorer.exe identificado no Visualizador de Eventos — Diagnóstico do explorer.exe reiniciando sozinho no Windows 11 usando Visualizador de Eventos para identificar o módulo associado à falha.

75 / 100

Desenvolvido por Rank Math SEO

Pontuação de SEO

Você está navegando normalmente pelo Windows 11 quando acontece algo estranho: a barra de tarefas desaparece por alguns segundos, as janelas do Explorador de Arquivos fecham, a área de trabalho parece piscar e, logo depois, tudo volta.

Em outros casos, o problema aparece ao:

clicar com o botão direito;
abrir determinada pasta;
visualizar fotos ou vídeos;
acessar um arquivo compactado;
conectar uma unidade;
abrir o menu de contexto;
selecionar determinado arquivo.

Muitos usuários descrevem isso simplesmente como:

“O Explorador de Arquivos reiniciou sozinho.”

Na prática, uma possibilidade importante é que o processo:

explorer.exe

tenha falhado e sido iniciado novamente.

Reiniciar o computador pode fazer o sintoma desaparecer temporariamente.

Executar:

sfc /scannow

também aparece em praticamente todo tutorial sobre o assunto.

Mas existe uma pergunta muito mais importante:

por que o explorer.exe caiu?

E, principalmente:

qual módulo estava envolvido quando a falha aconteceu?

O Windows pode registrar informações capazes de transformar um problema aparentemente aleatório em algo investigável:

explorer.exe
↓
falha
↓
evento registrado
↓
Faulting Module
↓
DLL ou componente
↓
programa relacionado
↓
causa provável

Neste guia, vamos investigar isso usando recursos como:

Monitor de Confiabilidade;
Visualizador de Eventos;
Application Error;
Windows Error Reporting;
módulo com falha;
código de exceção;
Process Explorer;
Autoruns;
Process Monitor;
extensões do shell;
dumps de processo;
ProcDump;
Windows Performance Recorder e outras ferramentas quando realmente necessárias.

O objetivo não é apenas fazer o Explorer voltar.

É descobrir quem o derrubou.

Primeiro: o que é explorer.exe?

Muita gente associa explorer.exe apenas às janelas utilizadas para navegar por:

C:\

Documentos, Downloads, Imagens e outras pastas.

Mas o Windows Explorer participa de vários elementos da interface gráfica do Windows.

Ele está relacionado, entre outras coisas, a:

Explorador de Arquivos;
área de trabalho;
barra de tarefas;
integração do shell;
menus de contexto;
manipulação de determinados elementos da interface.

Por isso, quando explorer.exe apresenta uma falha, o sintoma pode parecer maior do que simplesmente uma janela que fechou.

Você pode observar:

barra de tarefas desaparece
↓
área de trabalho pisca
↓
Explorer fecha
↓
segundos depois tudo reaparece

Isso pode indicar que o processo terminou e foi iniciado novamente.

Explorer reiniciar não significa necessariamente que o Windows inteiro travou

Essa distinção é fundamental.

Se o computador continua:

reproduzindo áudio;
executando programas;
conectado à Internet;
respondendo normalmente;

mas a interface do Explorer desaparece e retorna, podemos estar diante de uma falha específica do shell.

Isso é diferente de:

tela azul;
reinicialização completa;
congelamento total;
desligamento inesperado.

Cada sintoma exige investigação diferente.

Por que o Explorer pode falhar?

Existem várias possibilidades.

Entre elas:

bug no próprio Windows;
DLL defeituosa;
extensão do shell de terceiros;
menu de contexto problemático;
software de compactação;
cliente de nuvem;
antivírus;
ferramenta de backup;
codec;
manipulador de miniaturas;
preview handler;
driver;
arquivos de sistema corrompidos;
componente incompatível;
aplicação que se integra ao Explorer.

A lista é grande.

É justamente por isso que não devemos começar desinstalando programas aleatoriamente.

Precisamos encontrar evidências.

O que significa “módulo com falha”?

Quando um aplicativo falha, o Windows pode registrar qual módulo estava associado à exceção.

Esse módulo pode aparecer como:

Faulting module name

ou, em português, algo semelhante a:

Nome do módulo com falha

Imagine um registro simplificado:

Faulting application name: explorer.exe
Faulting module name: exemplo.dll
Exception code: 0xc0000005

Agora temos três informações extremamente importantes:

aplicativo
↓
explorer.exe

módulo
↓
exemplo.dll

exceção
↓
0xc0000005

Isso é muito melhor do que:

“O Explorer trava de vez em quando.”

O módulo com falha é automaticamente o culpado?

Não.

Essa é uma das observações mais importantes deste artigo.

Se o evento mostra:

exemplo.dll

isso significa que aquela DLL aparece no contexto da falha.

Mas isso não prova automaticamente que ela contém o defeito original.

Uma corrupção de memória provocada anteriormente por outro componente, por exemplo, pode se manifestar mais tarde em outro módulo.

Portanto:

Faulting Module é uma pista muito forte, não uma sentença definitiva.

Precisamos correlacionar outras evidências.

Primeira ferramenta: Monitor de Confiabilidade

Uma das formas mais simples de começar a investigação é usar o Monitor de Confiabilidade.

Pressione:

Win + R

e execute:

perfmon /rel

O Windows abrirá o histórico de confiabilidade.

Essa interface apresenta uma linha do tempo com eventos como:

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

Procure o momento exato em que o Explorer reiniciou

Se você percebeu a falha às:

14:32

procure eventos próximos desse horário.

Você pode encontrar algo relacionado ao:

Windows Explorer

ou:

explorer.exe

Abra os detalhes técnicos.

Dependendo do evento, podem existir informações como:

Nome do aplicativo com falha
explorer.exe

Versão do aplicativo
...

Nome do módulo com falha
...

Código de exceção
...

Caminho do aplicativo
C:\Windows\explorer.exe

Esse registro já pode mudar completamente a investigação.

Exemplo: DLL de terceiro aparece no módulo com falha

Imagine que o evento mostre:

Aplicativo:
explorer.exe

Módulo:
empresaXYZShell.dll

Agora surge uma pergunta:

qual programa instalou empresaXYZShell.dll?

Talvez seja:

compactador;
programa de nuvem;
antivírus;
software de backup;
gerenciador de arquivos;
programa gráfico.

Se o problema começou depois da instalação ou atualização desse programa, a correlação fica ainda mais interessante.

O histórico ajuda a encontrar quando o problema começou

Não olhe apenas o evento mais recente.

Observe a linha do tempo.

Imagine:

01/09 → nenhuma falha
02/09 → programa X atualizado
03/09 → primeira falha do Explorer
04/09 → 5 falhas
05/09 → 8 falhas

Isso não prova causalidade.

Mas cria uma hipótese muito melhor do que simplesmente reinstalar o Windows.

Falha sempre no mesmo horário também é uma pista

Imagine:

12:00 → Explorer cai
18:00 → Explorer cai

todos os dias.

Talvez exista:

backup;
sincronização;
atualização;
tarefa agendada;
varredura;
outro processo periódico.

O horário pode revelar padrões.

Segunda ferramenta: Visualizador de Eventos

O Monitor de Confiabilidade é excelente para começar.

Mas o Visualizador de Eventos oferece detalhes adicionais.

Pressione:

Win + R

e execute:

eventvwr.msc

Depois navegue até:

Logs do Windows
↓
Aplicativo

Agora procure eventos próximos ao horário da falha.

Application Error

Um dos eventos mais importantes nesse cenário vem da origem:

Application Error

Frequentemente associado ao Event ID:

Um evento desse tipo pode trazer informações como:

Faulting application name
Faulting application version
Faulting module name
Faulting module version
Exception code
Fault offset
Faulting process id
Faulting application start time
Faulting application path
Faulting module path
Report Id

Esses dados são extremamente úteis.

O caminho do módulo é tão importante quanto o nome

Imagine:

Faulting module name:
exemplo.dll

Não pare aí.

Veja também:

Faulting module path:
C:\Program Files\Empresa\Programa\exemplo.dll

Agora sabemos que o módulo provavelmente está relacionado a um software instalado.

Compare com:

C:\Windows\System32\alguma.dll

O contexto muda.

DLL em System32 significa que o Windows é culpado?

Não necessariamente.

Esse é outro erro comum.

Imagine que o evento mostre:

ntdll.dll

como módulo com falha.

Muitos usuários pesquisam o nome e concluem:

“Minha ntdll.dll está corrompida.”

Essa conclusão pode estar errada.

ntdll.dll participa de enorme quantidade de operações do Windows.

Uma falha pode se manifestar nela mesmo que outro componente tenha causado o problema anteriormente.

O mesmo cuidado vale para módulos centrais do sistema.

Módulo de terceiro costuma ser uma pista mais específica

Se repetidamente encontramos:

C:\Program Files\Fabricante\Programa\shell-extension.dll

associado à falha do Explorer, a investigação ganha direção.

Especialmente se:

sempre aparece a mesma DLL;
o erro ocorre ao clicar com botão direito;
a DLL pertence a uma extensão do shell;
desativar aquela integração faz o problema desaparecer.

Agora temos várias evidências convergentes.

O código de exceção também importa

O evento pode mostrar algo como:

Exception code: 0xc0000005

Esse código é frequentemente associado a uma violação de acesso.

Em termos simplificados, algum código tentou realizar uma operação de memória que não era válida naquele contexto.

Mas cuidado:

0xc0000005

não identifica sozinho qual programa causou a falha.

Ele descreve o tipo de exceção.

Precisamos correlacioná-lo com:

módulo;
caminho;
horário;
ação realizada;
repetição;
dump.

Não pesquise apenas o código de exceção no Google

Pesquisar:

0xc0000005 explorer.exe

pode retornar milhares de causas diferentes.

Isso acontece porque o mesmo código aparece em muitos cenários.

É muito melhor pesquisar um conjunto de informações:

explorer.exe
+
nome-do-modulo.dll
+
0xc0000005

Mesmo assim, o diagnóstico local continua sendo mais importante.

Windows Error Reporting

Além do Application Error, o Windows pode registrar informações através do Windows Error Reporting, conhecido como WER.

Eventos relacionados podem conter:

nome do evento;
aplicativo;
versão;
módulo;
parâmetros;
identificador do relatório.

Esses registros ajudam a complementar a investigação.

Event ID 1000 e Event ID 1001

Em muitos casos, você encontrará eventos próximos como:

Application Error
Event ID 1000

Windows Error Reporting
Event ID 1001

Eles podem representar partes diferentes do registro da mesma falha.

Não trate cada evento como um problema independente automaticamente.

Compare:

horário;
PID;
aplicativo;
Report ID.

Monte uma pequena tabela de falhas

Se o problema acontece várias vezes, documente.

Por exemplo:

Horário	Ação	Módulo	Exceção
10:14	botão direito	exemplo.dll	0xc0000005
11:27	botão direito	exemplo.dll	0xc0000005
14:02	botão direito	exemplo.dll	0xc0000005

Esse padrão é muito forte.

Compare com:

Horário	Ação	Módulo	Exceção
10:14	abrir pasta	ntdll.dll	0xc0000005
11:27	vídeo	combase.dll	diferente
14:02	desktop	outro.dll	diferente

O segundo cenário exige investigação mais ampla.

O problema acontece ao clicar com o botão direito?

Esse é um cenário clássico para investigar extensões do shell.

Quando você clica com o botão direito, programas instalados podem adicionar opções ao menu de contexto.

Por exemplo:

Compactar
Verificar com antivírus
Enviar para nuvem
Compartilhar
Abrir com programa X
Backup

Muitas dessas opções não pertencem diretamente ao núcleo do Explorer.

São integrações adicionadas por outros softwares.

O que é uma extensão do shell?

O shell do Windows permite que programas se integrem ao Explorador.

Essas integrações podem adicionar ou modificar comportamentos relacionados a:

menus de contexto;
ícones;
propriedades;
miniaturas;
visualizações;
arrastar e soltar;
outros recursos.

Isso é extremamente útil.

Mas existe uma consequência:

código de terceiros pode executar dentro ou em associação estreita com a experiência do Explorer.

Se esse componente apresenta um defeito, o Explorer pode sofrer junto.

Exemplo simples

Você instala um compactador.

Ele adiciona:

Botão direito
↓
Compactar arquivo
↓
Extrair aqui
↓
Adicionar ao arquivo...

Para fazer isso, o software integra componentes ao shell.

Se uma versão problemática dessa integração falha, o sintoma pode aparecer exatamente quando você abre o menu de contexto.

Por isso o gatilho da falha é tão importante

Pergunte:

O que você estava fazendo exatamente um segundo antes do Explorer reiniciar?

Respostas úteis:

cliquei com o botão direito;
abri Downloads;
selecionei um vídeo;
conectei um HD;
abri uma pasta do OneDrive;
extraí um ZIP;
cliquei em Propriedades;
abri uma pasta de rede.

Essa informação pode ser tão importante quanto o Event Viewer.

O Explorer cai apenas em uma pasta?

Isso também muda o diagnóstico.

Imagine:

C:\Documentos
→ funciona

C:\Fotos
→ funciona

C:\Videos\Camera
→ Explorer cai

Agora podemos suspeitar de algo específico naquele conteúdo.

Talvez:

arquivo problemático;
miniatura;
codec;
metadata handler;
extensão;
preview handler.

Teste mudando o modo de exibição

Se uma pasta de vídeos derruba o Explorer, tente acessar sem painel de visualização e usando uma visualização que reduza a dependência de miniaturas.

Se o comportamento mudar, temos uma pista.

Não é prova definitiva, mas ajuda a isolar o gatilho.

Miniaturas podem envolver componentes adicionais

Para exibir uma miniatura, o Windows precisa interpretar alguma informação do arquivo.

Arquivos de:

vídeo;
foto;
PDF;
formatos especializados;

podem envolver componentes próprios do Windows ou instalados por terceiros.

Se determinado componente falha ao processar um arquivo específico, o Explorer pode apresentar problemas.

Um único arquivo pode derrubar o Explorer?

Pode acontecer.

Imagine uma pasta com 500 vídeos.

Você abre a pasta.

O Explorer começa a gerar miniaturas.

Quando chega a:

video-problematico.mkv

um componente responsável pela leitura do formato falha.

O Explorer reinicia.

Você abre novamente.

A mesma sequência acontece.

Isso cria a impressão:

“Essa pasta está corrompida.”

Mas talvez exista apenas um arquivo ou manipulador específico acionando a falha.

Process Explorer ajuda a entender o que está carregado

O Process Explorer, da Microsoft Sysinternals, permite investigar processos de forma muito mais detalhada que o Gerenciador de Tarefas.

Podemos observar:

caminho;
processo pai;
propriedades;
DLLs carregadas;
assinaturas;
threads;
handles.

No contexto deste artigo, uma das perguntas é:

quais módulos de terceiros estão associados ao Explorer?

DLL carregada não significa DLL culpada

Essa regra precisa ficar clara.

Se o Process Explorer mostra 30 DLLs de terceiros associadas ao ambiente do Explorer, não significa que todas são suspeitas.

Muito menos que devemos apagar essas DLLs.

A lista serve para criar hipóteses.

O ideal é correlacionar com o evento de falha.

Exemplo de correlação forte

Visualizador de Eventos:

Faulting module:
cloudshell.dll

Process Explorer:

explorer.exe
↓
cloudshell.dll
↓
C:\Program Files\CloudApp\

Sintoma:

Explorer cai quando clico com botão direito em arquivo sincronizado

Programa:

CloudApp atualizado ontem

Agora temos várias pistas apontando para o mesmo componente.

Isso justifica testar a integração daquele programa.

Autoruns pode ajudar a investigar extensões do Explorer

Outra ferramenta da Microsoft Sysinternals muito útil é o Autoruns.

Ela mostra vários pontos de inicialização e integração do Windows.

Entre suas categorias existe conteúdo relacionado ao Explorer.

Dependendo da versão, podemos encontrar integrações e extensões que participam do shell.

Isso ajuda a identificar componentes de terceiros.

Não saia desmarcando tudo no Autoruns

O Autoruns é extremamente poderoso.

A estratégia correta é:

identificar suspeito
↓
documentar
↓
desativar componente específico
↓
reiniciar Explorer ou sessão quando necessário
↓
reproduzir teste

Não:

desmarcar 40 itens
↓
problema some
↓
não saber qual era o culpado

Diagnóstico exige isolamento controlado.

Método de metade pode acelerar investigações

Quando existem muitas extensões de terceiros e nenhuma pista clara, podemos utilizar uma abordagem sistemática.

Por exemplo:

20 extensões suspeitas
↓
desabilitar 10
↓
testar

Se o problema continuar:

culpado provavelmente está nas outras 10

Se desaparecer:

culpado provavelmente está nas 10 desabilitadas

Depois dividimos novamente.

Esse método reduz rapidamente o conjunto.

Mas registre tudo que foi alterado.

Priorize componentes de terceiros

Em uma investigação de extensões do shell, normalmente faz sentido começar pelas integrações adicionadas por programas de terceiros.

Não desative componentes Microsoft aleatoriamente.

A ideia é reduzir risco e aumentar a qualidade do teste.

ShellExView pode aparecer em muitos tutoriais

Existe também uma ferramenta conhecida chamada ShellExView, utilizada para visualizar extensões do shell.

Ela pode ser útil nesse tipo de diagnóstico.

Porém, para um procedimento VMIA, podemos combinar principalmente:

Monitor de Confiabilidade
+
Visualizador de Eventos
+
Process Explorer
+
Autoruns

e recorrer a outras ferramentas quando necessário.

SFC deve ser executado imediatamente?

Nem sempre.

O comando:

sfc /scannow

é útil para verificar e reparar determinados arquivos protegidos do Windows.

Mas imagine:

Explorer cai somente ao clicar com botão direito
↓
Event Viewer aponta sempre para DLL de terceiro
↓
desativar extensão elimina problema

Nesse cenário, SFC dificilmente seria o centro do diagnóstico.

Quando SFC faz mais sentido?

Quando existem indícios de problemas nos componentes protegidos do Windows ou corrupção do sistema.

Podemos executar:

sfc /scannow

e analisar o resultado.

Mas não use SFC como substituto para investigar uma DLL de terceiro claramente correlacionada.

E o DISM?

Outro comando frequentemente recomendado é:

DISM /Online /Cleanup-Image /RestoreHealth

Ele pode ser útil em cenários envolvendo integridade da imagem/component store do Windows.

Novamente:

DISM não diagnostica extensão defeituosa de menu de contexto.

Use cada ferramenta para o problema que ela realmente consegue investigar.

Reinstalar o Windows deveria ser a primeira solução?

Quase nunca nesse cenário.

Se conseguimos reproduzir:

botão direito
↓
explorer.exe cai
↓
mesma DLL de terceiro aparece

reinstalar o Windows inteiro antes de testar aquela integração seria desproporcional.

Além disso, se depois você reinstalar o mesmo software defeituoso, o problema pode voltar.

Atualização do Windows pode estar relacionada?

Pode.

Se o problema começou imediatamente depois de uma atualização, registre essa informação.

Mas cuidado com a conclusão:

atualização aconteceu ontem
+
problema apareceu hoje
=
Windows Update culpado

Isso é apenas correlação temporal.

No mesmo período também podem ter sido atualizados:

drivers;
programas;
antivírus;
extensões;
codecs;
clientes de nuvem.

Precisamos verificar os eventos.

Atualizações de programas também importam

Muitos programas atualizam silenciosamente.

Se uma extensão do shell começou a falhar, talvez o Windows não tenha mudado.

Quem mudou foi o software integrado ao Explorer.

O Monitor de Confiabilidade pode ajudar a observar instalações e alterações próximas ao início do problema.

Reiniciar explorer.exe é solução ou diagnóstico?

Depende.

Você pode reiniciar o Explorer pelo Gerenciador de Tarefas.

Isso restaura a interface em muitos casos.

Mas se o processo está caindo sozinho, reiniciá-lo manualmente não explica a origem.

Considere isso uma recuperação temporária.

Primeira árvore de diagnóstico

Até aqui, podemos organizar o problema:

Explorer reinicia sozinho
↓
confirmar se explorer.exe realmente falhou
↓
perfmon /rel
↓
evento do Windows Explorer
↓
eventvwr.msc
↓
Application Error
↓
Faulting Module
↓
módulo Microsoft ou terceiro?
↓
qual caminho?
↓
qual ação disparou?
↓
problema é reproduzível?

Se existir uma DLL de terceiro:

identificar programa
↓
verificar versão/atualização
↓
investigar extensão
↓
desabilitar de forma controlada
↓
reproduzir

Essa metodologia já é muito superior a simplesmente executar uma coleção de comandos aleatórios.

Antes de continuar, anote cinco informações

Na próxima vez que o Explorer reiniciar, registre:

1. Horário exato

Exemplo:

14:37:22

2. O que você estava fazendo

Exemplo:

clicando com botão direito em um arquivo MKV

3. Pasta

Exemplo:

D:\Videos

4. Módulo com falha

Exemplo:

exemplo.dll

5. Código de exceção

Exemplo:

0xc0000005

Com essas cinco informações, uma falha aparentemente aleatória começa a deixar rastros.

O diagnóstico começa antes da solução

A maior diferença entre um diagnóstico técnico e uma tentativa genérica é preservar as evidências.

Se imediatamente:

reiniciamos
↓
desinstalamos vários programas
↓
limpamos registros
↓
desabilitamos serviços

podemos eliminar temporariamente o sintoma sem descobrir a causa.

O objetivo aqui será seguir o caminho contrário:

reproduzir
↓
registrar
↓
correlacionar
↓
isolar
↓
confirmar
↓
corrigir

Como isolar o módulo, DLL ou extensão do shell que está derrubando o explorer.exe

Na primeira parte, estabelecemos uma regra importante: quando o Explorador de Arquivos reinicia sozinho, não devemos começar tentando “consertar o Windows”.

Primeiro precisamos confirmar se houve realmente uma falha do:

explorer.exe

e preservar as evidências.

Nosso fluxo inicial ficou assim:

Explorer desaparece e volta
↓
Monitor de Confiabilidade
↓
Visualizador de Eventos
↓
Application Error
↓
Faulting Module
↓
código de exceção
↓
ação que provocou a falha

Agora podemos avançar.

O objetivo desta parte é transformar informações como:

explorer.exe
0xc0000005
exemplo.dll

em uma hipótese que possa ser testada.

Event ID 1000: comece pelo horário, não pelo nome da DLL

Abra o Visualizador de Eventos:

eventvwr.msc

Acesse:

Logs do Windows
↓
Aplicativo

Localize eventos próximos ao horário exato em que o Explorer desapareceu.

Um evento da origem:

Application Error

pode trazer informações sobre a falha.

O Event ID 1000 aparece com frequência em falhas de aplicativos, mas não devemos procurar simplesmente “qualquer evento 1000”.

Precisamos correlacionar:

horário
+
explorer.exe
+
PID
+
módulo
+
exceção

Como interpretar um evento de falha

Imagine um registro simplificado:

Faulting application name: explorer.exe
Faulting application path: C:\Windows\explorer.exe

Faulting module name: exemploShell.dll
Faulting module path:
C:\Program Files\Exemplo\exemploShell.dll

Exception code: 0xc0000005
Faulting process id: 0x2A80

Não precisamos adivinhar aleatoriamente.

Temos uma cadeia:

explorer.exe
↓
exemploShell.dll
↓
C:\Program Files\Exemplo\
↓
software Exemplo

Agora podemos descobrir qual programa instalou aquela DLL.

O caminho do módulo costuma ser mais útil que o nome

DLLs podem ter nomes pouco esclarecedores.

Exemplo:

abcctx64.dll

O nome sozinho pode não dizer nada.

Mas:

C:\Program Files\FabricanteX\ProdutoY\abcctx64.dll

já oferece uma direção muito melhor.

Por isso, registre:

nome do módulo;
caminho completo;
versão;
horário;
código de exceção.

Pesquise as propriedades do arquivo

Depois de localizar a DLL, podemos verificar suas propriedades.

No Explorador:

botão direito → Propriedades → Detalhes

Procure informações como:

descrição;
nome do produto;
empresa;
versão;
copyright.

Também verifique:

Assinaturas Digitais

quando disponíveis.

Isso ajuda a associar o módulo ao fabricante correto.

Assinatura digital não significa que o módulo não possa ter bugs

Uma DLL corretamente assinada pode ser legítima e ainda assim apresentar:

bug;
incompatibilidade;
problema após atualização;
conflito com outro componente.

A assinatura responde principalmente a questões de identidade e integridade do código assinado.

Ela não certifica ausência de bugs.

DLL sem assinatura é automaticamente malware?

Também não.

Existem programas legítimos que podem incluir componentes não assinados.

A ausência de assinatura aumenta a necessidade de investigar origem e contexto, mas não permite concluir:

“Essa DLL é um vírus.”

Analise:

caminho
+
fabricante
+
programa instalado
+
comportamento
+
histórico

PowerShell pode ajudar a verificar a assinatura

Se conhecemos o caminho:

Get-AuthenticodeSignature "C:\Program Files\Exemplo\exemploShell.dll"

O resultado pode ajudar a verificar o estado da assinatura.

Novamente, isso faz parte da identificação, não determina sozinho a causa da falha.

Como obter informações do arquivo pelo PowerShell

Podemos consultar informações básicas:

Get-Item "C:\Program Files\Exemplo\exemploShell.dll" | Format-List *

E informações de versão:

(Get-Item "C:\Program Files\Exemplo\exemploShell.dll").VersionInfo

Isso pode revelar:

CompanyName
FileDescription
FileVersion
ProductName
ProductVersion

quando essas informações estão presentes.

E se o módulo com falha for ntdll.dll?

Esse é um dos cenários que mais gera diagnósticos errados.

Você encontra:

Faulting module name: ntdll.dll

e conclui:

“Preciso baixar outra ntdll.dll.”

Não faça isso.

ntdll.dll é um componente central do Windows.

Uma exceção pode terminar sendo registrada nesse módulo sem que ele seja necessariamente a origem do problema.

Não baixe DLLs individuais de sites aleatórios.

O mesmo cuidado vale para KERNELBASE.dll

Outro nome que pode aparecer em falhas é:

KERNELBASE.dll

Novamente, a presença desse módulo não prova automaticamente corrupção daquele arquivo.

Quando módulos centrais aparecem, precisamos observar mais atentamente:

padrão das falhas;
módulos carregados;
extensão do shell;
código de exceção;
dump;
comportamento reproduzível.

O módulo muda em todas as falhas?

Essa informação é importante.

Cenário A

Dez falhas:

Falha 1 → programaShell.dll
Falha 2 → programaShell.dll
Falha 3 → programaShell.dll
Falha 4 → programaShell.dll

Temos uma pista consistente.

Cenário B

Falha 1 → ntdll.dll
Falha 2 → KERNELBASE.dll
Falha 3 → combase.dll
Falha 4 → outro componente

Agora o diagnóstico pode exigir uma análise mais ampla.

O código 0xc0000005

Uma das exceções mais conhecidas é:

0xc0000005

Ela normalmente está relacionada a uma violação de acesso à memória.

Em termos simplificados:

código tentou acessar memória
↓
operação não era válida naquele contexto
↓
exceção

Mas esse código não informa:

“a RAM está com defeito”

nem:

“a DLL exibida está corrompida”

sozinho.

Precisamos do contexto.

RAM defeituosa pode causar falhas?

Pode.

Problemas físicos de memória podem gerar comportamento instável e falhas em aplicações.

Mas se:

Explorer cai apenas ao clicar com botão direito
+
sempre aparece a mesma extensão de terceiro

começar trocando memória RAM seria uma investigação ruim.

Por outro lado, se vários programas diferentes falham aleatoriamente em módulos diferentes, a hipótese de instabilidade sistêmica ganha mais importância.

Um bom diagnóstico compara o Explorer com outros aplicativos

Pergunte:

Só o explorer.exe está falhando?

Se:

explorer.exe
chrome.exe
winword.exe
outlook.exe
outros programas

estão falhando aleatoriamente, talvez o problema seja maior que uma extensão do Explorer.

Mas se apenas:

explorer.exe

cai sempre durante a mesma ação, concentre-se primeiro no shell.

Menu de contexto: um dos melhores testes

Suponha que o usuário diga:

“O Explorer reinicia quando clico com o botão direito em qualquer arquivo.”

Isso é uma informação excelente.

O menu de contexto pode incluir extensões adicionadas por programas de terceiros.

Podemos ter:

Explorer
↓
clique direito
↓
carrega integração
↓
DLL problemática
↓
exceção
↓
explorer.exe termina

Agora precisamos descobrir qual extensão.

Autoruns: investigando integrações do Explorer

O Autoruns, da Microsoft Sysinternals, permite visualizar muitos componentes configurados para iniciar ou integrar-se ao Windows.

Para este problema, a área relacionada ao Explorer é particularmente interessante.

Podem existir itens ligados a:

shell extensions;
context menu handlers;
icon overlays;
componentes auxiliares;
integrações de programas.

O objetivo é localizar componentes de terceiros que façam sentido no contexto da falha.

Use “Hide Microsoft Entries” com critério

Uma estratégia muito útil no Autoruns é reduzir o ruído visual e concentrar a investigação em componentes que não pertencem à Microsoft.

Isso facilita responder:

“Quais programas de terceiros estão integrados ao Explorer?”

Mas não interprete automaticamente:

não Microsoft = problema

A maioria dessas integrações pode ser perfeitamente legítima.

Procure o fabricante encontrado no Event Viewer

Se o evento mostrou:

C:\Program Files\FabricanteX\

procure entradas relacionadas ao mesmo fabricante no Autoruns.

Essa correlação é muito mais eficiente que desativar itens aleatoriamente.

Desativar é melhor que apagar

Durante diagnóstico, prefira uma alteração reversível.

Em vez de:

apagar DLL

ou:

excluir chave do Registro

prefira desativar temporariamente a integração através de uma ferramenta apropriada quando possível.

Depois:

reiniciar Explorer
↓
reproduzir problema
↓
observar resultado

Se o problema desaparecer, temos uma evidência importante.

Como reiniciar o Explorer durante o teste

Abra:

Ctrl + Shift + Esc

No Gerenciador de Tarefas, localize:

Windows Explorer

e escolha:

Reiniciar

A barra de tarefas pode desaparecer brevemente.

Depois, reproduza exatamente o mesmo procedimento que causava a falha.

O teste precisa ser reproduzível

Imagine:

antes:
10 cliques com botão direito
→ 10 falhas

Desativamos a extensão suspeita.

Depois:

10 cliques
→ nenhuma falha

Essa evidência é muito melhor do que:

“Parece que melhorou.”

Reative para confirmar?

Em ambiente controlado e quando o risco é baixo, um teste de confirmação pode ser útil.

Exemplo:

extensão ativa
→ falha

extensão desativada
→ funciona

extensão reativada
→ falha retorna

Essa sequência aumenta bastante a confiança na hipótese.

Mas não repita deliberadamente uma falha se houver risco de perda de dados ou instabilidade relevante.

Atualizar o programa pode ser melhor que removê-lo

Se identificamos que uma extensão pertence a um programa legítimo, verifique se existe uma versão corrigida.

A solução pode ser:

versão antiga
↓
bug na shell extension
↓
atualização
↓
versão corrigida

Não é necessário abandonar o programa automaticamente.

Reinstalar o programa também pode ajudar?

Pode, especialmente se a instalação estiver incompleta ou inconsistente.

Mas a sequência mais inteligente é:

identificar componente
↓
confirmar relação
↓
verificar atualização
↓
reparar/reinstalar se apropriado

em vez de reinstalar dez programas sem evidência.

O problema ocorre apenas ao clicar em arquivos compactados?

Programas de compactação frequentemente adicionam opções ao menu de contexto.

Por exemplo:

Extrair aqui
Adicionar ao arquivo
Compactar
Abrir

Se o Explorer cai apenas ao interagir com:

.zip
.rar
.7z

investigue:

compactador instalado;
extensão do shell;
versão;
tipo específico de arquivo.

Explorer cai ao selecionar vídeo

Outro cenário:

abrir pasta
↓
selecionar arquivo MKV
↓
Explorer reinicia

Agora o menu de contexto talvez nem esteja envolvido.

Podemos estar lidando com:

thumbnail handler;
property handler;
preview handler;
codec;
componente de metadados.

Primeiro teste: desative o Painel de Visualização

Se o Explorer cai ao selecionar o arquivo, desative temporariamente o painel de visualização.

Depois repita.

Se:

Preview ON
→ falha

Preview OFF
→ funciona

temos uma pista importante.

Segundo teste: elimine temporariamente as miniaturas da equação

Mude o modo de exibição para uma configuração menos dependente de miniaturas e observe o comportamento.

Se o Explorer deixa de falhar, podemos concentrar a investigação nos componentes responsáveis pela representação daquele formato.

O arquivo pode ser o gatilho sem estar “corrompido”?

Sim.

Um arquivo perfeitamente válido pode conter alguma combinação de metadados ou características que expõe um bug em determinado codec ou handler.

Portanto:

arquivo provoca falha

não significa automaticamente:

arquivo está corrompido

Teste o mesmo arquivo em outro computador

Esse teste pode ser bastante útil.

PC A

arquivo.mkv
→ Explorer cai

PC B

mesmo arquivo
→ funciona normalmente

Isso aumenta a suspeita de diferença no ambiente do PC A:

codec;
extensão;
software;
versão;
configuração.

Teste outros arquivos do mesmo tipo

Se:

arquivo1.mkv → falha
arquivo2.mkv → falha
arquivo3.mkv → falha

podemos suspeitar do tratamento do formato.

Mas se:

arquivo1.mkv → funciona
arquivo2.mkv → funciona
arquivo3.mkv → falha

o arquivo específico ganha relevância.

PDFs também merecem esse tipo de comparação

Um programa pode instalar:

preview handler;
thumbnail handler;
integração de menu;
propriedades.

Se selecionar PDFs faz o Explorer reiniciar, compare:

todos os PDFs?

ou:

somente um PDF?

apenas com Painel de Visualização?

Essas pequenas perguntas reduzem muito o espaço de busca.

Explorer cai ao acessar pasta do OneDrive

Clientes de nuvem possuem integração profunda com o Explorer.

Eles podem adicionar:

ícones de status;
menus;
sincronização;
Files On-Demand;
ações de compartilhamento.

Se o problema ocorre apenas dentro de:

C:\Users\Usuario\OneDrive\

registre isso.

Depois compare com uma pasta local comum.

Faça um teste A/B

Exemplo:

C:\Teste\arquivo.docx
→ funciona

C:\Users\Usuario\OneDrive\Teste\arquivo.docx
→ Explorer cai

Isso não prova que o OneDrive seja culpado, mas mostra que o contexto da pasta sincronizada importa.

Outros clientes de nuvem também podem integrar-se ao Explorer

O mesmo raciocínio vale para outros programas de sincronização.

Não associe automaticamente qualquer falha de pasta em nuvem ao Windows.

Identifique quais componentes estão integrados.

Explorer cai ao conectar um HD ou pendrive

Esse cenário exige outra abordagem.

Imagine:

conectar HD USB
↓
Explorer abre unidade
↓
Explorer reinicia

Podemos ter:

arquivo problemático;
miniatura;
extensão;
sistema de arquivos;
erro de leitura;
dispositivo;
driver.

Observe o Visualizador de Eventos além do log Aplicativo.

Eventos de armazenamento próximos ao horário podem ser relevantes.

Não execute CHKDSK automaticamente

Se existem arquivos importantes no dispositivo e sinais de problema de armazenamento, não comece alterando a estrutura do sistema de arquivos sem entender a condição da unidade.

Uma falha do Explorer ao acessar um disco não significa automaticamente que chkdsk /f seja a resposta.

Primeiro descubra se estamos diante de:

falha do Explorer

ou:

problema de armazenamento

ou dos dois.

Process Explorer: verificando módulos carregados

Com o Explorer funcionando, o Process Explorer pode ajudar a observar módulos associados ao processo.

Isso permite encontrar DLLs de terceiros carregadas no contexto investigado.

Procure principalmente correlações com:

Faulting Module

do Event Viewer.

Não remova DLLs manualmente

Nunca transforme:

Faulting Module = exemplo.dll

em:

del exemplo.dll

Uma DLL pode ser necessária para um programa.

Removê-la manualmente pode:

quebrar o aplicativo;
deixar referências inválidas;
causar novos erros;
dificultar desinstalação.

Trabalhe através do programa responsável ou da integração configurada.

Process Monitor entra quando precisamos observar o gatilho

O Process Monitor é útil quando queremos acompanhar o que acontece imediatamente antes da falha.

Imagine:

Explorer funciona
↓
clicamos com botão direito
↓
falha

Podemos capturar o intervalo e observar operações realizadas perto do momento da exceção.

Mas Process Monitor não é um detector automático de culpados

Ele registra enorme quantidade de atividade.

Ver:

programa.dll

alguns milissegundos antes da falha não prova causalidade.

Precisamos combinar:

ProcMon
+
Event Viewer
+
Faulting Module
+
reprodução

Quanto mais evidências apontam para o mesmo componente, melhor.

Filtros ajudam muito

Podemos filtrar por:

Process Name is explorer.exe

e analisar o período próximo à falha.

Dependendo da hipótese, também podemos filtrar:

caminho;
nome de DLL;
diretório;
operação.

O objetivo é reduzir milhões de eventos a uma sequência compreensível.

Process Monitor pode fechar junto com a falha?

O Process Monitor é um processo separado.

Portanto, a queda do Explorer não significa necessariamente perder a captura.

Isso permite analisar o que aconteceu imediatamente antes.

E se o Explorer travar sem fechar?

Esse é outro cenário.

Existe diferença entre:

crash

hang

Crash

O processo sofre uma falha e termina.

Hang

O processo continua existindo, mas deixa de responder adequadamente.

Essa distinção muda as ferramentas que podem ser mais úteis.

Monitor de Confiabilidade pode mostrar “parou de funcionar”

Uma falha pode aparecer como aplicativo que parou de funcionar.

Já um travamento pode gerar registros diferentes ou depender de como a situação termina.

Por isso, observe se:

explorer.exe desapareceu

ou se:

explorer.exe permaneceu ativo e não respondendo

Wait Chain pode ajudar em travamentos

O Windows possui mecanismos para analisar cadeias de espera em determinados processos.

No Gerenciador de Tarefas, dependendo da interface disponível, recursos relacionados à análise da cadeia de espera podem ajudar a identificar se um processo está aguardando outro.

Isso é mais útil para hangs do que para crashes instantâneos.

Crash e hang não são a mesma investigação

Podemos resumir:

Explorer termina e reinicia
↓
crash
↓
Event Viewer
Faulting Module
dump

Enquanto:

Explorer continua aberto
mas não responde
↓
hang
↓
wait chain
threads
dump de hang

Não misture os dois.

Quando o Event Viewer não é suficiente

Às vezes encontramos:

explorer.exe
ntdll.dll
0xc0000005

e nada mais esclarecedor.

Se o problema é frequente e reproduzível, podemos precisar de uma evidência muito mais poderosa:

um dump do processo no momento da falha.

O dump pode preservar informações sobre o estado do processo quando a exceção ocorreu.

Por que um dump é tão valioso?

O Event Viewer nos entrega algo semelhante a:

quem caiu
+
módulo
+
código

Um dump pode permitir investigação muito mais profunda de:

threads;
módulos;
stack;
exceção;
contexto do processo.

Essa é a ponte entre diagnóstico intermediário e análise avançada.

ProcDump pode capturar a falha

O ProcDump, da Microsoft Sysinternals, foi criado justamente para cenários de diagnóstico de processos.

Ele pode ser configurado para monitorar um processo e gerar dumps sob determinadas condições.

Para este artigo, o ponto mais importante é:

se o Explorer cai de forma reproduzível, podemos preparar a captura antes de provocar novamente o erro.

Na próxima parte veremos isso com mais cuidado.

Não compartilhe dumps indiscriminadamente

Um dump pode conter partes da memória de um processo.

Dependendo do processo e do contexto, isso pode incluir informações potencialmente sensíveis.

Portanto:

armazene com cuidado;
não publique em fóruns públicos sem avaliar;
não envie para serviços desconhecidos;
remova quando não for mais necessário.

SFC e DISM entram depois da hipótese, não antes dela

Se nenhum componente de terceiro aparece e existem sinais de corrupção do Windows, podemos investigar integridade.

Comece, quando apropriado, com:

sfc /scannow

E, dependendo do resultado e do cenário:

DISM /Online /Cleanup-Image /RestoreHealth

Mas não espere que esses comandos corrijam uma extensão defeituosa de um software de terceiro.

Uma sequência melhor que “SFC + DISM + reinicie”

Para um Explorer que reinicia ao clicar com botão direito:

1. Reproduzir.
2. Anotar horário.
3. perfmon /rel.
4. eventvwr.msc.
5. Localizar explorer.exe.
6. Anotar Faulting Module.
7. Ver caminho da DLL.
8. Identificar fabricante.
9. Verificar integração no Explorer.
10. Desativar de forma reversível.
11. Reiniciar Explorer.
12. Reproduzir.

Somente depois, se a hipótese apontar para componentes do Windows:

SFC
DISM

Essa ordem preserva muito mais informação.

Cenário prático 1 — Explorer cai no botão direito

Sintoma:

botão direito
↓
Explorer desaparece
↓
barra de tarefas volta

Event Viewer:

Faulting application: explorer.exe
Faulting module: compactadorShell.dll

Autoruns:

extensão do compactador

Teste:

desativar extensão
↓
reiniciar Explorer
↓
botão direito funciona

Hipótese fortemente confirmada.

Cenário prático 2 — Explorer cai ao selecionar MKV

Sintoma:

selecionar vídeo
↓
Explorer reinicia

Teste:

Painel de Visualização OFF
↓
problema desaparece

Agora investigamos:

preview handler;
codec;
software multimídia;
extensão relacionada.

Não começamos reinstalando o Windows.

Cenário prático 3 — apenas uma pasta causa falha

Sintoma:

C:\Fotos → OK
C:\Documentos → OK
D:\Videos\Camera → crash

Teste:

modo de detalhes;
preview desativado;
miniaturas reduzidas;
mover arquivos por outro método quando seguro;
identificar qual arquivo dispara a falha.

Isso pode revelar um conteúdo específico.

Cenário prático 4 — Explorer cai aleatoriamente em qualquer situação

Event Viewer:

módulos diferentes
exceções diferentes

Outros aplicativos também falham.

Agora ampliamos a investigação para:

estabilidade do sistema;
drivers;
memória;
armazenamento;
corrupção;
software de segurança;
problemas sistêmicos.

A hipótese de uma única shell extension perde força.

Cenário prático 5 — Explorer cai somente no OneDrive

Teste:

mesmo arquivo fora do OneDrive → OK
mesmo arquivo dentro do OneDrive → falha

Investigue:

cliente de sincronização;
integração do shell;
status do arquivo;
versão do software;
eventos relacionados.

Cenário prático 6 — módulo Microsoft aparece sempre

Se:

ntdll.dll

ou outro componente central aparece repetidamente, não conclua que aquela DLL precisa ser substituída.

Continue para:

dump;
módulos carregados;
reprodução;
integridade do Windows;
componentes de terceiros;
drivers.

Checklist de isolamento da Parte 2

Quando o Explorer reinicia:

1. Confirmar crash.
2. Registrar horário.
3. Abrir perfmon /rel.
4. Abrir eventvwr.msc.
5. Encontrar Application Error.
6. Registrar Faulting Module.
7. Registrar caminho.
8. Registrar Exception Code.
9. Identificar fabricante.
10. Ver assinatura e versão.
11. Descobrir ação que dispara.
12. Verificar extensões do shell.
13. Priorizar componentes de terceiros.
14. Desativar apenas o suspeito.
15. Reiniciar Explorer.
16. Reproduzir.
17. Confirmar se a falha desapareceu.
18. Atualizar/reparar o software responsável.
19. Se inconclusivo, capturar evidências adicionais.
20. Considerar dump.

O objetivo continua o mesmo:

não adivinhar
↓
encontrar evidência
↓
criar hipótese
↓
testar
↓
confirmar

ProcDump, dumps do explorer.exe e diagnóstico quando o módulo não entrega a causa

Até aqui, seguimos uma sequência relativamente direta:

Explorer reinicia
↓
Monitor de Confiabilidade
↓
Visualizador de Eventos
↓
Faulting Module
↓
identificar DLL
↓
correlacionar com software ou extensão

Isso funciona muito bem quando o Windows registra repetidamente uma DLL de terceiro específica.

Mas existem casos em que o evento mostra apenas algo genérico, como:

ntdll.dll

ou:

KERNELBASE.dll

ou ainda módulos diferentes em cada falha.

Nesses cenários, o Event Viewer pode não ser suficiente.

Precisamos observar o estado do explorer.exe mais de perto.

É aí que entram os dumps de processo.

O que é um dump de processo?

Um dump é uma captura do estado de um processo em determinado momento.

Dependendo do tipo de dump, ele pode preservar informações sobre:

threads;
módulos carregados;
exceção;
contexto da memória;
pilha de chamadas;
estado interno do processo.

Podemos pensar assim:

explorer.exe funcionando
↓
falha acontece
↓
dump captura o estado
↓
análise posterior

Em vez de receber apenas:

explorer.exe
+
0xc0000005
+
ntdll.dll

podemos obter evidências adicionais sobre o que estava acontecendo quando o processo falhou.

Quando vale a pena capturar um dump?

Um dump faz mais sentido quando:

o Explorer cai frequentemente;
a falha é reproduzível;
o módulo registrado é genérico;
vários módulos aparecem;
desativar extensões não resolveu;
precisamos aprofundar o diagnóstico;
o Event Viewer não explica suficientemente a origem.

Se o problema aconteceu uma única vez em seis meses, talvez não exista razão para começar imediatamente com análise de dump.

ProcDump: ferramenta da Microsoft Sysinternals

O ProcDump faz parte da suíte Microsoft Sysinternals.

Ele permite monitorar processos e gerar dumps quando determinadas condições ocorrem.

Isso é muito útil para aplicações que:

falham;
travam;
consomem CPU;
apresentam exceções;
encerram inesperadamente.

Para o nosso cenário, queremos capturar a falha do:

explorer.exe

Antes de usar ProcDump, crie uma pasta para os dumps

Podemos criar, por exemplo:

C:\Dumps

Ela servirá para armazenar os arquivos gerados durante o teste.

Evite usar uma pasta sincronizada com OneDrive para esse tipo de captura.

Além de desnecessário, dumps podem ser grandes e conter informações sensíveis.

Capturando uma falha do Explorer com ProcDump

Uma abordagem comum é monitorar o processo e solicitar dump quando ocorrer uma exceção não tratada.

Por exemplo:

procdump -e explorer.exe C:\Dumps

Dependendo da versão e do objetivo da captura, parâmetros adicionais podem ser úteis.

Um exemplo com dump mais completo:

procdump -ma -e explorer.exe C:\Dumps

O parâmetro:

-ma

solicita um dump completo.

-e

é utilizado para monitorar exceções.

Como o comportamento e as opções do ProcDump podem evoluir, vale sempre conferir a ajuda da versão utilizada:

procdump -?

ProcDump precisa estar aberto antes da falha

Essa é a lógica.

Você prepara o monitoramento:

ProcDump aguardando
↓
reproduz problema
↓
Explorer falha
↓
dump é gravado

Isso é especialmente útil quando a falha acontece ao executar uma ação específica.

Por exemplo:

1. Abrir ProcDump.
2. Começar monitoramento do explorer.exe.
3. Abrir determinada pasta.
4. Clicar com botão direito.
5. Explorer cai.
6. Dump é salvo.

Agora temos uma evidência adicional.

E se o Explorer reiniciar com outro PID?

Isso pode acontecer.

Quando o explorer.exe cai e volta, a nova instância pode receber outro PID.

Por isso, uma captura precisa ser planejada para o processo que está ativo naquele momento.

Em cenários recorrentes, talvez seja necessário reiniciar o monitoramento após a nova instância aparecer.

Dump completo ou minidump?

Existem diferenças importantes.

Um dump menor ocupa menos espaço e pode ser suficiente para certos tipos de análise.

Um dump completo oferece mais contexto, mas pode ficar muito maior.

Para um diagnóstico técnico mais profundo, um dump completo pode ser mais útil.

Mas existe um custo:

tamanho;
privacidade;
armazenamento;
tempo de análise.

Não gere dumps completos indiscriminadamente em todos os PCs.

Dump pode conter informações sensíveis

Esse cuidado é obrigatório.

Um dump captura memória de processo.

Dependendo da situação, ele pode conter partes de:

nomes de arquivos;
caminhos;
textos;
dados temporários;
informações da sessão;
outros conteúdos que estavam na memória.

Por isso:

não publique dumps em fóruns abertos sem avaliar o conteúdo.

Armazene em local controlado.

Como analisar um dump?

A ferramenta clássica para esse tipo de análise é o WinDbg, da Microsoft.

Ele permite abrir arquivos de dump e examinar informações sobre a exceção, módulos e pilhas.

Uma análise inicial pode utilizar comandos como:

!analyze -v

Em muitos casos, esse comando produz um resumo detalhado da falha.

Mas o resultado precisa ser interpretado.

`!analyze -v` não é um oráculo

É comum alguém abrir um dump, executar:

!analyze -v

e tratar a primeira DLL mencionada como culpada.

Isso pode levar ao mesmo erro que cometemos ao interpretar Faulting Module isoladamente.

A análise precisa considerar:

stack;
módulo;
função;
exceção;
contexto;
repetição;
software instalado.

O objetivo é encontrar convergência.

O que procurar em uma stack?

A pilha de chamadas mostra, em termos simplificados, a sequência de funções envolvidas naquela thread.

Imagine algo conceitual como:

explorer.exe
↓
shell32.dll
↓
programaXYZshell.dll
↓
função específica
↓
exceção

Se várias capturas mostram o mesmo módulo de terceiro próximo da exceção, a hipótese fica muito mais forte.

Exemplo de correlação com dump

Event Viewer:

Faulting Module:
ntdll.dll

Isso parece genérico.

Mas o dump mostra uma stack com:

programaBackupShell.dll

repetidamente próxima ao ponto de falha.

O problema acontece apenas quando clicamos com botão direito em arquivos.

Autoruns mostra uma shell extension do mesmo programa.

Quando desativamos a extensão:

falha desaparece

Agora temos uma investigação muito mais convincente.

E se a stack mostrar apenas componentes Microsoft?

Ainda não significa que o Windows esteja necessariamente com bug.

Talvez:

um terceiro tenha corrompido memória anteriormente;
exista driver envolvido;
haja instabilidade;
o dump seja insuficiente;
a extensão não esteja visível na stack principal;
o problema seja realmente do Windows.

Precisamos ampliar o contexto.

Crash versus Hang novamente

Dumps também ajudam em travamentos.

Mas a estratégia muda.

Se o Explorer:

não fecha
↓
fica “Não respondendo”

podemos capturar um dump do processo enquanto ele está travado.

Isso permite investigar qual thread está esperando e onde.

Criando dump manual pelo Gerenciador de Tarefas

Dependendo da versão e interface do Windows, o Gerenciador de Tarefas pode permitir criar um arquivo de dump de um processo.

Se o Explorer estiver travado mas ainda vivo, isso pode ser útil.

O procedimento conceitual é:

Gerenciador de Tarefas
↓
Detalhes
↓
explorer.exe
↓
Criar arquivo de despejo

Depois, o arquivo pode ser analisado.

Dump de hang é diferente de dump de crash

No crash:

exceção
↓
processo termina

No hang:

processo continua
↓
thread fica bloqueada/esperando

A pergunta muda.

No crash:

“Qual exceção encerrou o processo?”

No hang:

“Em que o processo está esperando?”

Wait Chain Analysis

Para hangs, uma análise de cadeia de espera pode ajudar.

Ela pode mostrar se uma thread está aguardando:

outro processo;
recurso;
sincronização;
operação externa.

Isso pode ser útil quando o Explorer fica congelado ao acessar:

pasta de rede;
unidade desconectada;
extensão;
armazenamento lento.

Explorador trava em pasta de rede

Imagine:

abrir \\SERVIDOR\Documentos
↓
Explorer para de responder

Nesse caso, a investigação pode envolver:

SMB;
DNS;
servidor;
autenticação;
armazenamento do servidor;
shell extension;
arquivo remoto.

Não é necessariamente uma falha do próprio Explorer.

Process Monitor pode revelar esperas de I/O

Se o problema acontece ao abrir determinada pasta, o Process Monitor pode mostrar operações repetidas ou demoradas.

Filtre:

Process Name is explorer.exe

Depois observe:

caminhos;
resultados;
padrão de repetição;
acessos à rede;
arquivos específicos.

Mais uma vez:

ProcMon mostra atividade, não sentencia culpados.

Duração também importa

O Process Monitor pode ajudar a perceber se determinada operação demora muito.

Imagine:

Explorer
↓
tenta acessar \\servidor-antigo\
↓
espera
↓
interface parece travar

Nesse caso, talvez o Explorer não tenha “bugado”.

Ele pode estar esperando uma operação de rede.

Pastas do Acesso Rápido podem provocar comportamentos estranhos

Se o Acesso Rápido referencia:

compartilhamento que não existe;
unidade removida;
pasta de rede lenta;
caminho externo indisponível;

o Explorer pode demorar para responder em determinadas operações.

Isso é diferente de um crash.

Diferencie travamento de reinicialização visual

O usuário pode dizer:

“O Explorer reinicia.”

Mas, na prática, o que aconteceu foi:

Explorer travou
↓
Windows aguardou
↓
interface recuperou

ou:

explorer.exe caiu
↓
processo reiniciou

Os dois sintomas podem parecer semelhantes.

Verifique os eventos.

Reliability Monitor ajuda a separar os dois casos

Se houver uma falha registrada no horário:

Windows Explorer stopped working

ou evento equivalente, temos indicação de crash.

Se não houver e o processo apenas ficou sem responder temporariamente, talvez seja um hang.

Quando usar Windows Performance Recorder

Para problemas complexos de desempenho, travamentos e operações lentas, o Windows Performance Recorder (WPR) pode capturar rastreamentos muito detalhados.

Esses rastreamentos podem ser analisados no:

Windows Performance Analyzer (WPA).

Essa dupla é muito mais avançada que o Event Viewer.

WPR não é a primeira ferramenta

Se o Event Viewer mostra claramente:

ProgramaXYZShell.dll

não há motivo para começar gravando um ETL gigantesco.

Use WPR quando:

problema de desempenho é difícil;
Explorer trava sem crash;
precisamos analisar CPU/I/O;
hangs são recorrentes;
outras ferramentas não explicam.

Exemplo: Explorer congela por 10 segundos ao abrir Downloads

Event Viewer:

nenhum crash

Monitor de Confiabilidade:

nenhuma falha

Process Monitor:

muitos acessos a arquivos

WPR/WPA pode ajudar a entender:

CPU;
disco;
chamadas;
espera;
I/O;
atividade de arquivos.

Process Monitor versus WPR

Simplificando:

Process Monitor

Excelente para:

arquivo;
Registro;
processo;
caminho;
operação;
resultado.

WPR/WPA

Excelente para:

desempenho;
CPU;
I/O;
latência;
stacks;
eventos de kernel;
análise temporal profunda.

Cada ferramenta responde perguntas diferentes.

E se a falha só acontece depois de horas?

Esse tipo de problema é mais difícil.

Talvez exista:

vazamento de memória;
extensão acumulando estado;
conflito periódico;
atualização automática;
sincronização;
serviço.

A solução é coletar evidências no período em que o problema ocorre.

Verifique o consumo do explorer.exe

No Gerenciador de Tarefas ou Process Explorer, observe se o processo cresce continuamente em:

memória;
handles;
GDI objects;
USER objects;
CPU.

Um crescimento anormal ao longo do tempo pode indicar vazamento.

Vazamento de handles pode afetar o Explorer

Se uma extensão abre recursos e não os fecha corretamente, o número de handles pode crescer.

Exemplo conceitual:

10 min → 2.000 handles
1 h → 10.000
4 h → 40.000

Isso seria anormal e mereceria investigação.

O Process Explorer pode ajudar a observar essa evolução.

Reiniciar Explorer “resolve” vazamento?

Temporariamente, sim.

Quando o processo reinicia:

estado anterior é descartado
↓
handles fecham
↓
memória libera

Mas se a extensão defeituosa continuar instalada:

vazamento começa novamente

Isso explica alguns casos em que o problema volta horas depois.

Explorer consumindo muita memória não significa vazamento automaticamente

O processo pode carregar:

miniaturas;
extensões;
caches;
componentes.

Precisamos observar tendência.

O mais importante é:

cresce continuamente
+
não retorna
+
comportamento piora

e não apenas um número isolado.

Explorer cai depois de instalar codec pack

Esse é um cenário clássico de investigação.

Codecs e componentes multimídia podem influenciar:

miniaturas;
propriedades;
preview;
reprodução.

Se o problema começou após instalar um pacote de codecs e acontece apenas com vídeos, essa relação merece teste.

Não instale outro codec pack para “corrigir”

Isso pode aumentar a quantidade de componentes envolvidos.

Primeiro identifique o que já está instalado.

Depois teste:

remover/atualizar componente suspeito;
desativar extensão;
comparar comportamento.

Explorer cai ao conectar celular

Quando um smartphone aparece no Explorer, o acesso pode utilizar protocolos e componentes diferentes de um disco convencional.

Se a falha acontece apenas ao navegar pelo telefone:

teste outro cabo;
outra porta;
outro telefone;
driver;
aplicativo do fabricante;
MTP.

Não trate imediatamente como shell extension.

Explorer cai ao abrir Propriedades

Se a falha acontece em:

botão direito
↓
Propriedades

podemos investigar property sheet handlers adicionados por terceiros.

Programas podem acrescentar abas extras às propriedades.

Isso é outra forma de integração com o shell.

Explorer cai ao clicar em “Enviar para”

Também pode existir integração de terceiros em menus específicos.

O gatilho é essencial.

Quanto mais específico o usuário consegue ser:

“cai ao abrir Propriedades de um PDF”

melhor do que:

“Explorer cai às vezes”

Inicialização limpa: quando ela faz sentido?

Se nenhuma DLL específica aparece e suspeitamos de um software de terceiro que inicia com o sistema, uma inicialização limpa pode ser útil.

O objetivo é reduzir componentes de terceiros temporariamente.

Depois verificamos se o comportamento muda.

Inicialização limpa não é Modo de Segurança

No Modo de Segurança, o Windows carrega um ambiente significativamente reduzido.

Na inicialização limpa, mantemos o Windows em modo normal, mas reduzimos serviços e programas de terceiros.

Isso pode ser melhor para certos testes.

Método progressivo

Imagine que o problema desapareça em inicialização limpa.

Agora sabemos:

algum componente desativado participa

Mas ainda não sabemos qual.

Reative em grupos.

Por exemplo:

Grupo A ON
Grupo B OFF
↓
testar

Depois:

Grupo A OFF
Grupo B ON
↓
testar

Continue reduzindo o conjunto.

Documente alterações

Crie uma tabela:

Componente	Estado	Resultado
Software A	ON	falha
Software B	OFF	falha
Shell X	OFF	sem falha

Isso evita confusão depois de vários testes.

Não desative serviços Microsoft indiscriminadamente

Uma inicialização limpa mal feita pode provocar:

falta de áudio;
rede;
login;
impressão;
funções do sistema.

Use um procedimento controlado e preserve os serviços Microsoft.

SFC: como interpretar o resultado

Quando faz sentido verificar arquivos de sistema:

sfc /scannow

O SFC pode informar, em essência, que:

não encontrou violações de integridade;
encontrou e corrigiu arquivos;
encontrou problemas que não conseguiu corrigir totalmente.

O resultado deve ser registrado.

SFC limpo não prova que o Explorer está saudável em todos os aspectos

Ele verifica arquivos protegidos do sistema.

Ele não valida:

shell extensions de terceiros;
codecs;
software de nuvem;
antivírus de terceiro;
complementos externos.

Portanto:

SFC sem erros

não significa:

problema não existe

DISM também tem uma função específica

O comando:

DISM /Online /Cleanup-Image /RestoreHealth

atua na imagem/component store do Windows.

Ele é útil em cenários específicos de corrupção.

Mas não substitui:

investigar Faulting Module

Ordem recomendada em um problema reproduzível

Se o Explorer cai sempre no botão direito:

1. Event Viewer.
2. Faulting Module.
3. Identificar extensão.
4. Desativar integração.
5. Testar.

Não:

1. DISM.
2. SFC.
3. Reset.
4. Reinstalar Windows.

Driver pode derrubar explorer.exe?

É menos comum que uma shell extension em certos gatilhos, mas drivers podem participar de problemas sistêmicos.

Especialmente se existem:

falhas gráficas;
USB;
armazenamento;
dispositivos;
instabilidade geral.

Se a falha ocorre ao conectar hardware ou acessar determinado dispositivo, drivers entram na investigação.

Explorer cai junto com tela piscando

Se há:

tela preta rápida;
driver gráfico reiniciando;
eventos de vídeo;
outras aplicações afetadas;

talvez o problema não seja exclusivamente o Explorer.

Verifique eventos relacionados a gráficos.

Explorer cai ao acessar HD com problemas

Se o disco apresenta:

lentidão extrema;
timeouts;
desconexões;
erros de E/S;

o Explorer pode travar ou parecer reiniciar ao acessar a unidade.

Nesse cenário, investigue armazenamento antes de tratar o Explorer como causa.

Event Viewer: olhe eventos próximos, não apenas Application Error

Além do log Aplicativo, dependendo do sintoma, verifique eventos próximos relacionados a:

Disk;
Ntfs;
storport;
controlador;
Display;
dispositivos;
WER.

A falha do Explorer pode ser consequência.

O mesmo horário é fundamental

Imagine:

14:22:10 → erro de disco
14:22:12 → explorer.exe falha

Essa sequência é muito mais interessante que dois eventos vistos isoladamente.

Explorer e antivírus de terceiro

Antivírus podem integrar-se ao Explorer através de menus e inspeção de arquivos.

Se o problema começou após atualizar uma suíte de segurança:

registre versão;
verifique módulo;
teste integração;
atualize software.

Não desative toda a proteção sem necessidade.

Explorer e software de backup

Clientes de backup também podem adicionar:

ícones;
menus;
status;
overlays.

Se a falha acontece apenas em pastas gerenciadas pelo backup, investigue essa integração.

Explorer e overlays de ícones

Programas podem adicionar pequenos indicadores sobre ícones.

Exemplos:

sincronizado;
erro;
versionado;
backup realizado.

Múltiplos programas podem disputar recursos de integração do shell.

Isso pode gerar comportamentos estranhos.

O problema começou depois de desinstalar um programa

Isso também é possível.

Uma desinstalação incompleta pode deixar:

registro de extensão;
DLL ausente;
integração órfã.

Autoruns e Event Viewer podem ajudar a revelar esses resíduos.

Não use “limpador de Registro” para resolver

Se existe uma entrada órfã específica, o objetivo é identificar e remover corretamente a integração relacionada.

Um limpador genérico de Registro não sabe necessariamente qual entrada está causando a falha.

Além disso, pode remover itens sem relação com o problema.

Criar novo usuário pode ser um teste útil

Se suspeitamos de configuração específica de perfil, crie temporariamente um novo usuário local e teste.

Usuário A

Explorer cai

Usuário B

Explorer funciona

Isso sugere algo ligado ao perfil do usuário:

configurações;
extensões por usuário;
cache;
integração;
preferências.

Novo usuário funciona: isso não diz qual é a causa

Mas reduz o escopo.

Agora podemos investigar:

perfil
vs
sistema inteiro

Esse é um teste de isolamento.

Modo de Segurança também reduz o escopo

Se:

modo normal → falha
modo seguro → funciona

isso sugere que algum componente não carregado no Modo de Segurança participa.

Novamente, não identifica sozinho o culpado.

Dump + Autoruns + Event Viewer é uma combinação poderosa

Para um caso difícil:

Event Viewer
↓
módulo genérico

dump
↓
stack aponta para DLL X

Autoruns
↓
DLL X integra Explorer

desativar DLL X
↓
problema desaparece

Aqui temos um diagnóstico tecnicamente sólido.

Quando considerar instabilidade de RAM?

Se além do Explorer também vemos:

navegadores fechando;
aplicativos falhando;
códigos variados;
BSOD;
comportamento aleatório;
corrupção inexplicável;

a memória física pode entrar no diagnóstico.

O Windows possui:

mdsched.exe

para diagnóstico de memória.

Mas isso não deve substituir ferramentas mais completas em cenários profissionais.

Não atribua 0xc0000005 automaticamente à RAM

Essa associação é simplista.

O mesmo código pode surgir por:

software;
bug;
DLL;
extensão;
corrupção de memória;
driver;
hardware.

O contexto decide a prioridade.

Quando considerar reinstalação do Windows?

Somente depois que a investigação indicar algo mais amplo.

Por exemplo:

múltiplos componentes do sistema corrompidos;
falhas sistêmicas;
reparos sem efeito;
sistema alterado profundamente;
não conseguimos restaurar confiança.

Um Explorer derrubado por uma extensão de compactador não justifica reinstalar o sistema inteiro.

Não confunda atualização no lugar com instalação limpa

Em alguns casos, um reparo do Windows preservando aplicativos e dados pode ser considerado.

Em outros, uma instalação limpa é necessária.

São estratégias diferentes.

O artigo não deve tratar “reinstalar Windows” como solução única.

Checklist avançado desta parte

Quando o Faulting Module não é claro:

1. Confirmar repetição.
2. Capturar horário.
3. Event Viewer.
4. Monitor de Confiabilidade.
5. Comparar módulos.
6. Ver se outros apps falham.
7. Process Explorer.
8. Autoruns.
9. Process Monitor.
10. Reproduzir.
11. Capturar dump com ProcDump.
12. Analisar dump.
13. Diferenciar crash de hang.
14. Verificar stack.
15. Testar integração suspeita.
16. Inicialização limpa se necessário.
17. Novo perfil de usuário.
18. SFC/DISM se houver indícios de corrupção.
19. Investigar drivers/hardware se sintomas forem sistêmicos.
20. Confirmar correção reproduzindo o cenário original.

A regra de ouro

Quanto mais difícil a falha, mais importante é evitar alterar o sistema antes de registrar evidências.

A sequência ideal permanece:

observar
↓
registrar
↓
capturar
↓
correlacionar
↓
isolar
↓
corrigir
↓
confirmar

Chegamos à etapa final do diagnóstico.

Até aqui, vimos que o Explorador de Arquivos pode reiniciar por vários motivos, mas que um bom diagnóstico procura responder a uma pergunta objetiva:

qual componente estava envolvido quando o explorer.exe falhou?

O procedimento completo pode ser resumido assim:

sintoma
↓
confirmar crash ou hang
↓
registrar horário
↓
Monitor de Confiabilidade
↓
Visualizador de Eventos
↓
Faulting Module
↓
código de exceção
↓
identificar caminho e fabricante
↓
correlacionar com ação realizada
↓
testar extensão, handler ou programa
↓
capturar dump se necessário
↓
confirmar a correção

O mais importante é manter o diagnóstico organizado.

Procedimento completo para diagnosticar explorer.exe reiniciando sozinho

1. Observe exatamente o que acontece

Antes de abrir ferramentas, descreva o sintoma.

Pergunte:

a barra de tarefas some?
as janelas fecham?
a área de trabalho pisca?
o Explorer retorna sozinho?
o processo fica “Não respondendo”?
o computador inteiro congela?

Essas diferenças importam.

2. Descubra se é crash ou hang

Se o processo termina e volta:

explorer.exe
↓
crash
↓
reinício

Se o processo permanece ativo, mas sem responder:

explorer.exe
↓
hang
↓
espera/bloqueio

Crash e hang exigem abordagens diferentes.

3. Anote o horário exato

Exemplo:

15:42:17

Isso facilita encontrar eventos relacionados.

Sem horário, o Visualizador de Eventos pode virar uma lista enorme de informações sem contexto.

4. Anote o gatilho

Exemplos:

cliquei com botão direito

abri a pasta Downloads

selecionei um arquivo MKV

abri uma pasta do OneDrive

conectei um HD USB

O gatilho muitas vezes indica qual tipo de integração devemos investigar.

5. Abra o Monitor de Confiabilidade

Execute:

perfmon /rel

Procure falhas próximas ao horário registrado.

Se aparecer:

Windows Explorer

ou:

explorer.exe

abra os detalhes técnicos.

Anote:

nome do aplicativo;
módulo;
código de exceção;
horário;
versão.

6. Abra o Visualizador de Eventos

Execute:

eventvwr.msc

Navegue até:

Logs do Windows
↓
Aplicativo

Procure eventos do tipo:

Application Error

próximos ao horário.

7. Procure Event ID 1000

Um evento desse tipo pode trazer:

Faulting application name
Faulting module name
Exception code
Faulting application path
Faulting module path
Faulting process id

Esses campos formam a base do diagnóstico.

8. Verifique também eventos do Windows Error Reporting

Eventos próximos podem complementar o erro.

Um Event ID 1001 do Windows Error Reporting pode trazer informações adicionais sobre o relatório da falha.

Compare:

horário;
Report ID;
aplicativo;
módulo.

9. Registre o Faulting Module

Exemplo:

exemploShell.dll

Depois registre o caminho completo:

C:\Program Files\Fabricante\Programa\exemploShell.dll

O caminho costuma ser decisivo para identificar o software relacionado.

10. Descubra o fabricante da DLL

Verifique:

Propriedades → Detalhes

Procure:

Company Name;
Product Name;
File Description;
File Version.

Também verifique assinatura digital quando disponível.

11. Use PowerShell para coletar informações

Por exemplo:

(Get-Item "C:\Program Files\Fabricante\Programa\exemplo.dll").VersionInfo

Get-AuthenticodeSignature "C:\Program Files\Fabricante\Programa\exemplo.dll"

Isso ajuda a identificar a origem do componente.

12. Não culpe automaticamente ntdll.dll

Se aparecer:

ntdll.dll

não tente substituir essa DLL.

O mesmo cuidado vale para:

KERNELBASE.dll

e outros módulos centrais.

Eles podem ser apenas o ponto onde a exceção se manifestou.

13. Compare várias falhas

Uma única falha pode enganar.

Monte um histórico.

Exemplo:

Falha 1 → programaShell.dll
Falha 2 → programaShell.dll
Falha 3 → programaShell.dll

Isso é muito mais significativo.

14. Verifique se outros aplicativos também falham

Se apenas o Explorer cai:

suspeita maior:
shell / integração / conteúdo específico

Se vários aplicativos falham:

investigação mais ampla:
driver / memória / armazenamento / sistema

15. Se o problema acontece no botão direito, investigue extensões do shell

Esse é um dos cenários mais característicos.

Programas podem adicionar entradas ao menu de contexto.

Exemplos:

compactadores;
antivírus;
clientes de nuvem;
backup;
ferramentas gráficas;
utilitários.

Uma extensão defeituosa pode provocar a falha.

16. Use Autoruns para procurar integrações

Procure componentes de terceiros associados ao Explorer.

Dê prioridade aos programas que aparecem no caminho do módulo registrado.

Evite desativar itens aleatoriamente.

17. Desative apenas um componente suspeito

Depois:

reiniciar Explorer
↓
reproduzir

Se a falha desaparecer, temos uma evidência importante.

18. Confirme o resultado

Quando seguro:

extensão ativa
→ falha

extensão desativada
→ funciona

Essa comparação é muito mais confiável que uma impressão subjetiva.

19. Se o Explorer cai ao selecionar arquivos, teste preview e miniaturas

Desative temporariamente:

Painel de Visualização;
visualizações dependentes de miniaturas.

Depois repita.

Se o comportamento mudar, investigue:

preview handler;
thumbnail handler;
codec;
property handler.

20. Compare arquivos

Pergunte:

todos os arquivos desse tipo falham?

ou:

somente um arquivo?

Isso ajuda a separar:

problema do formato

de:

problema de arquivo específico

21. Compare pastas

Exemplo:

C:\Documentos → OK
C:\Fotos → OK
D:\Videos → crash

Agora o problema parece ligado ao conteúdo ou contexto daquela pasta.

22. Compare pasta local e pasta sincronizada

Exemplo:

C:\Teste → OK
OneDrive\Teste → falha

Isso pode apontar para integração de sincronização.

23. Se o problema acontece em pasta de rede, diferencie hang de crash

Pasta SMB lenta pode fazer o Explorer parecer travado.

Investigue:

DNS;
disponibilidade do servidor;
autenticação;
armazenamento;
latência;
compartilhamento.

Não assuma imediatamente que explorer.exe está com defeito.

24. Use Process Explorer

O Process Explorer ajuda a verificar:

DLLs carregadas;
caminhos;
propriedades;
handles;
threads.

Procure principalmente correlação com o Faulting Module.

25. Não apague DLLs manualmente

Nunca faça:

Faulting Module
↓
apagar DLL

Isso pode quebrar o programa e complicar a manutenção.

Atualize, repare, desinstale ou desative o componente corretamente.

26. Use Process Monitor quando o gatilho não é claro

Filtre:

Process Name is explorer.exe

Depois reproduza a falha.

Observe as operações imediatamente anteriores.

Procure:

arquivos;
Registro;
caminhos;
rede;
erros recorrentes.

27. Não interprete qualquer acesso como causa

Process Monitor registra milhares de operações legítimas.

A presença de uma DLL ou arquivo antes da falha não prova causalidade.

Busque convergência com outras ferramentas.

28. Se Event Viewer não bastar, capture um dump

Com ProcDump, podemos preparar a captura antes da falha.

Exemplo:

procdump -ma -e explorer.exe C:\Dumps

Confira os parâmetros da versão utilizada:

procdump -?

29. Analise o dump com WinDbg

Uma análise inicial pode utilizar:

!analyze -v

Depois examine:

exceção;
stack;
módulos;
threads.

A interpretação deve ser feita em conjunto com os outros dados.

30. Se o Explorer estiver travado, capture dump do hang

Se ele continua vivo e sem responder, um dump durante o travamento pode mostrar onde as threads estão esperando.

Isso é diferente de analisar uma exceção de crash.

31. Considere Wait Chain em hangs

A análise de cadeia de espera pode ajudar a mostrar se o Explorer está aguardando:

outro processo;
recurso;
operação.

Muito útil em alguns travamentos.

32. Use inicialização limpa quando não houver suspeito claro

Se o problema desaparece em inicialização limpa, sabemos que algum componente de terceiro participa.

Reative itens progressivamente.

33. Teste com outro usuário

Crie um perfil temporário.

Compare:

Usuário A → falha
Usuário B → funciona

Isso pode indicar problema específico do perfil.

34. Use Modo de Segurança como teste de isolamento

Se:

Modo normal → falha
Modo seguro → funciona

sabemos que algum componente ausente no ambiente reduzido pode estar envolvido.

35. Execute SFC quando houver indício de corrupção

Use:

sfc /scannow

Mas não trate SFC como solução automática para qualquer crash do Explorer.

36. Use DISM quando fizer sentido

Por exemplo:

DISM /Online /Cleanup-Image /RestoreHealth

Esse comando pode reparar problemas na imagem do Windows.

Ele não corrige uma extensão de shell defeituosa de terceiro.

37. Investigue armazenamento se houver sinais de disco

Se o Explorer falha ao acessar determinado HD ou SSD e também existem:

lentidão;
timeouts;
desconexões;
erros de E/S;

analise o armazenamento.

O Explorer pode ser vítima do problema, não a causa.

38. Investigue drivers quando o cenário envolver hardware

Exemplos:

GPU;
USB;
armazenamento;
celular;
docking station.

Eventos próximos podem revelar outras pistas.

39. Considere memória física apenas quando o padrão justificar

Se vários aplicativos falham aleatoriamente, códigos variam e existem outros sintomas de instabilidade, a RAM entra no diagnóstico.

O Windows disponibiliza:

mdsched.exe

Mas não associe qualquer 0xc0000005 diretamente a defeito físico.

40. Confirme a correção reproduzindo o problema original

Essa etapa é frequentemente esquecida.

Se o Explorer caía ao:

clicar com botão direito em PDF

a validação deve reproduzir justamente isso.

Não basta o computador ficar ligado por cinco minutos.

Cenários práticos

Cenário 1 — Clique com botão direito reinicia o Explorer

Sintoma:

botão direito em arquivo
↓
barra de tarefas desaparece
↓
Explorer retorna

Verifique:

Event Viewer;
Faulting Module;
extensão de menu de contexto;
Autoruns;
software atualizado recentemente.

Provável área:

shell extension.

Cenário 2 — Explorer cai ao abrir pasta de vídeos

Faça:

teste sem Painel de Visualização;
teste em modo Detalhes;
compare arquivos;
analise codecs;
observe Faulting Module.

Possível área:

thumbnail/preview handler ou codec.

Cenário 3 — Explorer reinicia ao abrir PDFs

Compare:

todos os PDFs

com:

somente um PDF

Teste o painel de visualização.

Verifique software de PDF instalado e integrações do Explorer.

Cenário 4 — Explorer cai somente dentro do OneDrive

Compare o mesmo arquivo fora da pasta sincronizada.

Investigue:

cliente de nuvem;
integração;
icon overlays;
menu de contexto.

Cenário 5 — Explorer cai depois de instalar compactador

Muito suspeito se o problema aparece ao:

clicar com botão direito;
acessar ZIP/RAR/7z.

Verifique a shell extension do compactador.

Cenário 6 — Explorer reinicia após conectar HD externo

Antes de concluir que é shell extension, verifique:

integridade da unidade;
eventos de armazenamento;
erros de leitura;
USB;
driver;
arquivos específicos.

Cenário 7 — Explorer não cai, apenas congela ao acessar rede

Isso pode ser hang.

Teste:

servidor acessível;
DNS;
compartilhamento;
SMB;
unidade mapeada;
Acesso Rápido.

Cenário 8 — ntdll.dll aparece sempre

Não substitua ntdll.dll.

Capture mais evidências:

dump;
stack;
Process Explorer;
extensões;
inicialização limpa.

Cenário 9 — módulos diferentes em cada queda

Amplie o escopo.

Verifique:

outros programas;
RAM;
armazenamento;
drivers;
integridade do sistema.

Cenário 10 — Explorer cai uma vez por semana

O diagnóstico precisa de histórico.

Registre:

horário;
ação;
evento;
módulo;
software ativo.

Não faça alterações grandes após um único evento isolado.

Checklist rápido VMIA

Se o Explorador de Arquivos reinicia sozinho no Windows 11:

confirme se foi crash ou hang;
anote o horário;
registre o que estava fazendo;
execute perfmon /rel;
abra eventvwr.msc;
procure Application Error;
registre o módulo com falha;
registre o código de exceção;
veja o caminho da DLL;
identifique o fabricante;
compare várias falhas;
veja se outros aplicativos também caem;
investigue extensões do shell;
teste preview e miniaturas;
use Process Explorer;
use Autoruns;
desative apenas o componente suspeito;
reproduza a falha;
use Process Monitor se necessário;
capture dump com ProcDump em casos difíceis;
analise crash e hang de forma diferente;
use SFC/DISM somente quando apropriado;
investigue drivers e hardware se os sintomas forem sistêmicos;
confirme a correção no cenário original.

FAQ — Explorador de Arquivos reinicia sozinho no Windows 11

1. Por que o Explorador de Arquivos fecha e abre sozinho?

Uma possibilidade é que o processo explorer.exe tenha sofrido uma falha e sido reiniciado. Extensões do shell, DLLs de terceiros, codecs, clientes de nuvem, bugs, drivers e problemas sistêmicos podem estar envolvidos.

2. A barra de tarefas desaparecer significa que explorer.exe caiu?

Pode indicar isso, principalmente se a barra reaparece logo depois. Confirme pelo Monitor de Confiabilidade e Visualizador de Eventos.

3. Como descobrir se explorer.exe realmente falhou?

Execute:

perfmon /rel

e verifique eventos próximos ao horário.

Depois consulte:

eventvwr.msc

em:

Logs do Windows → Aplicativo

4. O que é Faulting Module?

É o módulo registrado no contexto da falha de um aplicativo.

Pode ser uma DLL ou outro componente.

É uma pista importante, mas não prova automaticamente que o módulo é a causa original.

5. Como descobrir o módulo que derrubou o Explorer?

Procure um evento Application Error relacionado a explorer.exe e veja o campo:

Faulting module name

Também verifique o caminho do módulo.

6. Event ID 1000 significa defeito no Windows?

Não.

Ele registra uma falha de aplicação.

A causa pode estar no aplicativo, em componentes de terceiros ou em outros elementos do sistema.

7. Event ID 1001 é a mesma coisa?

Pode estar relacionado ao Windows Error Reporting e complementar informações sobre a mesma falha.

Compare horário e identificadores.

8. ntdll.dll apareceu como módulo. Ela está corrompida?

Não necessariamente.

ntdll.dll participa de muitas operações do Windows.

Outro componente pode ter provocado a condição que terminou nela.

9. Devo baixar ntdll.dll da Internet?

Não.

Evite substituir componentes do Windows por DLLs baixadas de sites aleatórios.

10. O que significa erro 0xc0000005?

É normalmente uma violação de acesso à memória.

O código sozinho não identifica a causa.

11. 0xc0000005 significa RAM defeituosa?

Não necessariamente.

Software, DLLs, drivers e outros problemas também podem causar esse tipo de exceção.

12. Por que o Explorer trava ao clicar com o botão direito?

Programas de terceiros podem adicionar extensões ao menu de contexto.

Uma extensão defeituosa pode provocar falha.

13. O que é uma shell extension?

É um componente que integra funcionalidades de um programa ao shell do Windows.

Pode adicionar menus, ícones, propriedades, previews e outras funções.

14. Como descobrir qual extensão está causando o problema?

Use o Faulting Module, Autoruns, Process Explorer e testes controlados de desativação.

15. Posso apagar a DLL que aparece no erro?

Não é recomendado.

Identifique primeiro o programa responsável e faça a correção por meio dele.

16. Autoruns pode ajudar?

Sim.

Ele permite visualizar várias integrações e componentes carregados no Windows, inclusive relacionados ao Explorer.

17. ShellExView pode ajudar?

Pode ser útil para visualizar e testar extensões do shell de terceiros.

18. O Explorer cai quando seleciono um vídeo. Pode ser codec?

Sim.

Também pode envolver thumbnail handler, preview handler ou componente de metadados.

19. Como testar isso?

Desative temporariamente o Painel de Visualização e reduza o uso de miniaturas.

Depois reproduza.

20. Um arquivo específico pode derrubar o Explorer?

Pode ser o gatilho.

Isso não significa necessariamente que o arquivo esteja corrompido.

Ele pode expor um bug em um handler ou codec.

21. OneDrive pode estar relacionado?

Pode.

Clientes de nuvem adicionam integrações ao Explorer.

Compare o comportamento dentro e fora da pasta sincronizada.

22. Antivírus pode causar problema no Explorer?

Alguns antivírus adicionam menus ou outras integrações.

Se uma DLL do produto aparece repetidamente nas falhas, investigue.

23. Process Explorer serve para quê nesse caso?

Ajuda a verificar módulos, caminhos, threads, handles e propriedades do processo.

24. Process Monitor descobre automaticamente o culpado?

Não.

Ele mostra atividade detalhada. A interpretação precisa ser correlacionada com outras evidências.

25. O que é ProcDump?

É uma ferramenta Sysinternals usada para capturar dumps de processos sob determinadas condições.

26. Quando devo usar ProcDump?

Quando a falha é frequente ou reproduzível e os registros normais não mostram causa suficiente.

27. Como capturar dump do Explorer?

Uma abordagem possível é:

procdump -ma -e explorer.exe C:\Dumps

Consulte a ajuda da versão utilizada antes do teste.

28. O dump contém dados privados?

Pode conter informações da memória do processo.

Trate o arquivo como potencialmente sensível.

29. Como analisar um dump?

O WinDbg pode abrir dumps e permitir análise de exceções, threads e stacks.

30. `!analyze -v` identifica automaticamente o culpado?

Não necessariamente.

Ele gera uma análise útil, mas ainda exige interpretação.

31. O Explorer ficar “Não respondendo” é a mesma coisa que crash?

Não.

Nesse caso pode existir um hang.

O processo continua vivo, mas bloqueado ou aguardando alguma operação.

32. Pasta de rede pode travar o Explorer?

Sim.

Falhas de disponibilidade, DNS, SMB ou armazenamento remoto podem causar longas esperas.

33. SFC resolve qualquer falha do Explorer?

Não.

SFC verifica arquivos protegidos do Windows.

Não corrige automaticamente extensões de terceiros.

34. Devo rodar DISM?

Use quando houver motivos para investigar corrupção da imagem do Windows.

Não como primeira resposta para qualquer crash.

35. Inicialização limpa ajuda?

Sim, quando suspeitamos de componentes de terceiros e não conseguimos identificar um suspeito específico.

36. Criar outro usuário ajuda?

Pode ajudar a separar problema do perfil de usuário de um problema do sistema inteiro.

37. Modo de Segurança ajuda?

Sim, como teste de isolamento.

Se a falha desaparece, algum componente não carregado no ambiente reduzido pode estar envolvido.

38. Explorer reinicia por causa de SSD com problema?

Pode acontecer indiretamente.

Falhas ou timeouts de armazenamento podem travar operações do Explorer.

39. Devo formatar o Windows?

Não como primeira medida.

Se a falha está ligada a uma extensão específica, reinstalar o sistema inteiro seria desproporcional.

40. Qual é a melhor sequência de diagnóstico?

A sequência mais eficiente é:

registrar
↓
correlacionar
↓
identificar
↓
isolar
↓
testar
↓
confirmar

Conclusão

Quando o Explorador de Arquivos reinicia sozinho no Windows 11, o problema não deve ser tratado apenas como “mais um bug do Windows”.

O explorer.exe funciona como uma peça central da interface e pode carregar ou interagir com diversos componentes de terceiros.

Por isso, uma falha pode surgir por causa de:

shell extension;
menu de contexto;
preview handler;
codec;
cliente de nuvem;
antivírus;
backup;
driver;
armazenamento;
corrupção do sistema.

A melhor investigação começa pelo horário da falha e pelo módulo registrado.

Ferramentas como:

perfmon /rel
eventvwr.msc
Process Explorer
Autoruns
Process Monitor
ProcDump
WinDbg

permitem sair de um diagnóstico baseado em tentativas para um processo baseado em evidências.

A presença de uma DLL no campo Faulting Module é uma pista, não uma condenação automática.

O diagnóstico ganha força quando vários elementos convergem:

mesmo módulo
+
mesmo gatilho
+
mesmo software
+
teste controlado
+
falha desaparece

Esse é o ponto em que deixamos de “achar” e começamos realmente a identificar a causa.

Precisa de ajuda para descobrir por que o Explorer está reiniciando?

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas do Windows 11, travamentos, falhas de aplicativos, Explorer, drivers, armazenamento e softwares que interferem no funcionamento do sistema.

O atendimento pode ser feito por acesso remoto ou visita técnica com agendamento.

Telefone e WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br

Em vez de simplesmente reinstalar o Windows ou desativar serviços aleatoriamente, o objetivo é localizar a origem do problema e corrigir o componente responsável.