O computador liga normalmente. A tela de bloqueio aparece rápido. Você digita a senha ou PIN, o Windows 11 aceita a autenticação e parece que tudo deveria terminar em poucos segundos.

Mas não termina.

A tela permanece durante muito tempo em Bem-vindo, fica escura por alguns segundos ou minutos, mostra apenas o cursor do mouse ou finalmente exibe a Área de Trabalho, mas ainda demora até que barra de tarefas, ícones e programas fiquem realmente utilizáveis.

É comum resumir tudo isso em:

“Meu Windows está demorando para iniciar.”

Só que essa descrição pode levar o diagnóstico para o lugar errado.

Se o Windows chegou rapidamente à tela de logon, uma parte importante da inicialização já aconteceu.

O problema pode estar especificamente no que acontece depois da autenticação do usuário.

Podemos representar o cenário assim:

Liga o computador
        ↓
Windows inicializa
        ↓
Tela de logon aparece
        ↓
Usuário informa PIN/senha
        ↓
Autenticação
        ↓
“Bem-vindo”
        ↓
Perfil do usuário
        ↓
Explorer / Shell
        ↓
Área de Trabalho
        ↓
Sessão realmente utilizável

Cada etapa pode sofrer atrasos por motivos diferentes.

Entre os possíveis responsáveis estão:

perfil do usuário
serviços
scripts
tarefas agendadas
programas
rede
DNS
unidades mapeadas
credenciais
políticas
antivírus
sincronização
drivers
armazenamento
Explorer

Portanto, simplesmente abrir o Gerenciador de Tarefas e desativar tudo que aparece em Aplicativos de Inicialização não constitui um diagnóstico completo.

Neste guia da VMIA, vamos seguir outra estratégia:

medir onde o atraso começa, descobrir qual etapa termina tarde e somente depois investigar o componente responsável.

---

Primeiro: boot lento e logon lento são problemas diferentes

Imagine dois computadores.

Computador A

pressiona Power
↓
2 minutos
↓
tela de logon
↓
digita PIN
↓
5 segundos
↓
Área de Trabalho

Computador B

pressiona Power
↓
20 segundos
↓
tela de logon
↓
digita PIN
↓
90 segundos
↓
Área de Trabalho

Nos dois casos, o usuário pode dizer:

“O Windows demora para entrar.”

Mas tecnicamente temos problemas diferentes.

No computador A, o atraso ocorre principalmente antes do logon.

No computador B, o Windows chega rapidamente à autenticação e perde tempo depois que o usuário entra na sessão.

Este artigo trata principalmente do segundo cenário.

---

Cronometre antes de modificar

A primeira ferramenta de diagnóstico pode ser simplesmente um cronômetro.

Não precisamos de precisão de laboratório.

Queremos descobrir aproximadamente onde estão os segundos.

Faça três medições.

---

Medição 1 — Power até tela de logon

Comece quando liga o computador.

Pare quando a tela para informar PIN ou senha estiver pronta.

Anote:

Power → Logon = 22 segundos

---

Medição 2 — Enter até Área de Trabalho

Digite o PIN ou senha e inicie a contagem no momento da confirmação.

Pare quando a Área de Trabalho aparecer.

Exemplo:

Enter → Desktop = 68 segundos

---

Medição 3 — Área de Trabalho até computador utilizável

Essa medição é frequentemente ignorada.

A Área de Trabalho apareceu, mas tente imediatamente:

abrir Menu Iniciar
abrir Explorer
abrir navegador
abrir uma pasta

Talvez o desktop apareça em:

15 segundos

mas o computador só responda normalmente depois de:

70 segundos

Então temos outro tipo de atraso.

---

Monte uma linha do tempo

Exemplo:

Etapa	Tempo
Power → tela de logon	19 s
PIN → desktop	73 s
Desktop → utilizável	12 s

Esse resultado direciona a investigação para:

fase de logon

Agora outro computador:

Etapa	Tempo
Power → tela de logon	21 s
PIN → desktop	8 s
Desktop → utilizável	96 s

Aqui o problema provavelmente está mais relacionado ao que acontece depois que o shell aparece.

---

“Bem-vindo” por muito tempo é uma pista

Se o Windows permanece em:

Bem-vindo

por muito tempo depois da autenticação, registre isso.

Não conclua automaticamente:

SSD lento

ou:

Windows corrompido

Nesse momento, o sistema pode estar trabalhando com componentes relacionados à criação da sessão, carregamento do perfil, políticas, scripts, serviços e recursos necessários ao usuário.

---

Tela preta com cursor é outro sintoma

Imagine:

PIN
↓
Bem-vindo
↓
tela preta
↓
cursor aparece
↓
40 segundos
↓
Área de Trabalho

Esse comportamento merece ser registrado separadamente.

Pergunte:

Explorer demorou para iniciar?
algum componente bloqueou o shell?
perfil demorou?
há processo esperando recurso?

Não assuma imediatamente que o driver de vídeo é o culpado apenas porque a tela ficou preta.

---

Desktop aparece, mas barra de tarefas demora

Outro cenário:

papel de parede aparece
↓
ícones aparecem
↓
barra de tarefas não responde
↓
Menu Iniciar não abre
↓
depois de 40 segundos tudo normaliza

Aqui o tempo deve ser medido até:

sessão utilizável

e não apenas até o papel de parede aparecer.

---

Por que essa diferença importa?

Porque “tempo de inicialização” pode misturar:

firmware
boot
kernel
drivers
serviços
autenticação
perfil
shell
programas do usuário

Se o problema está depois da senha, investigar BIOS por horas provavelmente será desperdício de tempo.

---

Reiniciar é melhor que desligar para o primeiro teste

Para criar uma medição comparável, prefira:

Reiniciar

em vez de alternar entre desligar e ligar.

Isso reduz variáveis relacionadas ao comportamento de inicialização do Windows.

Faça pelo menos duas ou três medições.

---

Não confie em um único logon

O primeiro logon depois de:

atualização
instalação
manutenção
mudança de perfil

pode ser diferente dos seguintes.

Registre:

teste 1
teste 2
teste 3

---

O problema acontece sempre?

Classifique:

sempre
às vezes
somente primeiro logon do dia
somente depois de reiniciar
somente conectado à Internet
somente no Wi-Fi
somente fora da empresa
somente com determinado usuário

Esse dado vale muito.

---

O teste mais importante: outro usuário

Crie ou utilize outra conta local de teste, quando isso for apropriado.

Faça o logon.

Agora compare.

Resultado A

Usuário A → 80 segundos
Usuário B → 8 segundos

Esse resultado muda completamente a investigação.

O problema provavelmente está relacionado a algo específico do contexto do primeiro usuário.

---

Isso não significa automaticamente “perfil corrompido”

Essa conclusão é comum e precipitada.

Uma conta pode possuir:

programas de inicialização próprios
tarefas
scripts
configurações
sincronização
unidades de rede
credenciais
shell extensions
dados no perfil

Portanto:

outro usuário funciona

é uma excelente pista, mas não prova corrupção do perfil.

---

Resultado B — todos os usuários demoram

Se:

Usuário A → 70 segundos
Usuário B → 72 segundos

o problema pode estar em uma camada compartilhada pelo sistema.

Agora ganham importância:

serviços
drivers
armazenamento
segurança
rede
tarefas do sistema

---

Resultado C — administrador funciona, usuário comum não

Também é uma pista.

Compare:

programas
políticas
perfil
permissões
scripts
recursos de rede

Não conclua que a solução seja transformar o usuário em administrador.

---

Faça o teste sem Internet

Esse teste pode revelar muito.

Primeiro meça normalmente:

Internet conectada
PIN → Desktop = 75 s

Depois, em um teste controlado, desconecte a rede antes do logon.

Exemplo:

Internet desconectada
PIN → Desktop = 9 s

Essa diferença é extremamente importante.

---

Se sem rede fica muito mais rápido, investigue dependências de rede

Possibilidades incluem:

unidades mapeadas
DNS
scripts
servidores indisponíveis
aplicativos
credenciais
políticas
sincronização
recursos corporativos

Não significa necessariamente que “a Internet está lenta”.

---

Rede rápida não garante logon rápido

Você pode ter:

600 Mbps

e ainda esperar dezenas de segundos porque algum componente tenta alcançar:

servidor que não existe mais

ou um nome que demora para falhar.

Velocidade de banda e tempo de espera são coisas diferentes.

---

Timeout é uma pista importante

Imagine um programa tentando acessar:

\\SERVIDOR-ANTIGO\Dados

O servidor não existe mais.

O Windows ou o aplicativo pode tentar resolver:

nome
rede
autenticação
conexão

até desistir.

O usuário vê apenas:

“Bem-vindo demorando”

---

Verifique unidades mapeadas

No Prompt de Comando:

net use

Observe unidades e conexões existentes.

Exemplo:

Z: → \\Servidor\Arquivos

Pergunte:

esse servidor ainda existe?
está acessível?
a unidade reconecta no logon?

---

Não remova todas as unidades mapeadas

Primeiro identifique as que realmente estão relacionadas ao problema.

Em empresas, uma unidade pode ser necessária para o trabalho.

---

Teste o servidor diretamente

Se existe:

\\SERVIDOR\Dados

teste o acesso depois que o Windows terminar de entrar.

Você pode também verificar resolução:

ping SERVIDOR

O Ping não prova que SMB está funcionando, mas pode ajudar a verificar se o nome é resolvido e se o host responde a ICMP quando isso é permitido.

---

Test-NetConnection pode ajudar

PowerShell:

Test-NetConnection SERVIDOR -Port 445

Para compartilhamentos SMB, a porta TCP 445 é relevante.

Agora temos uma pergunta mais específica:

o servidor SMB está alcançável?

---

DNS pode atrasar sem “derrubar a Internet”

Se um componente tenta resolver repetidamente um nome inválido, a Internet pode parecer perfeitamente normal depois do logon.

Por isso:

sites abrem normalmente

não elimina completamente uma dependência de resolução de nomes durante o logon.

---

Teste outro tipo de conexão

Se possível:

Wi-Fi
versus
Ethernet

Não para concluir que um é sempre melhor, mas para observar se o atraso muda.

---

Se Ethernet demora e Wi-Fi não

Investigue diferenças de:

DNS
perfil de rede
DHCP
rotas
recursos corporativos
adaptadores

---

Se ambos demoram igual

A hipótese exclusivamente relacionada ao adaptador perde força.

---

Veja o tempo registrado pelo Gerenciador de Tarefas

Abra:

Gerenciador de Tarefas
→ Aplicativos de Inicialização

Você pode encontrar a informação:

Última hora do BIOS

ou equivalente conforme a interface.

Esse número pode ser útil para separar uma demora anterior ao carregamento do Windows de um problema que ocorre muito depois.

Mas ele não mede sozinho toda a experiência do usuário.

---

Aplicativos de Inicialização continuam relevantes

Eles não devem ser ignorados.

A diferença é que não vamos simplesmente desativar todos.

Observe:

nome
editor
impacto
necessidade

e faça testes controlados.

---

O “Impacto na inicialização” não conta toda a história

Um aplicativo pode ter impacto aparentemente baixo e ainda esperar:

rede
servidor
arquivo
serviço
autenticação

em determinada máquina.

Por isso, o comportamento real é mais importante que o rótulo.

---

Use Autoruns para enxergar mais pontos de inicialização

O Autoruns, da suíte Sysinternals da Microsoft, consegue mostrar muito mais mecanismos de inicialização automática do que a guia básica do Gerenciador de Tarefas.

Entre eles:

Logon
Services
Scheduled Tasks
Explorer
Drivers

Para diagnóstico, ele é extremamente útil.

---

Não desmarque tudo no Autoruns

Essa ferramenta expõe componentes importantes do sistema e de aplicativos.

A estratégia correta é:

identificar
documentar
formular hipótese
desativar item específico
reiniciar
medir novamente

---

Use o teste A/B

Suponha que suspeitamos de um aplicativo.

Antes:

PIN → Desktop utilizável = 68 s

Desative somente aquele componente.

Depois:

PIN → Desktop utilizável = 14 s

Repita o teste.

Se a diferença é consistente, temos evidência.

---

Não confunda correlação com causa

Se um único teste ficou mais rápido, repita.

Talvez naquele logon:

rede respondeu mais rápido
antivírus já havia terminado uma tarefa
cache estava diferente

Faça duas ou três medições.

---

Visualizador de Eventos: comece a montar a linha do tempo

Abra:

eventvwr.msc

O Visualizador de Eventos permite correlacionar eventos com o horário do logon.

Não procure apenas mensagens vermelhas.

---

Erro vermelho não significa automaticamente culpado

O Windows registra muitos eventos que não provocam o sintoma investigado.

Pergunte:

aconteceu durante o atraso?
repete em todos os logons lentos?
desaparece nos logons rápidos?
está relacionado ao componente suspeito?

---

O horário é fundamental

Se você digitou o PIN às:

10:15:20

e o desktop ficou utilizável às:

10:16:35

concentre a investigação nesse intervalo.

Isso reduz muito o ruído.

---

Crie um diário de testes

Exemplo:

Teste 1
Rede: conectada
Usuário: Victor
PIN: 10:15:20
Desktop: 10:16:28
Utilizável: 10:16:35
Tempo: 75 s

Teste 2
Rede: desconectada
Usuário: Victor
PIN: 10:22:11
Desktop: 10:22:20
Utilizável: 10:22:23
Tempo: 12 s

Isso vale mais do que:

“pareceu mais rápido”

---

Teste também logoff e novo logon

Faça:

Sair

e entre novamente.

Compare com:

Reiniciar
→ logon

---

Por que isso é útil?

Se:

após reboot → 80 s
logoff/logon → 10 s

alguma condição existente no primeiro logon após a inicialização merece atenção.

Se:

reboot → 80 s
logoff/logon → 78 s

o problema acompanha mais fortemente a criação da sessão.

---

Teste Bloquear versus Sair

Bloquear:

Win + L

não encerra a sessão.

Sair:

Logoff

encerra.

Se desbloquear é instantâneo, mas um novo logon é lento, isso reforça a importância da fase de criação da sessão.

---

Não reinstale o Windows ainda

Neste ponto já conseguimos realizar vários testes sem nenhuma alteração destrutiva:

cronômetro
outro usuário
com/sem rede
Wi-Fi/Ethernet
reboot/logoff
unidades mapeadas
eventos
inicialização

Essas comparações podem reduzir enormemente o universo de causas.

---

O perfil do usuário merece atenção

O perfil normalmente está associado a uma estrutura como:

C:\Users\Usuario

Ele contém:

Desktop
Documents
AppData
configurações
dados de aplicativos

Durante a sessão, vários componentes dependem desses dados.

---

AppData pode esconder o verdadeiro problema

Um aplicativo pode manter:

cache
banco de dados
configurações
logs
estado da sessão

dentro do perfil.

Se um desses componentes está problemático, outro usuário pode funcionar perfeitamente.

---

Não apague AppData para testar

Isso pode remover:

configurações
sessões
dados de programas
credenciais locais

e criar problemas adicionais.

Primeiro descubra qual aplicativo ou componente está envolvido.

---

Perfil enorme significa logon lento?

Não obrigatoriamente.

O tamanho total de:

C:\Users\Usuario

sozinho não prova a causa.

É mais importante descobrir o que está sendo acessado durante o intervalo lento.

É justamente aí que ferramentas como Process Monitor e Windows Performance Recorder se tornam muito interessantes.

---

Serviços também podem participar

Abra:

services.msc

Observe serviços de:

antivírus
backup
VPN
sincronização
fabricante
impressora
aplicativos empresariais

Não desative serviços da Microsoft aleatoriamente.

---

Um serviço pode estar iniciado, mas ainda não estar pronto

Esse detalhe é importante.

A interface pode mostrar:

Em execução

mas um aplicativo pode depender de uma operação que o serviço ainda está concluindo.

Por isso, status Running não prova que toda dependência já respondeu.

---

Tarefas agendadas podem executar no logon

Abra:

taskschd.msc

Procure tarefas cujo gatilho seja semelhante a:

Ao fazer logon

ou tarefas que coincidam temporalmente com a sessão.

---

Não desative todas as tarefas

Algumas pertencem ao Windows e outras a softwares necessários.

Correlacione:

horário
gatilho
programa executado
tempo
sintoma

---

Programas que acessam rede merecem atenção especial

Exemplos:

cliente de backup
VPN
sincronização
software empresarial
atualizador
gerenciador de documentos

Se o atraso muda drasticamente sem rede, esses componentes sobem na lista de suspeitos.

---

O antivírus também pode ser parte da investigação

Não conclua imediatamente que o Defender ou outro antivírus “deixa o Windows lento”.

Primeiro procure evidência.

Um programa de segurança pode estar analisando muitos objetos justamente durante o logon, mas também pode não ter relação alguma com o problema.

---

Não desative a proteção permanentemente para testar

Prefira analisar:

atividade
horário
uso de CPU
I/O
eventos

e utilizar métodos de diagnóstico que não deixem o computador desprotegido.

---

Gerenciador de Tarefas durante o período lento

Se o desktop aparece, mas permanece lento, abra:

Ctrl + Shift + Esc

Observe:

CPU
Memória
Disco
Rede

---

Disco em 100% é evidência, mas não diagnóstico

Se o disco está:

100%

pergunte:

qual processo?
qual arquivo?
leitura ou gravação?
quanto tempo?

---

CPU baixa não significa que nada está esperando

Um processo pode estar aguardando:

rede
disco
evento
outro processo
timeout

sem consumir muita CPU.

Esse é um dos motivos pelos quais “CPU está em 5%” não elimina um problema de espera.

---

O padrão temporal é a primeira grande evidência

Antes de usar ferramentas avançadas, queremos responder:

onde começa a demora?
quanto dura?
acontece com todos os usuários?
muda sem Internet?
muda no segundo logon?
desktop aparece antes de ficar utilizável?

Se respondermos essas perguntas, já eliminamos várias hipóteses.

---

Primeira matriz de diagnóstico

Resultado	Principal direção da investigação
Demora antes da tela de logon	Boot, drivers, serviços, firmware
Demora principalmente no “Bem-vindo”	Sessão, perfil, política, rede
Outro usuário entra rápido	Contexto específico do usuário
Todos entram devagar	Componente compartilhado
Sem Internet fica rápido	Dependência de rede
Logoff/logon fica rápido	Condição ligada ao primeiro logon/boot
Desktop aparece, mas trava	Pós-logon, aplicativos, I/O
Explorer demora para aparecer	Shell, perfil, extensões, dependências
Disco fica ocupado	Investigar processo e arquivos
CPU baixa e espera longa	Timeout/dependência pode ser relevante

---

O que não fazer ainda

Não faça:

formatar Windows
apagar perfil
apagar AppData
desativar todos os serviços
desativar todas as tarefas
remover todos os programas
alterar Registro aleatoriamente

Essas ações destroem evidências e podem criar novos problemas.

---

Nosso objetivo é encontrar a primeira diferença

Em um logon rápido:

A
→ B
→ C
→ D
→ desktop

Em um logon lento:

A
→ B
→ C
→ espera 60 segundos
→ D
→ desktop

A pergunta é:

O que aconteceu entre C e D?

Essa lógica será fundamental quando chegarmos ao Process Monitor e ao WPR/WPA.

---

Checklist da Parte 1

Antes de continuar, registre:

[ ] Tempo Power → tela de logon
[ ] Tempo PIN → desktop
[ ] Tempo PIN → desktop utilizável
[ ] Testei mais de uma vez
[ ] Testei outro usuário
[ ] Testei com rede
[ ] Testei sem rede
[ ] Comparei Wi-Fi/Ethernet se aplicável
[ ] Testei reiniciar
[ ] Testei logoff/logon
[ ] Verifiquei unidades mapeadas
[ ] Registrei o horário exato do atraso
[ ] Observei eventos no mesmo intervalo
[ ] Verifiquei aplicativos de inicialização
[ ] Observei CPU, disco e rede
[ ] Não fiz alterações em massa

O principal aprendizado

Quando o Windows 11 demora depois que você informa o PIN ou senha, não devemos tratar automaticamente o problema como “Windows lento para iniciar”.

Primeiro separe:

boot
autenticação
logon
perfil
shell
pós-logon

Depois meça.

Um teste simples pode revelar:

Power → Logon = 20 s
PIN → Desktop = 75 s

Isso já muda completamente a investigação.

E comparações como:

usuário A vs usuário B
rede vs sem rede
reboot vs logoff
desktop visível vs desktop utilizável

podem indicar onde procurar antes mesmo de utilizar ferramentas avançadas.

Event Viewer, perfil, Group Policy e tarefas: reconstruindo o que aconteceu durante o logon lento

Na Parte 1, separamos três intervalos:

Power → tela de logon
PIN/senha → Área de Trabalho
Área de Trabalho → sessão utilizável

Agora vamos investigar o segundo e o terceiro intervalos com evidências do próprio Windows.

O objetivo não é abrir o Visualizador de Eventos e procurar qualquer ícone vermelho.

Queremos montar uma linha do tempo.

Se o usuário confirmou o PIN às:

10:15:20

e o computador ficou utilizável às:

10:16:42

temos uma janela de aproximadamente:

82 segundos

Nossa pergunta passa a ser:

O que o Windows, o perfil, as políticas, os serviços e os programas estavam fazendo durante esses 82 segundos?

---

Anote o horário antes de abrir qualquer log

Faça um novo teste.

Assim que o desktop finalmente aparecer, registre:

logon iniciado: 10:15:20
desktop: 10:16:31
utilizável: 10:16:42

Não precisa ser perfeito.

Uma janela aproximada já ajuda muito.

---

Abra o Visualizador de Eventos

Pressione:

Win + R

execute:

eventvwr.msc

O Visualizador de Eventos possui muitos logs.

Não tente analisar todos.

---

Comece pelo log System

Vá para:

Logs do Windows
→ Sistema

Procure eventos no intervalo do logon.

Observe principalmente eventos relacionados a:

serviços
rede
drivers
armazenamento
Service Control Manager

---

Depois analise Application

Vá para:

Logs do Windows
→ Aplicativo

Procure eventos no mesmo intervalo.

Aqui podem aparecer:

falhas de aplicativos
componentes de perfil
serviços de software
erros de inicialização

---

Não procure somente Error

Inclua:

Critical
Error
Warning
Information

Um evento Information pode mostrar exatamente quando um componente começou ou terminou.

Para diagnóstico de desempenho, tempo e sequência podem ser mais importantes que a cor do ícone.

---

Crie uma Exibição Personalizada

Em vez de percorrer milhares de eventos, use:

Exibições Personalizadas
→ Criar Exibição Personalizada

Defina um intervalo próximo ao teste.

Por exemplo:

10:14 até 10:18

Isso reduz bastante o ruído.

---

O que estamos procurando?

Imagine esta sequência:

10:15:21 → usuário autenticado
10:15:23 → componente A inicia
10:15:24 → tentativa de conexão
10:16:20 → componente A registra falha
10:16:22 → Explorer aparece

Temos um intervalo de quase um minuto associado ao componente A.

Isso não prova sozinho a causa, mas é uma evidência forte para investigar.

---

Service Control Manager merece atenção

No log System, eventos de:

Service Control Manager

podem mostrar serviços que:

falharam
demoraram
não encontraram dependência
não iniciaram corretamente

---

Serviço com erro não significa serviço culpado

Um computador pode registrar um erro de serviço em todos os boots há meses sem apresentar logon lento.

Por isso, compare:

logon lento
versus
logon rápido

Se o mesmo evento aparece nos dois, sua relevância diminui.

---

O teste comparativo é fundamental

Faça:

Teste A → logon lento
Teste B → logon rápido

Depois compare os eventos.

Queremos descobrir o que existe apenas no cenário lento ou o que leva muito mais tempo nele.

---

User Profile Service

Uma área muito importante para nosso problema envolve o serviço de perfil do usuário.

O Windows precisa preparar e carregar o contexto da conta durante o logon.

No Visualizador de Eventos, explore:

Applications and Services Logs
→ Microsoft
→ Windows
→ User Profile Service

Dependendo da instalação e da versão, você encontrará canais disponíveis relacionados ao serviço.

---

O que procurar no perfil?

Eventos próximos ao horário em que:

PIN foi aceito

até:

desktop apareceu

Procure sinais de:

carregamento
falha
tentativas repetidas
acesso a arquivos
problemas relacionados ao perfil

---

Outro usuário rápido torna esse log ainda mais interessante

Imagine:

Victor → 78 s
Teste → 9 s

Agora compare eventos do User Profile Service entre os dois logons.

Isso é muito melhor do que concluir imediatamente:

“perfil corrompido”

---

Um perfil pode estar saudável e ainda assim possuir uma dependência lenta

Por exemplo:

aplicativo específico do usuário
sincronização
script
unidade de rede
configuração

Portanto, o perfil é o escopo do problema, não necessariamente a causa.

---

Verifique também o tamanho, mas com cautela

Você pode examinar:

C:\Users\Usuario

mas não use:

perfil grande = perfil ruim

como regra.

O tamanho total sozinho é pouco informativo.

---

AppData é particularmente importante

Dentro do perfil:

C:\Users\Usuario\AppData

existem dados de inúmeros aplicativos.

Podemos encontrar:

cache
logs
bancos locais
configurações
estado de programas

Mas não apague conteúdo por tentativa.

---

O Windows pode estar esperando Group Policy

Mesmo em computadores que não estão em um domínio corporativo, existem políticas locais.

Em ambientes empresariais, políticas de grupo podem ter participação ainda maior no logon.

Abra:

gpresult /r

Isso permite observar informações sobre políticas aplicadas ao usuário e computador.

---

Para relatório mais completo

Você pode gerar:

gpresult /h "%USERPROFILE%\Desktop\gpresult.html"

Depois abra o arquivo HTML.

Ele ajuda a documentar políticas aplicadas.

---

Não altere políticas ainda

Primeiro descubra:

quais existem
quais se aplicam ao usuário
quais podem depender da rede

---

Scripts de logon merecem investigação

Em ambientes empresariais, um script pode executar durante a entrada do usuário.

Ele pode tentar:

mapear unidade
acessar servidor
executar programa
copiar arquivo
configurar impressora
consultar rede

Se um recurso deixou de existir, o script pode esperar um timeout.

---

Um script aparentemente simples pode causar grande atraso

Imagine:

conectar \\SERVIDOR-ANTIGO\Dados

O servidor não responde.

O script espera.

Depois de algum tempo:

falha
↓
continua
↓
desktop aparece

Para o usuário:

“Windows ficou 50 segundos em Bem-vindo”

---

Teste sem rede novamente

Se:

com rede → 70 s
sem rede → 10 s

não significa necessariamente que um script de rede seja culpado.

Mas aumenta a prioridade de investigar:

GPO
scripts
unidades mapeadas
aplicativos de rede
DNS
autenticação

---

Analise unidades persistentes

Execute:

net use

Procure caminhos que apontem para:

servidores antigos
NAS desligados
nomes que não resolvem
recursos corporativos fora da rede

---

Unidade com X vermelho não prova a causa

O Windows pode manter uma unidade desconectada sem que ela necessariamente atrase o logon.

Precisamos correlacionar.

Teste:

unidade presente + logon lento

versus:

unidade removida temporariamente + logon rápido

apenas quando a remoção for segura e autorizada.

---

Não remova unidade corporativa sem saber sua função

Em empresa, o mapeamento pode vir de:

GPO
script
software

Removê-lo manualmente pode fazer com que ele simplesmente volte no próximo logon.

Nesse caso, precisamos descobrir quem o cria.

---

Task Scheduler: procure tarefas “At log on”

Abra:

taskschd.msc

Examine tarefas relevantes.

Procure gatilhos como:

At log on
Ao fazer logon

---

Observe a ação da tarefa

A tarefa pode iniciar:

EXE
PowerShell
CMD
script
atualizador
sincronizador

Registre:

nome
gatilho
ação
horário da última execução
resultado

---

Não confunda tarefa que inicia no logon com tarefa que bloqueia o logon

Muitas tarefas executam normalmente em segundo plano.

Precisamos descobrir se existe relação temporal com o atraso.

---

Histórico do Agendador ajuda

Quando disponível e habilitado, o histórico da tarefa pode mostrar:

quando disparou
quando executou
quando terminou
resultado

Compare com seu cronômetro.

---

Event Viewer também possui logs do Task Scheduler

Explore:

Applications and Services Logs
→ Microsoft
→ Windows
→ TaskScheduler

Correlacione os eventos com o intervalo lento.

---

Uma tarefa pode iniciar um processo que espera rede

Exemplo:

Logon
↓
Tarefa inicia BackupCliente.exe
↓
BackupCliente tenta alcançar servidor
↓
espera

O Task Scheduler pode ser apenas o iniciador.

A verdadeira espera acontece dentro do programa.

---

Autoruns complementa o Agendador

No Autoruns, a guia:

Logon

é especialmente interessante.

Ela pode mostrar itens associados ao início da sessão.

---

Procure entradas de terceiros

Exemplos:

atualizadores
software de impressora
clientes de nuvem
VPN
utilitários OEM
backup
launchers

Não desative tudo.

---

Verifique o caminho do executável

Um item de inicialização pode apontar para:

arquivo que não existe
caminho antigo
unidade de rede
programa removido parcialmente

Esse tipo de resíduo merece investigação.

---

Registro: pontos clássicos de inicialização

Alguns programas utilizam chaves como:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

e:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

---

Consulte sem alterar

PowerShell:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

e:

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"

---

HKCU é particularmente interessante quando só um usuário demora

HKCU representa configurações associadas ao usuário atual.

Se:

usuário A → lento
usuário B → rápido

itens específicos do HKCU ganham importância.

---

HKLM afeta um escopo mais amplo

Itens de máquina podem afetar múltiplos usuários.

Se todos apresentam o mesmo atraso, eles entram mais fortemente na investigação.

---

Não apague valores Run diretamente

Primeiro:

documente
identifique o programa
confirme o caminho
teste de forma reversível

Autoruns pode ser mais conveniente para testes controlados.

---

Explorer pode ser a etapa atrasada

Se o Windows sai do “Bem-vindo” mas fica em tela preta com cursor, tente observar quando:

explorer.exe

é iniciado.

Depois que o desktop estiver disponível:

Get-Process explorer | Select-Object Name, Id, StartTime

Isso pode fornecer uma referência temporal útil.

---

StartTime ajuda a reconstruir a sessão

Faça também:

Get-Process |
Sort-Object StartTime |
Select-Object Name, Id, StartTime

Alguns processos protegidos ou contextos específicos podem não fornecer todas as informações sem permissões adequadas, mas a lista ainda pode ser útil.

---

Procure processos iniciados durante o intervalo

Se o logon começou às:

10:15

e o desktop apareceu às:

10:16

observe quais processos têm StartTime nesse intervalo.

---

Isso não prova que o processo causou o atraso

Um processo pode simplesmente ter sido iniciado durante o logon.

Mas a lista cria candidatos.

---

Teste se Explorer já existe durante a tela problemática

Quando possível, se a tela preta permitir:

Ctrl + Shift + Esc

abra o Gerenciador de Tarefas.

Veja se:

Windows Explorer

já está executando.

---

Se explorer.exe ainda não iniciou

A investigação fica concentrada no que acontece antes do shell.

---

Se explorer.exe já está executando

Pode haver:

extensão
componente do shell
I/O
dependência
travamento

afetando a experiência.

---

Não finalize Explorer como primeira tentativa

Reiniciar o Explorer pode fazer o desktop aparecer e parecer uma solução.

Mas precisamos saber por que ele demorou ou travou.

---

Shell extensions entram na investigação

Programas adicionam extensões ao Explorer para:

menu de contexto
sincronização
compactação
antivírus
armazenamento em nuvem
versionamento

Uma extensão problemática pode afetar o shell.

Autoruns pode ajudar a identificar extensões carregadas.

---

Mas nosso sintoma precisa combinar

Se o atraso ocorre ainda em:

Bem-vindo

antes do shell, uma extensão do Explorer talvez não seja a primeira suspeita.

Se:

desktop aparece
Explorer congela
barra demora

ela se torna mais interessante.

---

Observe o disco durante a fase lenta

Se conseguir abrir o Gerenciador de Tarefas, veja:

Disco

Se estiver alto, abra:

resmon.exe

e vá para:

Disco

---

Resource Monitor mostra atividade por arquivo

Isso permite descobrir se determinado processo está lendo ou gravando intensamente em:

AppData
banco local
cache
arquivo de log
Windows
antivírus

---

100% de tempo ativo com poucos MB/s também importa

Um dispositivo pode apresentar alta latência e ficar ocupado sem mostrar uma taxa impressionante de transferência.

Portanto, não analise apenas:

MB/s

Observe também a responsividade do armazenamento.

---

SSD não elimina gargalo de I/O

Um SSD saudável é rápido, mas milhares de operações pequenas, antivírus, banco local ou problemas de armazenamento ainda podem afetar a sessão.

---

Event Viewer e armazenamento

No log System, observe eventos de armazenamento que coincidam com o atraso.

Não conclua que qualquer evento de disco significa SSD defeituoso.

Correlacione:

horário
frequência
sintoma

---

Sincronização pode iniciar junto com o usuário

Serviços de nuvem podem verificar arquivos logo após o logon.

Se o perfil possui grande quantidade de alterações, isso pode gerar atividade.

Mas novamente:

sincronizador aparece no Gerenciador

não significa automaticamente:

sincronizador é culpado

---

Faça teste A/B

Se houver uma forma segura e suportada de impedir temporariamente o início automático daquele aplicativo, faça:

Teste A → habilitado
Teste B → desabilitado

e compare os tempos.

---

Software de impressora também pode iniciar componentes

Utilitários de impressoras podem carregar:

monitor de status
atualizador
scanner
serviço
telemetria

em cada logon.

Em máquinas que acumularam várias instalações antigas, vale identificar os componentes realmente utilizados.

---

VPN pode provocar esperas de rede

Um cliente VPN pode:

inicializar serviço
verificar rede
consultar servidor
carregar filtros
tentar autenticação

Se o atraso muda dependendo da conexão, investigue.

---

Credenciais antigas também podem gerar sintomas indiretos

Abra:

Gerenciador de Credenciais

e examine entradas relacionadas ao recurso suspeito.

Não remova credenciais aleatoriamente.

---

Uma credencial salva pode estar associada a servidor antigo

Exemplo:

SERVIDOR-2019

que não existe mais.

Se algum programa tenta reconectar ao recurso, a combinação de nome antigo + credencial + rede pode contribuir para o atraso.

---

DNS: teste resolução do recurso suspeito

Se existe:

SERVIDOR-ARQUIVOS

use:

nslookup SERVIDOR-ARQUIVOS

ou:

Resolve-DnsName SERVIDOR-ARQUIVOS

conforme o ambiente.

---

Não use DNS público indiscriminadamente em ambiente corporativo

Um domínio interno pode depender do DNS da organização.

Trocar para um resolvedor público por tentativa pode quebrar a resolução de nomes internos e piorar o diagnóstico.

---

“Internet funciona” não elimina DNS interno

Sites públicos podem abrir normalmente enquanto:

servidor.interno

não resolve corretamente.

---

Group Policy em domínio merece cuidado especial

Em computador corporativo, políticas podem depender de:

controlador de domínio
DNS interno
rede corporativa
VPN

O comportamento dentro e fora da empresa pode mudar.

---

Faça uma matriz de ambiente

Situação	Tempo PIN → utilizável
Escritório + cabo	12 s
Casa + Wi-Fi	74 s
Casa sem rede	11 s
Casa + VPN	15 s

Uma tabela assim pode revelar muito mais que dezenas de alterações no Registro.

---

Compare logon lento e rápido no Event Viewer

Esse é um dos testes mais poderosos desta etapa.

Crie:

LOGON LENTO
hora inicial:
hora final:

LOGON RÁPIDO
hora inicial:
hora final:

Depois procure diferenças nos mesmos logs.

---

A primeira diferença temporal é valiosa

Imagine:

rápido:
A → B → C → D

lento:
A → B → tentativa de rede → 45 s → falha → C → D

Agora temos um candidato muito melhor do que simplesmente “programas de inicialização”.

---

Use filtros por horário

No Event Viewer:

Filtrar Log Atual

selecione o intervalo adequado.

Também é possível criar exibições personalizadas para repetir a análise.

---

Anote Source e Event ID

Quando encontrar um evento interessante, registre:

Data/hora
Log
Source
Event ID
Level
Mensagem

Não copie apenas o código.

O contexto da mensagem é importante.

---

Pesquisar Event ID sozinho pode enganar

O mesmo Event ID pode aparecer em contextos diferentes dependendo da fonte.

Pesquise sempre combinando:

Source + Event ID + mensagem

e considere a versão do Windows e o componente envolvido.

---

Event Viewer não é o fim do diagnóstico

Alguns atrasos não deixam um erro claro.

Você pode encontrar:

nenhum evento obviamente errado

mesmo com 60 segundos de espera.

Isso não significa que não exista causa mensurável.

---

É aí que entra o Process Monitor

Na próxima etapa, poderemos capturar atividades como:

Process Start
CreateFile
RegOpenKey
NAME NOT FOUND
PATH NOT FOUND
ACCESS DENIED

e, principalmente, observar o comportamento em torno do intervalo lento.

---

E depois entra o WPR/WPA

Para atrasos de desempenho mais difíceis, Windows Performance Recorder e Windows Performance Analyzer permitem investigar a sessão de forma muito mais profunda.

Podemos analisar:

processos
CPU
I/O
atividade
tempo
dependências

com uma linha temporal.

---

Antes das ferramentas avançadas, feche esta etapa

Você deve conseguir responder:

qual usuário demora?
todos demoram?
qual horário exato?
o atraso acontece em Bem-vindo?
acontece depois do desktop?
muda sem rede?
há GPO?
há script?
há unidade mapeada?
há tarefa no logon?
há processo específico?
há evento correlacionado?

---

Checklist da Parte 2

[ ] Registrei início e fim do logon lento
[ ] Analisei System
[ ] Analisei Application
[ ] Não procurei somente eventos vermelhos
[ ] Analisei User Profile Service
[ ] Comparei outro usuário
[ ] Verifiquei gpresult
[ ] Investiguei scripts quando aplicável
[ ] Listei unidades com net use
[ ] Verifiquei tarefas de logon
[ ] Consultei histórico do Task Scheduler
[ ] Examinei Autoruns
[ ] Consultei HKCU Run
[ ] Consultei HKLM Run
[ ] Observei explorer.exe
[ ] Comparei StartTime de processos
[ ] Observei disco e CPU
[ ] Considerei VPN e sincronização
[ ] Investiguei recursos de rede suspeitos
[ ] Comparei logon lento e rápido
[ ] Registrei Source + Event ID + horário

O principal aprendizado da Parte 2

O Visualizador de Eventos não deve ser usado como uma lista de erros a serem “corrigidos”.

Ele funciona melhor como parte de uma investigação temporal:

10:15:20 → autenticação
10:15:23 → componente inicia
10:15:24 → dependência é solicitada
10:16:18 → dependência falha
10:16:20 → sessão continua
10:16:25 → desktop aparece

Quando combinamos essa linha do tempo com:

User Profile Service
Group Policy
Task Scheduler
Autoruns
unidades mapeadas
rede
StartTime dos processos

o logon lento deixa de ser um sintoma genérico e começa a revelar onde o tempo realmente desaparece.

Process Monitor, Boot Logging e WPR/WPA: como encontrar onde o Windows realmente está esperando

Nas duas primeiras partes, nós fizemos o mais importante: paramos de tratar o problema como “Windows lento” e passamos a medir a fase exata do atraso.

Agora vamos usar ferramentas que conseguem mostrar o que acontece durante o logon em muito mais detalhes.

A meta é sair de algo genérico:

PIN aceito
↓
70 segundos
↓
Área de Trabalho

para algo como:

processo inicia
↓
tenta abrir caminho antigo
↓
não encontra
↓
repete várias vezes
↓
espera rede
↓
continua
↓
Explorer termina de carregar

Ou:

serviço inicia
↓
aplicativo depende dele
↓
serviço ainda não responde
↓
timeout
↓
sessão continua

É nessa etapa que Process Monitor, Windows Performance Recorder e Windows Performance Analyzer se tornam especialmente úteis.

---

Process Monitor: uma das ferramentas mais poderosas para esse diagnóstico

O Process Monitor, ou ProcMon, faz parte da suíte Sysinternals da Microsoft.

Ele registra em tempo real uma enorme quantidade de operações relacionadas a:

arquivos
Registro
processos
threads
atividade do sistema

Isso permite observar o que um processo estava tentando fazer exatamente no momento em que o logon parecia parado.

---

O desafio do ProcMon

Se você simplesmente abrir o Process Monitor e deixar capturando, ele pode registrar centenas de milhares ou milhões de eventos.

Por isso:

Process Monitor sem filtro vira ruído.

Precisamos de uma estratégia.

---

Primeiro, tenha o horário do atraso

Suponha que:

PIN confirmado → 09:20:10
Desktop utilizável → 09:21:22

Nossa janela principal é:

09:20:10 até 09:21:22

Mesmo que a captura seja maior, esse período será o foco.

---

Captura de logon é diferente de abrir o ProcMon depois

Se você abrir o Process Monitor somente quando o desktop finalmente aparecer, poderá perder exatamente o trecho que precisamos investigar.

Para esses casos, existe um recurso muito útil:

Boot Logging

---

O que é Boot Logging no Process Monitor?

O recurso permite que o Process Monitor registre atividade durante a inicialização e fases iniciais da sessão.

Isso é útil quando o problema acontece antes que você consiga abrir a ferramenta manualmente.

---

Ativando o Boot Logging

No Process Monitor, procure a opção relacionada a:

Options
→ Enable Boot Logging

A ferramenta poderá configurar a captura para o próximo ciclo de inicialização.

Depois disso:

reinicie
↓
reproduza o logon lento
↓
abra o Process Monitor
↓
finalize/salve a captura

A interface e os detalhes podem variar conforme a versão do ProcMon, então confirme as opções exibidas na instalação usada.

---

Use apenas durante o diagnóstico

Uma captura de boot pode gerar grande volume de dados.

Depois de obter a evidência necessária, desative o recurso.

---

Salve a captura antes de filtrar demais

Após reproduzir o problema, salve a captura original.

Assim você mantém:

dados brutos

e pode criar filtros diferentes posteriormente.

Isso é melhor do que capturar novamente toda vez que muda de hipótese.

---

Nomeie as capturas

Por exemplo:

logon-lento-01.pml
logon-rapido-01.pml

A comparação entre as duas será extremamente importante.

---

Faça uma captura de logon rápido também

Se você possui uma condição em que o problema desaparece, aproveite.

Exemplo:

com rede → lento
sem rede → rápido

Capture ambos.

Agora você consegue comparar:

BAD
versus
GOOD

---

O objetivo é encontrar a primeira divergência

Imagine:

GOOD:
A
B
C
D
desktop

e:

BAD:
A
B
C
tentativa X
tentativa X
tentativa X
espera
D
desktop

O evento X passa a ser um candidato muito forte.

---

Comece filtrando pelo horário

Não tente interpretar a captura inteira.

Concentre-se inicialmente na janela do atraso.

---

Depois filtre por processo

Se o Event Viewer ou Autoruns já apontaram um programa suspeito:

BackupCliente.exe

crie um filtro para esse processo.

Por exemplo, conceitualmente:

Process Name
is
BackupCliente.exe

---

O que procurar nos resultados?

Alguns resultados aparecem com frequência:

SUCCESS
NAME NOT FOUND
PATH NOT FOUND
ACCESS DENIED
SHARING VIOLATION

Mas não trate qualquer falha como causa.

---

NAME NOT FOUND pode ser normal

Aplicativos frequentemente procuram:

configuração A
configuração B
configuração C

até encontrar o caminho correto.

Por isso, milhares de:

NAME NOT FOUND

não significam automaticamente problema.

---

O que torna um NAME NOT FOUND interessante?

Quando existe:

repetição
+
mesmo caminho
+
mesmo período
+
correlação com atraso

Exemplo:

\\SERVIDOR-ANTIGO\Sistema\config.ini

aparecendo repetidamente durante 40 segundos.

Agora temos algo muito mais relevante.

---

PATH NOT FOUND pode revelar configuração antiga

Um software pode tentar acessar:

D:\ProgramaAntigo\Dados

mas a pasta não existe mais.

Se isso se repete durante o logon, investigue de onde o caminho está vindo.

---

ACCESS DENIED também exige contexto

Se um processo tenta abrir:

arquivo protegido do sistema

e recebe ACCESS DENIED, isso pode ser normal.

Mas se ele tenta acessar repetidamente:

C:\Users\Usuario\AppData\...

e fica preso na sequência, a relevância aumenta.

---

Use o detalhe do evento

Ao abrir um evento no ProcMon, examine informações como:

Process
Operation
Path
Result
Detail

O campo Detail pode fornecer informações úteis sobre a operação.

---

Process Start é particularmente importante

Filtre eventos relacionados a:

Process Start

Isso ajuda a reconstruir:

quem iniciou
o quê
quando

---

Processo pai pode revelar o iniciador

Imagine:

Updater.exe

foi iniciado por:

explorer.exe

ou por:

taskeng.exe

ou outro componente relacionado a tarefas/serviços.

Isso ajuda a localizar a origem.

---

Não investigue apenas o processo final

Talvez o processo lento seja consequência de:

tarefa agendada
script
serviço
launcher

O processo pai ajuda a reconstruir essa cadeia.

---

Process Tree também ajuda

O Process Monitor possui recursos para visualizar a árvore de processos capturada.

Isso pode esclarecer relações como:

winlogon
↓
userinit
↓
explorer
↓
programa

ou outras cadeias específicas observadas na máquina.

---

Não altere componentes centrais por causa dessa árvore

Processos do Windows fazem parte de uma cadeia complexa de logon.

Use a informação para diagnóstico, não para sair desativando componentes essenciais.

---

Procure operações demoradas

Além dos resultados, observe a duração das operações quando disponível.

Um padrão interessante é:

operações rápidas
↓
uma operação ou sequência muito mais demorada
↓
sessão continua

---

Timeouts podem aparecer como ausência de atividade óbvia

Nem toda espera aparece como um evento isolado de 40 segundos.

Às vezes você observa:

atividade
↓
grande intervalo
↓
atividade retorna

Esse “buraco temporal” merece atenção.

---

O que aconteceu logo antes do buraco?

Essa é uma excelente pergunta.

Se imediatamente antes vemos:

tentativa de acessar servidor

e depois existe silêncio até o processo continuar, temos uma hipótese.

---

Use Highlight para marcar eventos suspeitos

Em vez de remover tudo, você pode destacar:

ACCESS DENIED
PATH NOT FOUND
processo específico
caminho específico

Isso preserva o contexto.

---

Rede no ProcMon não é o único caminho

O Process Monitor é excelente para arquivos, Registro e processos, mas não substitui uma captura completa de rede quando o problema está em DNS, SMB ou outro protocolo.

Por isso, combine evidências.

---

Se o logon muda drasticamente sem rede

Volte à hipótese:

dependência de rede

Agora use ferramentas específicas para validar o recurso.

---

Exemplo: servidor SMB

Test-NetConnection SERVIDOR -Port 445

Se falha, isso pode explicar uma tentativa de reconexão lenta.

---

Exemplo: resolução DNS

Resolve-DnsName SERVIDOR

Se o nome demora ou falha, investigue o DNS usado pela máquina.

---

Evite “corrigir” trocando DNS sem evidência

Especialmente em redes corporativas, DNS interno pode ser essencial.

Primeiro identifique qual nome está falhando e quem deveria resolvê-lo.

---

Process Monitor pode revelar chaves de Registro de inicialização

Filtre por operações de Registro e observe programas consultando:

Run
RunOnce
configurações do usuário
configurações de aplicativo

Mas não conclua que cada acesso ao Registro é um problema.

---

O padrão repetitivo é mais importante

Por exemplo:

RegOpenKey
NAME NOT FOUND
RegOpenKey
NAME NOT FOUND
RegOpenKey
NAME NOT FOUND

repetido milhares de vezes pelo mesmo processo durante o atraso pode justificar uma investigação específica.

---

Compare GOOD e BAD

Uma estratégia excelente:

Capture 1:
logon rápido

Capture 2:
logon lento

Agora compare:

processos iniciados
caminhos acessados
operações repetidas
intervalos

---

O mesmo processo pode aparecer nos dois testes

Isso não elimina a hipótese.

Talvez no GOOD ele leve:

0,5 s

e no BAD:

45 s

O comportamento, não apenas a presença, é o que importa.

---

Boot Logging não substitui cronômetro

Mesmo com milhões de eventos, continue registrando:

hora do PIN
hora do desktop
hora utilizável

Isso permite encontrar rapidamente o trecho certo.

---

Windows Performance Recorder: quando o ProcMon não basta

O WPR, Windows Performance Recorder, permite coletar traces de desempenho do Windows.

Ele faz parte das ferramentas de análise de desempenho da Microsoft.

Para problemas difíceis, ele pode oferecer uma visão temporal muito mais rica.

---

Windows Performance Analyzer

O WPA, Windows Performance Analyzer, é usado para abrir e analisar as capturas geradas.

Com ele, você pode explorar:

CPU
I/O
processos
threads
atividade temporal

dependendo do perfil de captura.

---

WPR/WPA não são ferramentas para “clicar até achar um erro”

Elas exigem uma pergunta clara.

No nosso caso:

Qual componente está consumindo ou esperando tempo durante o intervalo entre autenticação e desktop utilizável?

---

Instalação

WPR e WPA podem ser obtidos como parte das ferramentas de desempenho do Windows disponíveis no Windows Assessment and Deployment Kit, dependendo da versão utilizada.

Use sempre a distribuição oficial da Microsoft e compatível com o Windows analisado.

---

Capture o cenário ruim

A sequência conceitual é:

iniciar trace
↓
reproduzir o problema
↓
parar trace
↓
salvar ETL
↓
abrir no WPA

Para problemas relacionados ao boot/logon, os perfis disponíveis podem incluir cenários específicos de inicialização.

Use o perfil adequado à versão instalada.

---

Não capture horas sem necessidade

Um trace enorme dificulta a análise.

O ideal é capturar apenas o período necessário para reproduzir o comportamento.

---

No WPA, pense em linha do tempo

Você quer localizar:

início do logon
↓
período lento
↓
desktop

e observar o que mudou nesse intervalo.

---

CPU Usage

Uma das primeiras visões pode ser:

CPU Usage

Pergunte:

qual processo usa CPU?
durante quanto tempo?
é contínuo?
é um pico?

---

CPU alta durante o atraso

Se:

ProcessoX

consome um núcleo ou vários núcleos durante todo o período lento, investigue esse processo.

---

CPU baixa não inocenta o processo

Se a máquina fica esperando:

I/O
rede
sincronização
evento
mutex
outro processo

o uso de CPU pode ficar baixo.

---

Disk I/O

Observe atividade de disco.

Pergunte:

qual processo lê?
qual processo grava?
qual arquivo?

---

Muitas pequenas operações podem ser significativas

Um processo pode realizar milhares de acessos em:

AppData
cache
banco SQLite
arquivos temporários

durante a entrada do usuário.

---

SSD saudável pode sofrer com comportamento de software

A presença de SSD não torna todos os acessos instantâneos.

O problema pode ser:

volume de operações
latência
fila
aplicativo
antivírus

e não velocidade sequencial do SSD.

---

Compare tempo de CPU e tempo total

Se um processo demora:

50 s

mas usa apenas:

2 s de CPU

provavelmente grande parte do tempo está sendo gasta esperando algo.

Isso direciona o diagnóstico.

---

Wait Chain pode complementar

O Windows e ferramentas como Process Explorer podem ajudar em determinados cenários a observar cadeias de espera entre processos/threads.

Isso é especialmente útil quando:

programa parece congelado

mas não consome CPU.

---

Process Explorer durante o desktop lento

Se o shell já apareceu, abra Process Explorer.

Observe:

process tree
CPU
I/O
handles
threads

---

Um processo “Not Responding” é uma pista, não uma sentença

Pergunte:

ele está aguardando o quê?

---

Se o problema é explorer.exe

Investigue:

extensões
rede
pastas recentes
Quick Access
unidades
sincronização
shell extensions

Mas use evidência antes de desabilitar componentes.

---

Quick Access pode tentar referências indisponíveis?

Dependendo do cenário, referências a locais indisponíveis podem participar de comportamentos lentos do Explorer.

Se o problema surge depois que o shell aparece e desaparece ao eliminar determinada referência, isso pode ser relevante.

Mas não transforme isso em diagnóstico padrão.

---

Se o problema é aplicativo de nuvem

Compare:

sincronização habilitada
versus
temporariamente pausada

somente se o software oferecer método seguro para o teste.

Cronometre.

---

Se o problema é VPN

Compare:

serviço/cliente VPN normal

com um teste controlado conforme a política da máquina.

Se a máquina é corporativa, não desabilite componentes de segurança sem autorização.

---

Se o problema parece serviço

Volte ao Event Viewer.

Correlacione:

Service Control Manager
StartTime
eventos
trace

Um único dado não deve carregar toda a conclusão.

---

Teste de inicialização limpa

Quando vários programas de terceiros participam do logon e não existe um candidato claro, uma inicialização limpa pode ajudar a separar:

Windows
versus
software de terceiros

Mas deve ser feita de forma controlada.

---

Não desative serviços Microsoft indiscriminadamente

Em msconfig, uma abordagem segura de diagnóstico normalmente exige separar serviços Microsoft dos serviços de terceiros antes de realizar testes.

Documente tudo que mudar.

---

O resultado mais útil de uma inicialização limpa

Cenário A

normal → 75 s
clean boot → 9 s

Agora sabemos que algum componente desativado tem forte relação com o atraso.

---

Não reative tudo de uma vez

Use divisão por grupos:

metade A
metade B

e repita os testes.

Isso aproxima um processo de busca binária.

---

Exemplo

Você tem 20 itens de terceiros.

Ative 10.

logon lento

O culpado provavelmente está nesse grupo.

Divida novamente:

5 + 5

Até reduzir.

---

Isso é muito melhor que testar 20 itens aleatoriamente

Mantém:

método
evidência
repetibilidade

---

Outro usuário rápido + clean boot rápido

Essa combinação sugere que tanto elementos do usuário quanto componentes de terceiros merecem análise.

Não conclua ainda.

---

Outro usuário rápido + clean boot continua lento no usuário principal

Agora o foco pode se aproximar mais de:

perfil
HKCU
dados específicos
tarefas específicas do usuário

---

Todos os usuários lentos + clean boot rápido

Isso sugere componente de terceiros com escopo de máquina.

---

Todos lentos mesmo em clean boot

Agora dê mais atenção a:

drivers
armazenamento
serviços essenciais
perfil compartilhado
políticas
rede
Windows

---

Modo de Segurança pode ser comparativo

Se o sistema entra rapidamente em Modo de Segurança, isso mostra que o conjunto reduzido de drivers e serviços muda o comportamento.

Mas novamente:

Safe Mode rápido

não identifica sozinho o culpado.

É uma pista de isolamento.

---

Não use SFC e DISM como primeira etapa

Comandos como:

sfc /scannow

e:

DISM /Online /Cleanup-Image /RestoreHealth

são úteis quando existe evidência de corrupção do Windows.

Mas um logon lento provocado por:

servidor inexistente
aplicativo
script
unidade mapeada

não será diagnosticado simplesmente executando reparos do sistema.

---

Reparar Windows não substitui identificar a espera

Primeiro descubra:

onde o tempo desaparece

Depois escolha a correção adequada.

---

Comparação GOOD/BAD completa

Uma planilha simples pode ficar assim:

Item	Logon rápido	Logon lento
Usuário	Teste	Victor
Rede	desconectada	conectada
PIN → Desktop	8 s	71 s
Unidade Z:	não usada	tentativa
Processo X	0,4 s	48 s
Servidor antigo	nenhuma tentativa	várias
CPU	baixa	baixa
Disco	baixo	baixo

Isso aponta claramente para espera, não para falta de CPU ou SSD lento.

---

Outro exemplo

Item	Rápido	Lento
PIN → Desktop	9 s	88 s
CPU	10%	90%
Processo	normal	IndexadorApp.exe
Disco	moderado	alto
Rede	igual	igual

Agora o caminho é totalmente diferente.

---

Outro exemplo

Item	Rápido	Lento
Outro usuário	8 s	—
Usuário principal	—	75 s
HKCU Run	3 itens	18 itens
Aplicativo Y	ausente	presente
Desabilita Y	9 s	—

A evidência converge para o aplicativo Y.

---

Registre a hipótese

Em vez de:

“acho que é o OneDrive”

escreva:

Hipótese:
Cliente de sincronização está aumentando o logon.

Evidências:
- só ocorre no usuário principal
- processo inicia durante o atraso
- I/O alto em AppData
- desativação temporária reduz 72 s para 11 s

Isso é muito mais forte.

---

Depois procure a causa dentro do aplicativo

Mesmo que um programa seja o componente envolvido, ainda existe uma pergunta:

por que ele está demorando?

Pode ser:

banco local
rede
cache
conta
arquivo corrompido
plugin
atualização

---

Não desinstale imediatamente

Primeiro veja se existe:

configuração
atualização
reparo
recriação de cache suportada

adequada ao programa.

---

Captura de rede pode ser necessária

Se o ProcMon e WPR indicam uma espera de rede, uma análise de rede pode aprofundar a causa.

Nesse ponto, ferramentas como Wireshark podem ser úteis em ambiente técnico.

O objetivo pode ser descobrir:

DNS repetido
TCP sem resposta
SMB
timeout

---

Não capture credenciais sensíveis desnecessariamente

Capturas de rede e traces podem conter informações do ambiente.

Proteja os arquivos e compartilhe apenas quando necessário.

---

O diagnóstico ideal combina três tipos de evidência

1. experiência
   cronômetro

2. eventos
   Event Viewer

3. atividade
   ProcMon / WPR

Quando os três apontam para o mesmo componente, a conclusão fica muito mais forte.

---

Procedimento da Parte 3

1. registre horário do logon lento
2. obtenha uma captura ruim
3. obtenha uma captura rápida se possível
4. salve os PML originais
5. filtre pelo período
6. analise Process Start
7. identifique processos iniciados
8. procure repetições
9. procure caminhos antigos
10. procure PATH NOT FOUND
11. procure ACCESS DENIED relevante
12. observe buracos temporais
13. compare GOOD/BAD
14. valide rede se houver suspeita
15. use WPR/WPA se necessário
16. observe CPU
17. observe I/O
18. diferencie processamento de espera
19. faça teste A/B
20. repita para confirmar

---

O que não fazer

Evite:

filtrar apenas ACCESS DENIED

e concluir que encontrou a causa.

Evite:

apagar todos os NAME NOT FOUND

— eles não são arquivos que precisam ser “corrigidos”.

Evite desativar serviços críticos.

Evite alterar drivers aleatoriamente.

Evite aplicar cinco correções ao mesmo tempo.

---

Uma mudança por teste

Esse princípio é fundamental.

Se você:

desativa 10 programas
troca DNS
remove unidade mapeada
atualiza driver
limpa perfil

e o problema desaparece, não sabe qual mudança resolveu.

---

Prefira:

hipótese
↓
uma alteração
↓
medição
↓
comparação

---

Checklist da Parte 3

[ ] Tenho o horário exato do atraso
[ ] Salvei captura original do ProcMon
[ ] Fiz Boot Logging quando necessário
[ ] Capturei cenário GOOD
[ ] Capturei cenário BAD
[ ] Comparei Process Start
[ ] Observei processos pais
[ ] Procurei repetições
[ ] Não tratei todo NAME NOT FOUND como erro
[ ] Não tratei todo ACCESS DENIED como causa
[ ] Procurei grandes intervalos temporais
[ ] Validei caminhos de rede suspeitos
[ ] Usei Test-NetConnection quando aplicável
[ ] Usei Resolve-DnsName quando aplicável
[ ] Considerei WPR/WPA
[ ] Observei CPU
[ ] Observei I/O
[ ] Diferenciei processamento de espera
[ ] Fiz testes A/B
[ ] Alterei uma variável de cada vez

O principal aprendizado da Parte 3

Quando um logon demora 60 ou 90 segundos, a pergunta não deve ser:

“Qual programa devo desativar?”

A pergunta correta é:

O que aconteceu durante esses 60 ou 90 segundos que não acontece durante um logon rápido?

O Process Monitor ajuda a encontrar:

processos
arquivos
Registro
caminhos inexistentes
negações
repetições

Enquanto WPR/WPA ajudam a analisar:

tempo
CPU
I/O
processos
esperas

O melhor diagnóstico nasce da comparação:

GOOD
versus
BAD

e da busca pela primeira divergência relevante.

Depois de separar boot, autenticação, logon, perfil, shell e pós-logon, já temos uma metodologia sólida para investigar a demora entre digitar a senha e realmente conseguir usar a Área de Trabalho.

Agora vamos transformar tudo em um procedimento prático.

A ideia é evitar diagnóstico por tentativa e erro.

---

Procedimento definitivo em 30 etapas

1. Reinicie o computador

Use:

Reiniciar

para começar com um cenário comparável.

---

2. Meça Power → tela de logon

Registre:

Power → Logon = X segundos

---

3. Meça PIN/senha → Área de Trabalho

Anote:

PIN → Desktop = X segundos

---

4. Meça até a sessão realmente ficar utilizável

Teste:

Menu Iniciar
Explorer
navegador
barra de tarefas

Registre:

PIN → Utilizável = X segundos

---

5. Identifique exatamente onde aparece a demora

Classifique:

Bem-vindo
tela preta
Explorer
barra de tarefas
desktop visível, mas lento

---

6. Repita o teste

Faça pelo menos mais uma ou duas medições.

Não baseie a conclusão em um único logon.

---

7. Teste outro usuário

Compare:

Usuário A
versus
Usuário B

Se apenas um usuário demora, aumente a prioridade de:

perfil
HKCU
tarefas do usuário
programas
sincronização

---

8. Teste com e sem rede

Compare:

rede conectada
versus
rede desconectada

Se houver grande diferença, investigue:

DNS
SMB
unidades
scripts
VPN
servidores

---

9. Compare reiniciar com logoff/logon

Faça:

Reiniciar → entrar

e depois:

Sair → entrar

A diferença ajuda a separar componentes ligados ao boot dos ligados à criação da sessão.

---

10. Registre o horário exato

Anote:

início
desktop
fim da lentidão

Esse intervalo será usado no Event Viewer e nas capturas.

---

11. Analise System

Abra:

eventvwr.msc

e examine:

Windows Logs
→ System

no intervalo correto.

---

12. Analise Application

Depois:

Windows Logs
→ Application

Procure eventos temporalmente relacionados ao atraso.

---

13. Analise User Profile Service

Investigue logs relacionados ao serviço de perfil.

Compare principalmente se:

um usuário demora
outro não

---

14. Examine Group Policy

Execute:

gpresult /r

Quando necessário:

gpresult /h "%USERPROFILE%\Desktop\gpresult.html"

Procure políticas e scripts relevantes.

---

15. Liste unidades de rede

Execute:

net use

Procure recursos antigos ou indisponíveis.

---

16. Teste recursos suspeitos

Para SMB:

Test-NetConnection SERVIDOR -Port 445

Para DNS:

Resolve-DnsName SERVIDOR

---

17. Examine tarefas de logon

Abra:

taskschd.msc

e procure gatilhos:

Ao fazer logon
At log on

---

18. Examine Autoruns

Observe principalmente:

Logon
Scheduled Tasks
Services
Explorer

Identifique itens de terceiros e caminhos antigos.

---

19. Consulte entradas Run

PowerShell:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

e:

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"

---

20. Observe processos iniciados no período

Depois do logon:

Get-Process |
Sort-Object StartTime |
Select-Object Name, Id, StartTime

Procure processos que surgiram durante o intervalo lento.

---

21. Observe CPU e disco

Abra:

Gerenciador de Tarefas

e, se necessário:

resmon.exe

Identifique:

CPU alta
Disco alto
rede
processo
arquivo

---

22. Capture com Process Monitor

Se o problema ainda não estiver claro, use ProcMon.

Quando necessário, use:

Boot Logging

para capturar a fase inicial da sessão.

---

23. Salve a captura original

Exemplo:

logon-lento.pml

Não filtre e descarte a captura original.

---

24. Faça uma captura rápida para comparação

Se houver um cenário sem problema:

logon-rapido.pml

Agora compare:

GOOD
versus
BAD

---

25. Procure a primeira divergência

Observe:

Process Start
PATH NOT FOUND
NAME NOT FOUND
ACCESS DENIED
repetições
intervalos longos

Não trate cada erro isolado como causa.

---

26. Use WPR/WPA para casos difíceis

Quando a causa ainda estiver obscura, capture o desempenho.

Observe:

CPU
I/O
processos
tempo

e concentre-se no intervalo lento.

---

27. Formule uma hipótese

Exemplo:

Hipótese:
cliente de backup espera um servidor indisponível.

Evidências:
- problema desaparece sem rede
- processo inicia no logon
- ProcMon mostra tentativas repetidas
- servidor não responde na porta 445

---

28. Altere uma única variável

Exemplo:

desabilitar temporariamente apenas o item suspeito

---

29. Reinicie e meça novamente

Compare:

antes = 78 s
depois = 11 s

---

30. Repita para confirmar

Se o resultado se mantém, temos uma evidência muito mais confiável.

---

Árvore de decisão

Windows chega rápido à tela de logon?
│
├─ Não
│  └─ Investigue boot, drivers, serviços e firmware
│
└─ Sim
   │
   ├─ Demora depois do PIN?
   │  │
   │  ├─ Não
   │  │  └─ Investigue fase pós-desktop
   │  │
   │  └─ Sim
   │     │
   │     ├─ Outro usuário entra rápido?
   │     │  │
   │     │  ├─ Sim
   │     │  │  └─ Perfil, HKCU, apps, tarefas, sync
   │     │  │
   │     │  └─ Não
   │     │     └─ Sistema, serviços, rede, drivers
   │     │
   │     ├─ Sem rede fica rápido?
   │     │  │
   │     │  ├─ Sim
   │     │  │  └─ DNS, SMB, GPO, VPN, scripts
   │     │  │
   │     │  └─ Não
   │     │     └─ Continue investigação local
   │     │
   │     ├─ CPU alta?
   │     │  └─ Identifique o processo
   │     │
   │     ├─ Disco alto?
   │     │  └─ Identifique processo e arquivo
   │     │
   │     └─ CPU e disco baixos?
   │        └─ Investigue espera, timeout, rede e dependências

---

Cenário 1 — Fica 60 segundos em Bem-vindo

Sintoma:

PIN
↓
Bem-vindo por 60 s
↓
desktop normal

Outro usuário entra rápido.

Prioridades:

perfil
HKCU
programas do usuário
tarefas
sincronização

---

Cenário 2 — Sem Internet entra instantaneamente

Resultado:

com rede = 70 s
sem rede = 9 s

Investigue:

servidor antigo
DNS
unidade mapeada
script
VPN
software empresarial

---

Cenário 3 — Desktop aparece, mas nada responde

Sintoma:

desktop aparece
barra trava
Explorer demora
aplicativos não abrem

Observe:

CPU
I/O
Explorer
sincronização
antivírus
processos

---

Cenário 4 — Tela preta com cursor

Sequência:

Bem-vindo
↓
tela preta
↓
cursor
↓
Explorer aparece

Investigue a transição para o shell.

Compare:

StartTime do explorer.exe
eventos
ProcMon
extensões
dependências

---

Cenário 5 — Apenas primeiro logon após reiniciar demora

Resultado:

após reboot = 80 s
logoff/logon = 10 s

Considere:

serviços
tarefas de startup
rede inicial
antivírus
indexação
atualizadores

---

Cenário 6 — Todos os usuários demoram

Resultado:

Usuário A = 70 s
Usuário B = 69 s

A investigação passa a priorizar:

sistema
serviços
drivers
armazenamento
rede
software global

---

Cenário 7 — Disco em 100% durante o logon

Não conclua:

SSD ruim

Descubra primeiro:

qual processo
qual arquivo
qual tipo de I/O

Use Resource Monitor, ProcMon e, se necessário, WPA.

---

Cenário 8 — CPU baixa e nenhuma atividade evidente

Esse é um cenário clássico de espera.

Pode existir:

timeout de rede
espera de serviço
mutex
IPC
servidor indisponível

ProcMon e análise temporal ficam mais importantes.

---

Cenário 9 — Cliente VPN participa do atraso

Se o programa VPN:

inicia
tenta detectar rede
tenta autenticar
espera

compare o comportamento conforme a política de uso da máquina.

Em ambiente corporativo, não desative componentes de segurança sem autorização.

---

Cenário 10 — Unidade de rede antiga

Imagine:

Z: → \\SERVIDOR-ANTIGO\Documentos

O servidor não existe.

Se a sessão tenta reconectar essa unidade, o usuário pode ficar esperando até a tentativa falhar.

---

Cenário 11 — Aplicativo de sincronização

Se apenas determinado usuário demora e há forte I/O em:

AppData
pasta sincronizada
banco local

investigue o cliente de sincronização.

Não apague a pasta inteira por tentativa.

---

Cenário 12 — Programa de terceiros no Autoruns

Você identifica:

UtilitarioOEM.exe

no logon.

Teste A/B:

habilitado = 65 s
desabilitado = 10 s
habilitado novamente = 64 s

Essa repetibilidade é uma evidência muito forte.

---

Quando o problema é realmente o perfil?

Considere essa hipótese quando várias evidências convergem:

apenas um usuário
outro usuário funciona
clean boot não resolve
itens do HKCU não explicam
dados do perfil apresentam comportamento anormal

Mesmo assim, prefira identificar o componente afetado antes de simplesmente apagar o perfil.

---

Criar outro perfil é diagnóstico ou solução?

Pode ser ambos.

Como diagnóstico:

novo usuário rápido

mostra que o problema tem relação com o contexto do usuário antigo.

Como solução definitiva, depende do caso.

Migrar perfil sem entender a causa pode carregar configurações problemáticas para a conta nova.

---

Quando usar SFC?

Use:

sfc /scannow

quando existirem indícios de arquivos de sistema corrompidos ou componentes do Windows comprometidos.

Não como primeira tentativa para qualquer logon lento.

---

Quando usar DISM?

Em cenários de corrupção do Windows:

DISM /Online /Cleanup-Image /ScanHealth

e, quando indicado:

DISM /Online /Cleanup-Image /RestoreHealth

O DISM não resolve um servidor SMB inexistente nem um aplicativo esperando rede.

---

Quando reinstalar o Windows?

A reinstalação deve ficar muito depois de:

medição
isolamento
eventos
comparação
ProcMon
WPR/WPA

Se o problema é provocado por um software ou configuração que será reinstalado depois, formatar pode apenas ocultar a causa temporariamente.

---

FAQ — Windows 11 demora depois de digitar a senha

1. Por que o Windows 11 demora em “Bem-vindo”?

Porque vários componentes ainda podem estar preparando a sessão do usuário, carregando perfil, políticas, programas, serviços ou recursos de rede.

---

2. Isso significa que o SSD está ruim?

Não necessariamente. Um SSD defeituoso pode causar lentidão, mas logon lento também pode resultar de software, rede, perfil e esperas.

---

3. Como saber se o problema está no perfil?

Compare com outro usuário. Se outra conta entra rapidamente, investigue itens específicos do usuário.

---

4. Devo apagar o perfil?

Não como primeira medida.

---

5. Um perfil grande demora mais?

Não existe relação simples. O que importa é o que está sendo acessado e processado durante o logon.

---

6. Por que sem Internet o Windows entra mais rápido?

Isso pode indicar dependência de rede, servidor indisponível, DNS, unidade mapeada, script, VPN ou aplicativo.

---

7. Internet rápida elimina problema de rede?

Não. Um recurso específico pode estar indisponível mesmo com conexão rápida.

---

8. O Ping é suficiente para testar servidor?

Não. Para SMB, por exemplo, você também pode verificar a porta TCP 445.

---

9. Como testar porta 445?

Test-NetConnection SERVIDOR -Port 445

---

10. Como ver unidades mapeadas?

net use

---

11. O Windows pode esperar servidor que não existe mais?

Sim. Programas, scripts e unidades persistentes podem tentar recursos antigos.

---

12. Devo remover todas as unidades mapeadas?

Não. Identifique primeiro as suspeitas.

---

13. Task Scheduler pode causar logon lento?

Uma tarefa disparada no logon pode iniciar um processo que contribui para o atraso.

---

14. Autoruns é melhor que Gerenciador de Tarefas?

Ele mostra mais pontos de inicialização e serve muito bem para diagnóstico avançado.

---

15. Posso desabilitar tudo no Autoruns?

Não. Faça alterações seletivas e documentadas.

---

16. O que é HKCU Run?

É uma área do Registro onde programas podem configurar inicialização associada ao usuário atual.

---

17. O que é HKLM Run?

É uma área de inicialização com escopo de máquina.

---

18. O Process Monitor pode capturar o logon?

Sim. O Boot Logging pode ajudar quando o problema acontece antes que seja possível abrir o ProcMon normalmente.

---

19. Todo ACCESS DENIED do ProcMon é problema?

Não.

---

20. Todo NAME NOT FOUND é erro?

Não. Muitos aplicativos procuram diversos caminhos normalmente.

---

21. O que torna um erro do ProcMon suspeito?

Repetição, duração, mesmo processo, mesmo caminho e correlação com o intervalo lento.

---

22. O que é captura GOOD/BAD?

É comparar uma sessão rápida com uma sessão lenta para encontrar diferenças.

---

23. Por que comparar é tão importante?

Porque elimina muitos eventos normais que aparecem nos dois cenários.

---

24. Para que serve o WPR?

Para gravar traces de desempenho do Windows.

---

25. Para que serve o WPA?

Para analisar as capturas de desempenho em uma linha temporal.

---

26. CPU baixa significa que nada está errado?

Não. Pode haver espera de rede, I/O, serviço ou outro recurso.

---

27. CPU alta ajuda?

Sim. Identifique qual processo consome CPU durante o atraso.

---

28. Disco em 100% é defeito?

Não necessariamente.

---

29. Resource Monitor ajuda?

Sim. Ele mostra atividade por processo e arquivo.

---

30. Process Explorer ajuda?

Sim, especialmente para observar árvore de processos, threads, handles e atividade.

---

31. Tela preta significa driver de vídeo?

Não automaticamente.

---

32. Explorer.exe pode ser a causa?

Pode participar do problema, mas precisa ser investigado.

---

33. Shell extensions podem atrasar o Explorer?

Sim, dependendo do componente e do cenário.

---

34. OneDrive pode causar demora?

Qualquer cliente de sincronização pode contribuir em determinadas situações, mas é preciso medir antes de concluir.

---

35. Antivírus pode atrasar o logon?

Pode haver casos de atividade intensa, mas não desative a proteção permanentemente sem evidência.

---

36. Clean boot é útil?

Sim, para separar software de terceiros do conjunto normal do Windows.

---

37. Devo desativar serviços Microsoft no clean boot?

Evite desativá-los indiscriminadamente.

---

38. Modo de Segurança ajuda?

Sim como comparação, mas não identifica sozinho a causa.

---

39. Logoff rápido e reboot lento indicam o quê?

Pode indicar componentes ligados ao primeiro logon após a inicialização.

---

40. Bloquear e desbloquear é igual a sair e entrar?

Não. Bloquear mantém a sessão existente.

---

41. Posso medir apenas até aparecer o papel de parede?

Não. O ideal é medir até a sessão ficar realmente utilizável.

---

42. O Visualizador de Eventos mostra a causa sempre?

Não. Alguns atrasos não geram erro explícito.

---

43. Event ID sozinho identifica o problema?

Não. Analise também Source, mensagem e horário.

---

44. gpresult ajuda em computador doméstico?

Pode ajudar a identificar políticas aplicadas, embora seja particularmente relevante em ambientes gerenciados.

---

45. DNS público sempre melhora?

Não. Em redes corporativas isso pode quebrar resolução interna.

---

46. Formatar é a solução mais rápida?

Nem sempre. Sem identificar a causa, o problema pode voltar.

---

47. Atualizar todos os drivers ajuda?

Atualizações aleatórias não constituem diagnóstico.

---

48. Como sei que encontrei o culpado?

Quando a evidência é repetível:

componente presente → lento
componente removido/desativado → rápido
componente reativado → lento novamente

---

49. Quanto tempo de logon é considerado normal?

Não existe um único valor universal. Compare principalmente com o histórico da própria máquina, hardware, perfil e ambiente.

---

50. Qual é a principal regra para diagnosticar logon lento?

Meça primeiro e altere uma variável por vez.

---

Conclusão

Quando o Windows 11 demora muito depois que você digita a senha ou PIN, o problema nem sempre está na inicialização do sistema.

O Windows pode chegar rapidamente à tela de logon e perder tempo apenas ao:

carregar perfil
executar tarefas
aplicar políticas
conectar recursos
iniciar programas
esperar rede
preparar o Explorer

Por isso, o melhor diagnóstico começa separando:

boot
logon
desktop
sessão utilizável

Depois, compare cenários:

outro usuário
com e sem rede
reboot e logoff
GOOD e BAD

Ferramentas como:

Event Viewer
gpresult
net use
Autoruns
Task Scheduler
Process Monitor
Process Explorer
Resource Monitor
WPR
WPA

permitem transformar a sensação de que “o Windows fica parado em Bem-vindo” em um diagnóstico técnico baseado em tempo, processos, eventos e dependências.

A regra mais importante continua simples:

não tente corrigir tudo ao mesmo tempo. Descubra primeiro onde o tempo desaparece.

Precisa de ajuda para descobrir por que o Windows 11 demora depois do logon?

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores Windows, problemas de desempenho, inicialização lenta, falhas de rede, impressoras, programas, drivers e configurações.

O atendimento pode ser feito por acesso remoto ou visita técnica agendada, conforme o tipo de problema.

VMIA – Manutenção e Configuração
Telefone e WhatsApp: (11) 99779-7772
Atendimento em São Paulo e suporte remoto.