Introdução: por que o Windows 11 fica lento mesmo quando o Gerenciador de Tarefas mostra tudo normal?

Você liga o computador, abre o navegador, inicia o Word ou tenta acessar uma pasta. De repente, o Windows 11 demora vários segundos para responder.

O cursor continua se movimentando. O computador não apresenta tela azul. Nenhum aviso aparece.

Ao abrir o Gerenciador de Tarefas, você encontra números aparentemente normais:

• Processador utilizando apenas 8%.
• Memória RAM com 42% de ocupação.
• SSD apresentando 2% de atividade.
• GPU praticamente ociosa.
• Nenhum aplicativo consumindo recursos excessivos.

Mesmo assim, o computador continua lento.

O Explorador de Arquivos demora para abrir. Aplicativos apresentam pequenas pausas. O Menu Iniciar responde com atraso. Às vezes, o sistema volta ao normal sozinho.

Esse comportamento costuma confundir usuários porque os indicadores tradicionais de desempenho não revelam necessariamente a origem da lentidão.

O problema pode estar relacionado à latência de operações, drivers, interrupções de hardware, armazenamento, gerenciamento de energia ou esperas internas do sistema operacional.

Neste guia técnico da VMIA, vamos investigar por que o Windows 11 pode apresentar lentidão mesmo quando CPU, RAM e SSD parecem funcionar normalmente.

O objetivo é ensinar um diagnóstico baseado em evidências, sem recorrer imediatamente à formatação do computador ou à instalação de programas de otimização.

1. O erro mais comum: acreditar que baixo consumo de recursos significa bom desempenho

O Gerenciador de Tarefas apresenta informações importantes sobre o funcionamento do Windows.

Entretanto, seus indicadores representam apenas parte do comportamento do sistema.

Um computador pode apresentar baixo consumo de CPU porque os processos estão aguardando operações de entrada e saída.

Da mesma forma, um SSD pode apresentar baixa taxa de transferência enquanto determinadas operações individuais demoram muito para terminar.

1.1. Utilização não é a mesma coisa que latência

Considere dois computadores.

No primeiro, um aplicativo executa uma operação de armazenamento em poucos milissegundos.

No segundo, a mesma operação demora centenas de milissegundos.

Ambos podem apresentar baixo consumo de CPU.

Entretanto, o segundo computador terá uma experiência de uso muito pior.

Isso acontece porque o tempo de resposta não depende apenas da quantidade de recursos utilizados.

Também depende de quanto tempo cada operação leva para terminar.

1.2. Exemplo prático

Imagine um usuário tentando abrir uma pasta com documentos.

O Explorador de Arquivos solicita informações ao sistema de arquivos.

Se uma operação necessária ficar aguardando o armazenamento, a rede ou outro componente, a interface pode parecer travada.

Durante essa espera, a CPU pode permanecer praticamente ociosa.

O Gerenciador de Tarefas não necessariamente mostrará um processo utilizando muitos recursos.

Baixo consumo de CPU não significa que o computador esteja respondendo rapidamente.

2. As principais causas ocultas de lentidão no Windows 11

A lentidão com indicadores aparentemente normais pode surgir por diferentes motivos.

Causa	Sintoma comum	Ferramenta de diagnóstico
Latência de armazenamento	Pastas e programas demoram para abrir	Monitor de Recursos
Interrupções e DPC	Pequenas pausas no sistema	WPR/WPA
Driver com comportamento inadequado	Travamentos intermitentes	Event Viewer e WPA
Hard faults de memória	Pausas ao alternar aplicativos	Monitor de Recursos
Processos aguardando I/O	CPU baixa, aplicativo sem resposta	Resource Monitor
Problemas de energia	Resposta lenta ou desempenho inconsistente	Powercfg e ferramentas de desempenho
Erros de hardware	Lentidão acompanhada de falhas ocasionais	WHEA e Event Viewer
Acesso à rede	Explorador demora ao abrir pastas	Monitor de Recursos e testes de rede
Filtros de sistema de arquivos	Operações de arquivos lentas	ProcMon e ferramentas de diagnóstico

Essas hipóteses não devem ser tratadas como causas confirmadas.

O diagnóstico precisa identificar qual componente está realmente atrasando a execução.

3. Latência de armazenamento: quando o SSD parece normal, mas responde lentamente

Uma das causas que merecem investigação é a latência de armazenamento.

Muitos usuários avaliam o SSD apenas pela velocidade anunciada pelo fabricante ou pela taxa de transferência exibida no Gerenciador de Tarefas.

Entretanto, um SSD pode apresentar boa velocidade em testes sequenciais e ainda sofrer atrasos em determinadas operações.

3.1. O que é latência de armazenamento?

Latência é o tempo necessário para uma operação ser atendida.

No contexto do armazenamento, ela pode envolver diferentes etapas, incluindo:

• Envio da solicitação.
• Processamento pelo sistema de armazenamento.
• Atendimento da operação.
• Conclusão e retorno ao aplicativo.

A latência percebida pelo usuário também pode incluir esperas fora do dispositivo físico.

Por isso, uma leitura lenta não significa automaticamente que o SSD esteja defeituoso.

3.2. Por que o Gerenciador de Tarefas pode não mostrar o problema?

Imagine que o sistema precise ler um arquivo pequeno.

Se essa leitura apresentar um atraso significativo, o aplicativo poderá ficar aguardando.

Entretanto, como o volume de dados é pequeno, a taxa de transferência pode continuar baixa.

O usuário observa um aplicativo lento, mas o Gerenciador de Tarefas não mostra muitos MB/s de atividade.

Além disso, picos curtos podem passar despercebidos entre as atualizações da interface.

3.3. Como verificar a latência pelo Monitor de Recursos

Pressione:

Win + R

Digite:

resmon

Abra a guia Disco.

Observe principalmente:

• Processos com atividade de disco.
• Arquivos acessados.
• Tempo de resposta.
• Taxas de leitura e gravação.
• Comprimento da fila de disco.

O Monitor de Recursos pode apresentar informações que não ficam tão evidentes na visualização resumida do Gerenciador de Tarefas.

3.4. Como interpretar o tempo de resposta?

Não existe um único valor universal que determine se um SSD está saudável ou defeituoso.

O tempo de resposta depende do tipo de operação, da carga, do dispositivo e do ambiente.

Uma operação isolada com latência elevada não comprova falha de hardware.

Entretanto, atrasos repetidos e correlacionados com os travamentos merecem investigação.

O mais importante é verificar se os aumentos de latência acontecem no mesmo momento em que o Windows fica lento.

4. Filas de I/O: quando processos aguardam operações

I/O significa Input/Output, ou entrada e saída.

No Windows, diferentes componentes utilizam operações de I/O para acessar arquivos, dispositivos, rede e outros recursos.

Um processo pode permanecer aguardando a conclusão de uma operação.

Durante essa espera, ele não precisa consumir CPU continuamente.

4.1. Exemplo de uma operação bloqueante

Considere um aplicativo que precisa ler informações de um banco de dados local.

Ele solicita os dados ao sistema.

Enquanto a operação não termina, determinada thread pode permanecer aguardando.

Se a interface depender dessa thread, o aplicativo poderá parecer congelado.

A CPU pode continuar com baixa utilização.

Esse comportamento não significa necessariamente que o processador esteja lento.

Significa que o aplicativo está aguardando uma condição necessária para continuar.

4.2. O que é comprimento da fila de disco?

O comprimento da fila representa a quantidade de solicitações de armazenamento em andamento ou aguardando atendimento, conforme o contador utilizado.

Filas maiores podem ser normais em determinadas cargas de trabalho.

Por isso, não existe uma regra simples como “fila acima de 1 significa problema”.

O técnico deve avaliar a fila junto com:

• Latência.
• Taxa de transferência.
• Tipo de dispositivo.
• Padrão de acesso.
• Quantidade de operações.
• Sintomas observados.

Uma fila elevada acompanhada de latência crescente pode indicar saturação ou outro gargalo de armazenamento.

5. DPC e ISR: problemas de drivers que não aparecem claramente no Gerenciador de Tarefas

Outra possibilidade envolve o processamento de interrupções de hardware.

O Windows utiliza mecanismos para atender eventos gerados por dispositivos.

Dois conceitos importantes são:

ISR — Interrupt Service Routine

Rotina associada ao tratamento de interrupções de hardware.

DPC — Deferred Procedure Call

Mecanismo utilizado para executar posteriormente determinadas tarefas relacionadas ao processamento de interrupções e outras atividades de kernel.

Esses mecanismos fazem parte do funcionamento normal do Windows.

O problema aparece quando determinadas rotinas apresentam duração excessiva ou frequência que prejudica a capacidade de resposta do sistema.

5.1. Como isso afeta o usuário?

Dependendo da causa, problemas relacionados a DPC e ISR podem contribuir para:

• Pequenas pausas na interface.
• Falhas momentâneas de áudio.
• Atrasos de resposta.
• Problemas de comunicação com dispositivos.
• Comportamento inconsistente de aplicativos sensíveis à latência.

Entretanto, nem todo travamento do Windows é causado por DPC ou ISR.

É necessário medir o comportamento antes de atribuir a culpa a um driver.

5.2. Por que a CPU pode parecer normal?

O Gerenciador de Tarefas apresenta médias de utilização.

Atividades curtas ou concentradas em determinados núcleos podem não ficar evidentes na porcentagem total.

Além disso, a experiência de resposta depende de fatores que não são representados apenas pela utilização média do processador.

Um sistema pode apresentar baixa utilização geral e ainda sofrer atrasos em operações sensíveis ao tempo.

5.3. Quais drivers merecem investigação?

Dependendo dos sintomas, diferentes componentes podem estar envolvidos:

• Controladores de armazenamento.
• Adaptadores de rede.
• Drivers gráficos.
• Controladores USB.
• Dispositivos de áudio.
• Drivers de chipset.
• Componentes de gerenciamento de energia.

Não é correto afirmar que um driver específico está causando o problema apenas porque ele aparece em uma ferramenta de monitoramento.

O diagnóstico exige correlação entre as medições, o comportamento do computador e os componentes envolvidos.

6. Hard faults de memória: quando existe RAM disponível, mas o sistema apresenta pausas

Outro indicador frequentemente mal interpretado é o número de hard faults.

No Windows, um hard fault ocorre quando uma página de memória necessária não está presente na RAM e precisa ser obtida de uma fonte de armazenamento apropriada.

Isso pode envolver o arquivo de paginação ou arquivos mapeados em memória.

Hard fault não significa defeito físico na memória RAM.

Também não significa necessariamente que o computador esteja sem memória.

6.1. Por que existem hard faults com RAM livre?

O Windows gerencia a memória utilizando diferentes mecanismos.

Páginas podem ser removidas do conjunto de trabalho de um processo e recuperadas posteriormente.

Além disso, aplicativos podem acessar dados de arquivos mapeados em memória que ainda não estão residentes na RAM.

Isso pode produzir hard faults mesmo quando existe memória disponível.

6.2. Quando hard faults podem afetar o desempenho?

O problema merece investigação quando a recuperação dessas páginas provoca atrasos perceptíveis.

Por exemplo, ao alternar entre aplicativos, o usuário pode observar pausas enquanto determinadas páginas são carregadas.

Entretanto, a quantidade de hard faults isoladamente não determina a gravidade do problema.

É necessário avaliar o tempo de resposta e o comportamento do armazenamento.

6.3. Como verificar hard faults

Abra:

Win + R → resmon

Selecione a guia Memória.

Observe a coluna Falhas Graves/s ou Hard Faults/sec, conforme o idioma do Windows.

Compare os valores com os momentos de lentidão.

Uma quantidade elevada durante a abertura inicial de um aplicativo pode ser normal.

Já pausas repetidas acompanhadas de latência elevada de armazenamento podem justificar uma investigação mais aprofundada.

7. Gerenciamento de energia: quando o processador não responde como esperado

O Windows 11 utiliza mecanismos de gerenciamento de energia para equilibrar consumo, temperatura e desempenho.

Esses mecanismos dependem do processador, firmware, drivers e configurações do sistema.

Entre os conceitos relevantes estão:

• Estados de desempenho do processador.
• Estados de economia de energia.
• Limites de potência.
• Gerenciamento térmico.
• Políticas de energia do Windows.
• Recursos específicos de plataformas Intel e AMD.

Um computador pode apresentar desempenho inconsistente quando existem limitações de potência ou problemas relacionados ao firmware.

Entretanto, baixa frequência do processador em repouso é normal e não indica defeito.

7.1. Verificando o modo de energia

Abra:

Configurações → Sistema → Energia e bateria

Quando disponível, verifique o modo de energia selecionado.

As opções variam conforme o dispositivo e a configuração.

Não é necessário utilizar permanentemente o modo de maior desempenho.

O objetivo é verificar se existe alguma configuração inadequada para o uso esperado.

7.2. Consultando os planos de energia

No Terminal ou PowerShell:

powercfg /list

Esse comando lista os planos de energia disponíveis.

Para identificar o plano ativo:

powercfg /getactivescheme

Essas consultas não alteram o sistema.

O técnico deve considerar que computadores modernos podem utilizar mecanismos de gerenciamento de energia que não ficam completamente representados pelos planos tradicionais.

8. WHEA: erros de hardware que podem acompanhar problemas de desempenho

O Windows Hardware Error Architecture, conhecido como WHEA, fornece mecanismos para registrar determinadas condições de erro de hardware.

Eventos WHEA podem envolver diferentes componentes, dependendo da plataforma.

Entre eles estão:

• Processador.
• Memória.
• Barramentos.
• Dispositivos PCI Express.
• Outros componentes monitorados pela arquitetura.

Alguns erros podem ser corrigidos pelo hardware ou pela plataforma sem provocar imediatamente uma tela azul.

Entretanto, a presença de um evento WHEA não significa automaticamente que ele esteja causando lentidão.

8.1. Como consultar eventos WHEA

Abra o PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-WHEA-Logger'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

O comando procura eventos WHEA registrados nos últimos sete dias.

Examine:

• Horário.
• Tipo de erro.
• Componente indicado.
• Frequência dos registros.
• Relação com os travamentos.

8.2. Eventos WHEA não são diagnósticos definitivos

Um evento pode indicar um erro corrigido ou outra condição registrada pela plataforma.

A interpretação exige analisar os detalhes disponíveis e considerar o hardware envolvido.

Não substitua componentes apenas porque existe um evento WHEA isolado.

9. Monitor de Confiabilidade: identificando quando a lentidão começou

O Monitor de Confiabilidade apresenta um histórico de determinados problemas de estabilidade do Windows.

Ele pode ajudar a identificar:

• Falhas de aplicativos.
• Falhas do Windows.
• Instalações de software.
• Atualizações.
• Outros eventos registrados no histórico.

Para abrir:

Win + R → perfmon /rel

Examine a linha do tempo.

9.1. Como utilizar o histórico

Imagine que o computador começou a apresentar lentidão na terça-feira.

O Monitor de Confiabilidade mostra que um driver foi atualizado no mesmo dia.

Essa coincidência não comprova que o driver causou o problema.

Entretanto, fornece uma hipótese que pode ser investigada.

Compare a data da alteração com:

• Início dos sintomas.
• Eventos do sistema.
• Versões dos drivers.
• Resultados das ferramentas de desempenho.

9.2. Quando o Monitor de Confiabilidade não mostra nada

Nem toda lentidão gera um evento de falha.

O Windows pode apresentar atrasos de resposta sem registrar um erro crítico.

Por isso, um histórico aparentemente normal não significa que o computador esteja livre de problemas.

Nesses casos, ferramentas de medição de desempenho podem ser mais úteis.

10. Primeiro roteiro de diagnóstico: descubra onde investigar

Antes de executar testes avançados, observe o comportamento do computador.

Qual comportamento descreve melhor a lentidão?

Pastas e programas demoram para abrirO sistema pausa ao alternar aplicativosPequenos travamentos em áudio, mouse ou interfaceLentidão ao acessar arquivos ou pastas de redeTudo responde lentamente, sem padrão claro

Investigue latência de armazenamento

Comece pelo Monitor de Recursos, guia Disco. Observe tempo de resposta, arquivos acessados e filas durante a lentidão. Correlacione com eventos de armazenamento.

Esse roteiro não substitui o diagnóstico técnico. Ele ajuda a selecionar a primeira ferramenta de investigação.

11. Por que formatar o Windows pode não resolver a lentidão?

A formatação pode corrigir determinados problemas de software, mas não elimina necessariamente causas relacionadas a hardware, firmware ou drivers.

Se a origem estiver em um SSD com falhas intermitentes, por exemplo, reinstalar o Windows não corrige o dispositivo.

O mesmo vale para problemas de firmware, limitações térmicas ou determinadas falhas de hardware.

Além disso, uma reinstalação pode apagar evidências importantes para a investigação.

Antes de formatar, procure identificar a origem do problema.

Um diagnóstico bem conduzido pode evitar perda de tempo, reinstalações desnecessárias e substituição incorreta de componentes.

12. Conclusão da Parte 1

O Windows 11 pode apresentar lentidão mesmo quando CPU, RAM e SSD mostram utilização aparentemente normal.

Isso acontece porque a experiência de desempenho depende de fatores que vão além das porcentagens exibidas no Gerenciador de Tarefas.

Latência de armazenamento, filas de I/O, hard faults, processamento de interrupções, drivers e gerenciamento de energia podem influenciar o tempo de resposta.

A investigação deve considerar os sintomas e relacioná-los às medições técnicas.

O primeiro passo não é instalar um otimizador ou formatar o computador.

É descobrir qual operação está demorando e por quê.

Diagnóstico profissional de desempenho | Novembro de 2026

Na primeira parte deste guia, explicamos por que o Windows 11 pode apresentar lentidão mesmo quando o Gerenciador de Tarefas mostra CPU, memória RAM e SSD com utilização aparentemente normal.

Agora vamos aprofundar a investigação com ferramentas capazes de revelar problemas que os indicadores tradicionais não mostram claramente.

Entre elas estão o Monitor de Recursos, Performance Monitor, PowerShell, Windows Performance Recorder (WPR) e Windows Performance Analyzer (WPA).

Essas ferramentas permitem investigar atrasos de armazenamento, filas de entrada e saída, hard faults, interrupções de hardware, execução de drivers e esperas de threads.

O objetivo desta segunda parte é descobrir onde o Windows está perdendo tempo, em vez de simplesmente procurar processos que consomem muitos recursos.

13. Monitor de Recursos: identificando operações lentas que não aparecem no Gerenciador de Tarefas

O Monitor de Recursos, conhecido como Resource Monitor, apresenta informações detalhadas sobre CPU, memória, disco e rede.

Ele é especialmente útil quando um aplicativo fica sem responder, mas o Gerenciador de Tarefas não mostra utilização elevada.

Para abrir:

Win + R → resmon

Selecione a guia correspondente ao recurso que deseja investigar.

13.1. Analisando a guia Disco

A guia Disco apresenta informações sobre processos e atividades de armazenamento.

Entre os indicadores disponíveis estão:

• Processos com atividade de disco.
• Arquivos acessados.
• Taxas de leitura e gravação.
• Tempo de resposta.
• Atividade por unidade.
• Comprimento da fila de disco.

O técnico deve observar esses indicadores enquanto reproduz o problema.

Por exemplo, se o Explorador de Arquivos demora cinco segundos para abrir uma pasta, examine o comportamento do armazenamento durante esse intervalo.

13.2. Tempo de resposta elevado com poucos MB/s

Imagine o seguinte cenário hipotético:

Indicador	Valor observado
CPU	9%
RAM utilizada	43%
Atividade de disco	4%
Leitura	0,8 MB/s
Tempo de resposta	850 ms

O SSD apresenta baixa taxa de transferência, mas uma operação demora 850 milissegundos.

Esse resultado merece investigação.

Entretanto, não significa automaticamente que o SSD esteja defeituoso.

O atraso pode envolver o dispositivo, o controlador, drivers, filtros de sistema de arquivos ou outras condições.

O mais importante é verificar se a latência elevada coincide com a lentidão percebida.

13.3. Quando a fila de disco merece atenção?

O comprimento da fila representa solicitações de I/O em andamento ou aguardando atendimento, conforme o contador utilizado.

Uma fila maior não significa necessariamente defeito.

SSDs NVMe modernos podem processar várias operações simultaneamente.

Por isso, o técnico deve avaliar:

• Quantidade de solicitações.
• Latência média.
• Tipo de operação.
• Taxa de transferência.
• Características do dispositivo.
• Duração do problema.

Uma fila crescente acompanhada de atrasos persistentes pode indicar um gargalo.

14. Performance Monitor: medindo o desempenho ao longo do tempo

O Performance Monitor, também chamado de Monitor de Desempenho, permite acompanhar contadores do Windows.

Ele oferece uma vantagem importante: registrar indicadores durante um período prolongado.

Isso ajuda a investigar problemas que aparecem apenas ocasionalmente.

14.1. Como abrir o Performance Monitor

Pressione:

Win + R

Digite:

perfmon

No painel lateral, selecione Monitor de Desempenho.

É possível adicionar contadores relacionados a processador, memória, armazenamento e outros componentes.

14.2. Contadores importantes para investigar lentidão

Contador	O que representa
Processor Information\% Processor Time	Utilização do processador
Processor Information\% DPC Time	Tempo associado ao processamento de DPC
Processor Information\% Interrupt Time	Tempo associado ao processamento de interrupções
Memory\Available MBytes	Memória disponível
Memory\Page Reads/sec	Leituras de páginas relacionadas a hard faults
Memory\Pages/sec	Taxa de páginas transferidas para atender determinadas operações de memória
PhysicalDisk\Avg. Disk sec/Read	Tempo médio de leitura
PhysicalDisk\Avg. Disk sec/Write	Tempo médio de gravação
PhysicalDisk\Current Disk Queue Length	Solicitações pendentes ou em atendimento
PhysicalDisk\Disk Transfers/sec	Operações de transferência por segundo

Os nomes podem aparecer traduzidos conforme o idioma do Windows.

A disponibilidade dos contadores também depende da versão e da configuração do sistema.

14.3. Interpretando a latência em segundos

Os contadores:

Avg. Disk sec/Read

Avg. Disk sec/Write

apresentam valores em segundos.

Para converter em milissegundos:

\[ \text{Latência (ms)} = \text{Tempo (s)} \times 1000 \]

Exemplo:

\[ 0{,}025 \times 1000 = 25\text{ ms} \]

Isso significa que o contador apresentou um tempo médio de 25 milissegundos no intervalo analisado.

Esse valor precisa ser interpretado considerando o tipo de armazenamento e a carga.

Não existe um limite universal que determine a saúde de todos os SSDs.

15. PowerShell: coletando indicadores de desempenho

O PowerShell permite consultar contadores sem depender exclusivamente da interface gráfica.

O cmdlet Get-Counter pode coletar amostras de desempenho.

15.1. Verificando a latência do armazenamento

Em sistemas com os contadores em inglês:

Get-Counter `
    -Counter "\PhysicalDisk(_Total)\Avg. Disk sec/Read" `
    -SampleInterval 1 `
    -MaxSamples 10

O comando coleta dez amostras, com intervalo de um segundo.

Em instalações com contadores localizados, o caminho poderá precisar ser adaptado.

Para descobrir os nomes disponíveis:

Get-Counter -ListSet * |
Where-Object {
    $_.CounterSetName -match "Disk|Disco"
} |
Select-Object CounterSetName

15.2. Coletando vários indicadores

$contadores = @(
    "\PhysicalDisk(_Total)\Avg. Disk sec/Read",
    "\PhysicalDisk(_Total)\Avg. Disk sec/Write",
    "\PhysicalDisk(_Total)\Current Disk Queue Length",
    "\Memory\Available MBytes"
)

Get-Counter `
    -Counter $contadores `
    -SampleInterval 2 `
    -MaxSamples 15

Esse exemplo coleta amostras durante aproximadamente 30 segundos.

Os contadores devem existir com os nomes utilizados no sistema.

15.3. Por que não utilizar somente o contador _Total?

A instância _Total apresenta uma visão agregada.

Em computadores com várias unidades, ela pode ocultar diferenças entre dispositivos.

Para identificar qual SSD apresenta latência elevada, consulte também as instâncias individuais.

Isso é especialmente importante quando o Windows está instalado em uma unidade e os aplicativos ou dados estão em outra.

16. PowerShell para investigar hard faults e paginação

Hard faults ocorrem quando determinadas páginas de memória precisam ser recuperadas de uma fonte de armazenamento.

Eles podem envolver o arquivo de paginação ou arquivos mapeados.

A presença de hard faults não significa automaticamente falta de memória RAM.

16.1. Consultando leituras de páginas

Get-Counter `
    -Counter "\Memory\Page Reads/sec" `
    -SampleInterval 1 `
    -MaxSamples 10

O contador apresenta uma taxa relacionada a operações de leitura de páginas.

Ele não corresponde diretamente ao número de hard faults individuais.

Uma única operação de leitura pode atender mais de uma página.

16.2. Consultando memória disponível

Get-Counter `
    -Counter "\Memory\Available MBytes" `
    -SampleInterval 1 `
    -MaxSamples 10

A quantidade de memória disponível deve ser interpretada junto com outros indicadores.

Um computador pode possuir memória disponível e ainda apresentar hard faults relacionados a arquivos mapeados.

16.3. Quando a paginação realmente afeta o desempenho?

Considere um aplicativo que apresenta pausas ao alternar entre janelas.

Durante essas pausas, o Monitor de Recursos mostra aumento de hard faults e o armazenamento apresenta latência elevada.

Essa correlação sugere que operações de recuperação de páginas podem estar contribuindo para o atraso.

Entretanto, o diagnóstico ainda deve considerar outras atividades de disco.

17. DPC e ISR: investigando atrasos provocados por drivers

O Windows utiliza interrupções para responder a eventos de hardware.

As rotinas ISR tratam aspectos imediatos dessas interrupções.

Os DPCs permitem adiar determinadas atividades para execução posterior.

Esses mecanismos são normais.

O problema aparece quando determinadas rotinas consomem tempo excessivo ou interferem em atividades sensíveis à latência.

17.1. Sintomas possíveis

Problemas relacionados a DPC e ISR podem contribuir para:

• Áudio interrompido.
• Pequenas pausas na interface.
• Atrasos na resposta de dispositivos.
• Falhas momentâneas em atividades de tempo real.
• Comportamento inconsistente de determinados aplicativos.

Entretanto, esses sintomas também podem ter outras causas.

17.2. Monitorando DPC e interrupções

No Performance Monitor, procure contadores relacionados a:

% DPC Time

% Interrupt Time

Esses indicadores ajudam a observar o tempo de CPU associado a essas atividades.

Entretanto, médias de utilização não identificam necessariamente qual driver provocou um atraso específico.

Para isso, podem ser necessários rastreamentos ETW analisados com o Windows Performance Analyzer.

18. Windows Performance Recorder: coletando rastreamentos ETW

O Windows Performance Recorder, conhecido como WPR, é uma ferramenta da Microsoft utilizada para coletar rastreamentos de desempenho.

Ele utiliza Event Tracing for Windows (ETW).

Esses rastreamentos podem registrar informações sobre:

• Atividade de CPU.
• Agendamento de threads.
• Operações de armazenamento.
• Carregamento de imagens.
• DPC e ISR.
• Outros eventos, conforme o perfil selecionado.

O WPR faz parte das ferramentas de desempenho disponibilizadas pela Microsoft, incluindo componentes do Windows Assessment and Deployment Kit (ADK).

18.1. Por que utilizar WPR?

O Gerenciador de Tarefas mostra principalmente o estado atual dos recursos.

O WPR permite registrar uma sequência de eventos.

Isso ajuda a investigar o que aconteceu durante um travamento.

Por exemplo, uma interface pode ficar sem responder durante três segundos.

Um rastreamento apropriado pode ajudar a identificar se a thread estava executando, aguardando I/O ou bloqueada por outra condição.

18.2. Verificando a disponibilidade do WPR

Abra o Terminal:

Get-Command wpr.exe -ErrorAction SilentlyContinue

Se estiver disponível, consulte a ajuda:

wpr -help

Os perfis disponíveis dependem da versão instalada.

18.3. Listando perfis de gravação

wpr -profiles

A listagem ajuda a identificar os perfis disponíveis.

Para investigar lentidão geral, um perfil de desempenho geral pode ser apropriado.

A escolha deve considerar o problema investigado e o volume de dados que será coletado.

18.4. Exemplo de coleta básica

Em versões compatíveis com o perfil GeneralProfile:

wpr -start GeneralProfile

Depois:

1. Reproduza a lentidão.
2. Aguarde a ocorrência do problema.
3. Registre o horário aproximado.
4. Encerre a gravação.

wpr -stop "C:\Diagnostico\lentidao.etl"

Crie previamente a pasta de destino e confirme as permissões necessárias.

O arquivo ETL poderá ser analisado com o WPA.

Atenção: rastreamentos ETW podem conter caminhos, nomes de processos e outras informações sobre a atividade do computador. Armazene-os de maneira apropriada.

19. Windows Performance Analyzer: encontrando a origem dos atrasos

O Windows Performance Analyzer, conhecido como WPA, permite examinar rastreamentos ETW.

Ele apresenta gráficos e tabelas que ajudam a analisar o comportamento do sistema durante o período registrado.

Entre as áreas de investigação estão:

• CPU Usage.
• CPU Usage (Precise).
• DPC/ISR.
• Disk Usage.
• File I/O.
• Memory.
• Thread scheduling.

A disponibilidade dessas visualizações depende dos eventos capturados pelo perfil do WPR.

19.1. CPU Usage: utilização não é a mesma coisa que espera

A análise de CPU pode mostrar quais processos e threads consumiram tempo de processamento.

Entretanto, um aplicativo lento pode não consumir CPU porque está aguardando uma operação.

Nesse cenário, a investigação precisa considerar o agendamento de threads e as condições de espera.

19.2. CPU Usage (Precise)

Quando os eventos necessários estão disponíveis, a visualização de uso preciso da CPU pode ajudar a examinar transições de threads e informações de agendamento.

Ela é útil para investigar:

• Threads prontas para executar.
• Threads aguardando.
• Intervalos de execução.
• Atrasos de agendamento.
• Relações entre processos e threads.

O objetivo é identificar se o aplicativo estava efetivamente executando ou aguardando outra atividade.

19.3. Exemplo prático

Imagine que o Explorador de Arquivos apresente uma pausa de quatro segundos.

Durante esse intervalo, a CPU permanece com baixa utilização.

No WPA, a análise mostra que uma thread relevante passou parte do período aguardando uma operação.

Essa observação ajuda a direcionar a investigação.

Entretanto, o estado de espera isoladamente não identifica a causa.

É necessário relacionar a thread aos eventos de I/O, sincronização ou outras atividades disponíveis.

20. WPA e análise de DPC/ISR

O WPA pode apresentar informações sobre atividades de DPC e ISR quando o rastreamento contém os eventos necessários.

Entre os dados úteis estão:

• Duração das rotinas.
• Quantidade de ocorrências.
• Distribuição temporal.
• Módulos associados.
• Processadores envolvidos.

20.1. Como interpretar uma rotina longa?

Uma rotina com duração elevada pode merecer investigação, especialmente quando coincide com um problema de resposta.

Entretanto, não existe um limite único que determine a causa de todos os travamentos.

O técnico deve considerar:

• Frequência das ocorrências.
• Duração.
• Tipo de atividade.
• Hardware envolvido.
• Sintomas.
• Correlação temporal.

20.2. O módulo associado nem sempre é o responsável final

Um rastreamento pode identificar um módulo do Windows relacionado à atividade observada.

Isso não significa necessariamente que o próprio componente do Windows esteja defeituoso.

A origem pode envolver drivers de terceiros, firmware ou comportamento do dispositivo.

Por isso, evite concluir que arquivos como ntoskrnl.exe são a causa do problema apenas porque aparecem em uma ferramenta.

21. NVMe: por que um SSD rápido pode apresentar atrasos?

SSDs NVMe utilizam uma interface projetada para operações de armazenamento de alto desempenho.

Entretanto, o desempenho real depende de diferentes componentes.

Entre eles estão:

• Controlador NVMe.
• Firmware do SSD.
• Interface PCI Express.
• Drivers.
• Gerenciamento de energia.
• Temperatura.
• Carga de trabalho.
• Estado do dispositivo.

Um SSD pode apresentar excelente desempenho sequencial e ainda sofrer atrasos em determinadas operações.

21.1. Latência e throughput

Throughput representa a quantidade de dados transferidos por unidade de tempo.

Latência representa o tempo necessário para atender uma operação.

Essas métricas não são equivalentes.

Um SSD pode transferir grandes arquivos rapidamente e apresentar atrasos em pequenas operações aleatórias.

21.2. Eventos de armazenamento

No Visualizador de Eventos, consulte:

Logs do Windows → Sistema

Procure eventos relacionados aos provedores de armazenamento, como Storport, Disk e drivers específicos.

Eventos frequentemente investigados incluem:

Evento	Possível interpretação
129	Solicitação de redefinição relacionada ao caminho de armazenamento
153	Operação de I/O que precisou ser repetida
7	Erro relacionado a bloco defeituoso, conforme o provedor
51	Erro durante operação de paginação, conforme o contexto

Os IDs devem ser interpretados junto com o provedor, a mensagem e o dispositivo.

Não conclua que um SSD está defeituoso apenas pelo número do evento.

21.3. Consultando eventos com PowerShell

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 7,51,129,153
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

O comando coleta eventos que podem ser relevantes para a investigação.

Como os IDs não são exclusivos de um único provedor, examine cuidadosamente os resultados.

22. PowerShell para identificar unidades físicas

O Windows disponibiliza cmdlets de armazenamento.

Para listar os discos físicos reconhecidos:

Get-PhysicalDisk |
Select-Object FriendlyName, MediaType, BusType, HealthStatus, OperationalStatus, Size

O resultado pode apresentar informações como:

• Nome do dispositivo.
• Tipo de mídia.
• Barramento.
• Estado operacional.
• Estado de saúde informado.
• Capacidade.

Essas informações dependem do suporte oferecido pelo dispositivo e pela pilha de armazenamento.

Um estado Healthy não garante que o SSD esteja livre de falhas intermitentes.

22.1. Consultando informações de confiabilidade

Quando o dispositivo e o provedor oferecem suporte:

Get-PhysicalDisk |
Get-StorageReliabilityCounter |
Format-List *

O comando pode apresentar dados relacionados à confiabilidade e ao funcionamento do armazenamento.

Nem todos os SSDs expõem as mesmas informações.

Campos ausentes ou não preenchidos não devem ser interpretados automaticamente como defeitos.

23. Como correlacionar diferentes indicadores

Uma das etapas mais importantes do diagnóstico é relacionar os dados coletados.

Considere os seguintes cenários hipotéticos.

Cenário A — Lentidão associada ao armazenamento

O Explorador demora para abrir arquivos. O Monitor de Recursos mostra latência elevada e o sistema registra eventos de armazenamento no mesmo período.

Próximo passo: investigar dispositivo, controlador, firmware, drivers e integridade dos dados.

Cenário B — Pequenas pausas relacionadas a drivers

O usuário percebe interrupções momentâneas. O rastreamento ETW apresenta atividades DPC/ISR relevantes nos mesmos intervalos.

Próximo passo: identificar os módulos associados e correlacionar com os dispositivos e drivers.

Cenário C — Hard faults acompanhados de latência

O computador apresenta pausas ao alternar aplicativos. Há aumento de hard faults e atrasos de armazenamento.

Próximo passo: investigar conjuntos de trabalho, paginação e comportamento dos aplicativos.

Cenário D — Aplicativo aguardando sem consumir CPU

A interface fica sem responder, mas a utilização de CPU permanece baixa. O WPA indica períodos de espera em threads relevantes.

Próximo passo: investigar as operações e dependências responsáveis pelas esperas.

24. Tabela de diagnóstico profissional VMIA

Sintoma	Indicador	Ferramenta	Hipótese
Pastas abrem lentamente	Latência elevada	Resource Monitor	Armazenamento ou I/O
Pausas curtas	DPC/ISR	WPR/WPA	Driver ou dispositivo
Lentidão ao alternar apps	Hard faults e latência	Resource Monitor	Recuperação de páginas
CPU baixa e app congelado	Thread aguardando	WPA	Espera por recurso
SSD apresenta erros	Eventos 129/153	Event Viewer	Caminho de armazenamento
Desempenho inconsistente	Frequência e energia	Powercfg/WPA	Gerenciamento de energia
Travamentos sem erro visível	Ausência de eventos conclusivos	ETW	Necessidade de rastreamento detalhado

25. Cuidados durante a coleta de desempenho

Ferramentas avançadas podem gerar arquivos grandes e consumir recursos.

Para obter resultados úteis:

1. Registre o horário do problema.
2. Escolha o perfil de captura adequado.
3. Evite coletar dados desnecessários.
4. Reproduza a falha durante a gravação.
5. Encerre a captura depois do evento.
6. Preserve os arquivos originais para análise.
7. Evite compartilhar dados sensíveis presentes nos rastreamentos.

Não execute testes intensivos de armazenamento em um dispositivo com suspeita de falha física sem avaliar previamente a necessidade de backup.

Também não altere firmware, drivers ou configurações de energia antes de identificar uma hipótese consistente.

26. Conclusão da Parte 2

O Windows 11 pode apresentar lentidão mesmo quando os indicadores tradicionais de utilização parecem normais.

Isso acontece porque a experiência do usuário depende de latência, agendamento, operações de I/O, memória e comportamento dos dispositivos.

O Monitor de Recursos permite identificar atividades e tempos de resposta.

O Performance Monitor registra contadores ao longo do tempo.

O PowerShell facilita a coleta de indicadores.

O WPR e o WPA permitem investigar eventos detalhados de execução, esperas, interrupções e armazenamento.

O diagnóstico profissional consiste em relacionar os sintomas aos dados coletados, evitando conclusões baseadas em uma única métrica.

Investigação profissional de latência e travamentos | Novembro de 2026

Nas duas primeiras partes deste guia, explicamos por que o Windows 11 pode apresentar lentidão mesmo quando o Gerenciador de Tarefas mostra baixo consumo de processador, memória RAM disponível e pouca atividade de SSD.

Também exploramos o Monitor de Recursos, Performance Monitor, PowerShell, Windows Performance Recorder (WPR) e Windows Performance Analyzer (WPA).

Agora vamos investigar uma camada mais profunda do funcionamento do sistema operacional: o tempo que processos e threads passam aguardando recursos, as rotinas de drivers, os filtros de arquivos e as operações internas de armazenamento.

Esses mecanismos podem explicar situações em que o computador parece congelado durante alguns segundos, mas não apresenta utilização elevada de CPU, RAM ou disco.

O objetivo desta terceira parte é ensinar a identificar a origem desses atrasos por meio de evidências técnicas, sem recorrer a alterações arriscadas no Registro, desativação indiscriminada de serviços ou reinstalação desnecessária do Windows.

27. WPA Wait Analysis: descobrindo por que uma thread está aguardando

O Windows executa aplicativos utilizando processos e threads.

Um processo representa uma instância de execução de um programa. Uma thread representa uma sequência de instruções que pode ser agendada pelo sistema operacional.

Um aplicativo pode possuir dezenas ou centenas de threads.

Enquanto algumas executam instruções, outras aguardam eventos, operações de entrada e saída ou recursos compartilhados.

Esse comportamento é normal.

O problema aparece quando uma thread importante para a interface permanece aguardando uma operação que demora excessivamente.

27.1. Por que o aplicativo congela sem consumir CPU?

Imagine que o Explorador de Arquivos precise consultar informações de uma pasta.

A thread responsável pela operação solicita os dados.

Se essa solicitação não terminar rapidamente, a thread pode entrar em estado de espera.

Enquanto aguarda, ela não precisa executar instruções continuamente.

Consequentemente, o Gerenciador de Tarefas pode mostrar utilização baixa.

O usuário percebe o Explorador congelado, mas não identifica nenhum processo consumindo muitos recursos.

Uma thread aguardando não significa necessariamente que o processador esteja sobrecarregado.

27.2. Estados importantes de threads

Estado ou condição	Significado
Running	Thread executando em um processador lógico
Ready	Thread pronta para executar, aguardando agendamento
Waiting	Thread aguardando uma condição ou recurso
Standby	Thread selecionada para execução em um processador
Transition	Estado de transição associado ao gerenciamento da thread
Terminated	Thread encerrada

A nomenclatura e a disponibilidade das informações variam conforme a ferramenta e o tipo de rastreamento.

No WPA, as visualizações de agendamento ajudam a identificar intervalos de execução e espera.

27.3. Como investigar esperas no WPA

Abra um rastreamento ETL coletado com os eventos necessários.

No WPA, procure visualizações relacionadas a:

Computation → CPU Usage (Precise)

Dependendo da versão e do perfil capturado, também podem existir visualizações específicas de análise de esperas.

Selecione o intervalo em que o usuário percebeu a lentidão.

Depois:

1. Identifique o processo afetado.
2. Examine as threads relevantes.
3. Compare os intervalos de execução e espera.
4. Observe as informações de agendamento disponíveis.
5. Investigue as operações associadas ao período.

A disponibilidade de pilhas de chamadas e detalhes de espera depende das opções utilizadas na coleta.

27.4. Nem toda espera representa um problema

Threads frequentemente aguardam eventos de maneira intencional.

Por exemplo, uma thread pode aguardar uma interação do usuário.

Isso não representa lentidão.

O diagnóstico deve identificar uma espera que impeça o progresso de uma operação importante.

O tempo de espera precisa ser relacionado ao comportamento observado.

28. Wait Analysis: diferenciando espera normal de gargalo real

A análise de esperas busca identificar o motivo pelo qual determinada atividade não consegue avançar.

Uma espera pode envolver:

• Operação de armazenamento.
• Comunicação entre processos.
• Sincronização entre threads.
• Acesso a recursos compartilhados.
• Resposta de um serviço.
• Comunicação de rede.
• Temporizadores.

Essas condições podem produzir sintomas semelhantes.

28.1. Exemplo: aplicativo aguardando armazenamento

Considere um aplicativo que precisa carregar um arquivo.

A thread solicita uma leitura.

Se a operação demorar, a interface poderá ficar sem responder.

Nesse cenário, a análise de threads pode mostrar um período de espera.

Os eventos de armazenamento ajudam a verificar se existiu uma operação lenta no mesmo intervalo.

28.2. Exemplo: aplicativo aguardando outro processo

Imagine um programa que depende de um serviço local.

O aplicativo envia uma solicitação e aguarda a resposta.

Se o serviço apresentar atraso, a interface poderá congelar.

A CPU do aplicativo pode continuar baixa.

Nesse caso, investigar apenas o executável principal pode não revelar a causa.

O técnico precisa examinar o processo ou serviço responsável pela resposta.

28.3. Exemplo: contenção de recursos

Duas ou mais threads podem precisar acessar um recurso protegido por mecanismos de sincronização.

Se uma thread mantiver o recurso por tempo excessivo, outras poderão aguardar.

Dependendo dos dados capturados, o WPA pode ajudar a identificar relações entre threads e intervalos de espera.

Entretanto, nem toda relação de bloqueio pode ser reconstruída automaticamente.

A investigação pode exigir símbolos, pilhas de chamadas ou ferramentas adicionais.

29. ETW: correlacionando eventos de diferentes componentes

O Event Tracing for Windows é uma infraestrutura de rastreamento do sistema operacional.

Ela permite registrar eventos produzidos por componentes do Windows e por softwares que oferecem provedores ETW.

O WPR utiliza essa infraestrutura para coletar dados de desempenho.

O WPA permite analisar os registros.

29.1. Por que a correlação temporal é importante?

Imagine que o Windows apresente uma pausa às 14h32.

Durante esse período, diferentes eventos podem ocorrer:

• Uma thread entra em espera.
• Uma operação de armazenamento demora.
• Um driver executa uma rotina DPC.
• Um processo consulta um arquivo.
• Um serviço responde com atraso.

Analisar esses eventos separadamente pode produzir interpretações incorretas.

A correlação temporal ajuda a identificar quais atividades coincidem com a falha.

Entretanto, coincidência temporal não comprova causalidade.

29.2. Linha do tempo de um travamento hipotético

Exemplo ilustrativo: pausa de aproximadamente 4 segundosOs tempos são fictícios. A figura mostra como uma espera de I/O pode coincidir com uma interface sem resposta, mesmo com baixa atividade de CPU.

29.3. Cuidados ao analisar ETW

Rastreamentos podem apresentar milhares ou milhões de eventos.

Por isso, o técnico deve:

• Identificar o intervalo exato do problema.
• Filtrar os processos relevantes.
• Selecionar os gráficos adequados.
• Comparar eventos relacionados.
• Evitar conclusões baseadas em um evento isolado.

Também é importante preservar os arquivos ETL originais.

30. DPC e ISR: como identificar drivers que prejudicam a capacidade de resposta

As rotinas DPC e ISR participam do processamento de eventos de hardware.

Um driver pode executar essas rotinas para atender atividades de um dispositivo.

Quando determinadas rotinas apresentam duração elevada ou frequência excessiva, podem interferir na execução de outras atividades.

30.1. DPC e ISR não são erros

É importante destacar que a presença de DPCs e ISRs é normal.

Todos os computadores utilizam mecanismos de interrupção.

O problema não é a existência dessas rotinas.

O problema potencial está em seu comportamento durante os sintomas.

30.2. Como analisar DPC/ISR no WPA

Abra um rastreamento que contenha eventos de DPC e ISR.

Procure visualizações relacionadas a:

Computation → DPC/ISR

Dependendo da versão do WPA, os nomes e a organização podem variar.

Examine:

• Duração das rotinas.
• Quantidade de ocorrências.
• Distribuição temporal.
• Módulos associados.
• Processadores envolvidos.

Selecione o período correspondente ao travamento.

30.3. Como interpretar a duração?

Uma rotina com duração elevada pode merecer investigação.

Entretanto, não existe um valor universal que determine se um driver está defeituoso.

O impacto depende da frequência, da carga, do hardware e da atividade afetada.

Por exemplo, uma rotina relativamente longa durante uma operação excepcional pode não provocar problemas perceptíveis.

Já ocorrências repetidas durante atividades sensíveis à latência podem ser relevantes.

30.4. Drivers frequentemente investigados

Dependendo do sintoma, os seguintes componentes podem entrar na investigação:

Componente	Possível relação
Driver de rede	Processamento de pacotes e interrupções
Driver gráfico	Atividades de GPU e exibição
Driver de áudio	Processamento sensível à latência
Controlador USB	Comunicação com periféricos
Controlador de armazenamento	Operações de I/O
Driver de chipset	Comunicação e gerenciamento de plataforma

Essas são categorias de investigação, não uma lista de culpados.

30.5. Por que ntoskrnl.exe aparece em algumas análises?

O arquivo ntoskrnl.exe faz parte do núcleo do Windows.

Ele participa de diversas operações fundamentais.

Sua presença em uma pilha de chamadas ou relatório não significa automaticamente que o kernel esteja causando o problema.

O técnico deve investigar a sequência de execução e os componentes associados.

31. Storport: investigando atrasos na pilha de armazenamento

O Storport é um componente importante da infraestrutura de armazenamento do Windows.

Ele participa da comunicação com determinados controladores e drivers de armazenamento.

Dependendo do dispositivo e da configuração, a pilha pode envolver componentes como:

• Aplicativo.
• Sistema de arquivos.
• Gerenciadores de I/O.
• Drivers de filtro.
• Drivers de volume e classe.
• Infraestrutura de porta de armazenamento.
• Driver de controlador.
• Hardware.

Uma operação lenta pode envolver diferentes etapas dessa cadeia.

31.1. Por que um SSD NVMe pode apresentar latência elevada?

Mesmo um SSD rápido pode sofrer atrasos por diferentes razões:

• Firmware.
• Gerenciamento de energia.
• Controlador.
• Drivers.
• Temperatura.
• Carga de trabalho.
• Problemas de comunicação.
• Erros e novas tentativas de operações.

A investigação deve considerar as evidências disponíveis.

31.2. Eventos 129 e 153

Dois eventos frequentemente utilizados em diagnósticos de armazenamento são 129 e 153.

O evento 129 pode estar relacionado a solicitações de redefinição do caminho de armazenamento após condições de timeout.

O evento 153 pode indicar operações de I/O que precisaram ser repetidas.

Entretanto, o significado exato depende do provedor e da mensagem registrada.

31.3. Consultando os eventos

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 129,153
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

Examine o provedor e o dispositivo indicado.

Não interprete todos os eventos com esses IDs como problemas de SSD.

31.4. Correlação com o WPA

Se o sistema registra atrasos de armazenamento no mesmo momento em que o usuário percebe lentidão, o WPA pode ajudar a examinar a atividade de disco.

Dependendo do rastreamento, procure:

• Disk Usage.
• Disk I/O.
• File I/O.
• Informações de duração.
• Processos relacionados.

A análise pode ajudar a diferenciar operações lentas de períodos em que o aplicativo simplesmente não solicita dados.

32. Minifilters: filtros de sistema de arquivos que podem introduzir latência

O Windows utiliza drivers de filtro para permitir que determinados softwares participem das operações de sistema de arquivos.

Esses filtros podem ser utilizados por:

• Antivírus.
• Soluções de backup.
• Ferramentas de criptografia.
• Sistemas de sincronização.
• Softwares corporativos de segurança.
• Outros componentes especializados.

Os minifilters são gerenciados pelo Filter Manager.

Eles podem inspecionar ou modificar determinadas operações de I/O.

32.1. Como um minifilter pode afetar o desempenho?

Imagine que um aplicativo tente abrir um documento.

A operação pode passar por filtros instalados no sistema.

Se algum componente introduzir um atraso significativo, o aplicativo poderá demorar para receber a resposta.

Entretanto, a presença de um minifilter não significa que ele esteja causando lentidão.

Muitos filtros são componentes legítimos e necessários.

32.2. Listando minifilters com FLTMC

Abra o Terminal com privilégios administrativos quando necessário.

Execute:

fltmc filters

O comando lista filtros registrados no Filter Manager.

A saída pode apresentar:

• Nome do filtro.
• Número de instâncias.
• Altitude.
• Frame.

32.3. O que significa altitude?

A altitude ajuda a determinar a ordem relativa de posicionamento dos minifilters na pilha.

Ela não representa prioridade de CPU.

Também não indica diretamente o desempenho do filtro.

Uma altitude maior não significa que o driver seja mais lento ou mais importante.

32.4. Consultando instâncias

fltmc instances

O comando apresenta informações sobre instâncias de filtros associadas a volumes.

Isso ajuda a compreender quais filtros estão presentes no caminho de determinadas operações.

32.5. O que não fazer com minifilters

Não descarregue filtros indiscriminadamente.

Não remova drivers de antivírus, criptografia ou backup apenas porque aparecem na listagem.

Essas alterações podem comprometer a segurança, a integridade dos dados ou a estabilidade do sistema.

Se houver evidências consistentes de problema em um produto específico, utilize os procedimentos oficiais do fornecedor.

33. Process Monitor: identificando operações lentas e acessos repetitivos

O Process Monitor, ou ProcMon, é uma ferramenta da Microsoft Sysinternals utilizada para observar atividades de processos.

Ele pode registrar operações relacionadas a:

• Sistema de arquivos.
• Registro.
• Processos.
• Threads.
• Carregamento de imagens.

A ferramenta é especialmente útil quando um aplicativo demora para abrir ou fica sem responder durante determinadas operações.

33.1. Como utilizar o Process Monitor

Obtenha a ferramenta pela página oficial:Microsoft Sysinternals — Process Monitor

Execute o ProcMon com as permissões apropriadas.

Antes de iniciar a investigação, configure filtros para reduzir o volume de eventos.

Por exemplo, filtre pelo processo afetado.

33.2. Investigando o Explorador de Arquivos

Se o problema ocorre no Explorador:

Process Name → is → explorer.exe → Include

Depois:

1. Inicie a captura.
2. Reproduza a lentidão.
3. Interrompa a captura.
4. Localize o intervalo do problema.
5. Examine as operações relevantes.

33.3. Coluna Duration

O ProcMon pode apresentar a duração de determinadas operações.

Essa informação ajuda a identificar atividades que demoraram mais do que o esperado.

Entretanto, uma operação longa não significa necessariamente que o arquivo acessado esteja defeituoso.

É necessário considerar o tipo de operação e o contexto.

33.4. Resultados que merecem interpretação cuidadosa

Resultado	Interpretação possível
SUCCESS	Operação concluída
NAME NOT FOUND	Objeto procurado não encontrado
PATH NOT FOUND	Caminho não encontrado
ACCESS DENIED	Acesso negado
SHARING VIOLATION	Conflito de compartilhamento
BUFFER OVERFLOW	Pode representar comportamento normal de consulta

Nem todo resultado diferente de SUCCESS representa erro.

Aplicativos frequentemente procuram arquivos ou chaves de Registro que não existem.

Isso pode fazer parte de seu funcionamento normal.

33.5. Identificando operações repetitivas

Um aplicativo pode consultar repetidamente o mesmo recurso.

Se essas consultas forem lentas, a experiência de uso poderá ser prejudicada.

O ProcMon ajuda a identificar padrões como:

• Acesso repetido a arquivos.
• Consultas recorrentes ao Registro.
• Tentativas de abrir caminhos indisponíveis.
• Operações demoradas.
• Carregamento de componentes.

O técnico deve investigar por que o aplicativo executa essas operações antes de modificar o sistema.

34. PowerShell avançado: correlacionando eventos e processos

O PowerShell permite reunir informações de diferentes fontes.

Uma abordagem útil consiste em coletar eventos próximos ao horário da lentidão.

34.1. Consultando eventos recentes do sistema

$inicio = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    StartTime = $inicio
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Level -le 3
} |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

O comando consulta eventos críticos, erros e avisos das últimas duas horas.

Nem todo aviso representa um problema.

34.2. Consultando falhas de aplicativos

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    StartTime = (Get-Date).AddHours(-2)
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Level -le 3
} |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

Essa consulta ajuda a identificar falhas registradas no período.

Entretanto, uma interface lenta pode não gerar nenhum evento de erro.

34.3. Identificando processos com maior tempo acumulado de CPU

Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 15 Name, Id, CPU, WorkingSet64

A propriedade CPU representa tempo acumulado de processamento, não a porcentagem instantânea de utilização.

Por isso, ela não deve ser interpretada como consumo atual.

Para medir utilização ao longo do tempo, utilize contadores apropriados.

34.4. Verificando serviços relacionados a um processo

Quando um serviço está envolvido:

Get-CimInstance Win32_Service |
Where-Object {
    $_.State -eq "Running"
} |
Select-Object Name, DisplayName, ProcessId, StartMode

O comando ajuda a relacionar serviços aos processos correspondentes.

Essa informação pode ser útil quando o aplicativo depende de um serviço local.

35. Exemplos práticos de diagnóstico profissional

Os cenários a seguir são ilustrativos e demonstram como correlacionar evidências.

Caso 1 — Explorador demora para abrir pastas

Sintoma: o usuário abre uma pasta e o Explorador fica sem responder durante alguns segundos.

Observações:

• CPU baixa.
• Memória disponível.
• Atividade de disco aparentemente pequena.
• ProcMon mostra operações demoradas.
• WPA indica períodos de espera em threads relevantes.

Investigação: verificar se as operações envolvem armazenamento local, rede, extensões do Explorer ou filtros de sistema de arquivos.

Conclusão: o diagnóstico deve identificar qual recurso está atrasando a resposta antes de aplicar correções.

Caso 2 — SSD NVMe apresenta pausas intermitentes

Sintoma: aplicativos demoram para carregar, mas testes rápidos de velocidade parecem normais.

Observações:

• Latência de armazenamento elevada durante as pausas.
• Eventos de armazenamento próximos ao horário.
• Operações de I/O com duração elevada.

Investigação: examinar firmware, controlador, drivers, gerenciamento de energia e saúde do dispositivo.

Conclusão: testes sequenciais de velocidade não substituem a análise de latência e confiabilidade.

Caso 3 — Sistema apresenta microtravamentos

Sintoma: pequenas pausas na interface, sem utilização elevada de CPU.

Observações:

• Eventos DPC/ISR relevantes durante os sintomas.
• Módulos associados a determinados dispositivos.
• Ausência de falhas críticas.

Investigação: comparar drivers, versões de firmware e comportamento dos dispositivos.

Conclusão: a presença de um módulo em uma rotina DPC não comprova, isoladamente, que ele seja a causa.

Caso 4 — Aplicativo lento por dependência de serviço

Sintoma: um programa demora para abrir, mas outros funcionam normalmente.

Observações:

• Processo principal com baixo consumo de CPU.
• Thread aguardando resposta.
• Serviço local envolvido.
• Operação demorada identificada no rastreamento.

Investigação: verificar o serviço, suas dependências e as operações executadas.

Conclusão: a origem pode estar fora do processo que apresenta o sintoma.

36. Tabela de diagnóstico avançado VMIA

Sintoma	Evidência	Ferramenta	Próxima investigação
Aplicativo congela	Thread aguardando	WPA	Dependência ou operação pendente
Interface apresenta pausas	DPC/ISR relevante	WPA	Driver e dispositivo
SSD responde lentamente	Latência elevada	PerfMon/WPA	Controlador e armazenamento
Eventos 129/153	Operações de armazenamento	Event Viewer	Caminho de I/O
Acesso a arquivos demora	Operações lentas	ProcMon	Arquivos, rede e filtros
Muitos minifilters	Filtros registrados	FLTMC	Correlação com operações
CPU baixa e programa lento	Esperas prolongadas	WPA	Agendamento e sincronização
Aplicativo depende de serviço	Resposta atrasada	PowerShell/ETW	Serviço e dependências

37. Boas práticas para um diagnóstico seguro

O diagnóstico avançado deve preservar a integridade do sistema.

Antes de modificar configurações:

1. Registre os sintomas.
2. Identifique o horário das falhas.
3. Colete evidências.
4. Verifique a existência de backup.
5. Confirme a hipótese técnica.
6. Escolha a correção menos invasiva.
7. Teste o resultado.
8. Documente as alterações.

Evite utilizar programas de otimização que prometem corrigir automaticamente todos os problemas de desempenho.

Também não desative serviços essenciais, filtros de segurança ou mecanismos de proteção sem compreender suas funções.

A investigação deve ser orientada por evidências, não por tentativas aleatórias de alteração do Windows.

38. Conclusão da Parte 3

O Windows 11 pode apresentar lentidão mesmo quando os indicadores de CPU, RAM e SSD parecem normais porque muitos problemas envolvem esperas, latência e operações internas.

O WPA permite investigar agendamento de threads, DPC/ISR e atividades de armazenamento.

O ETW ajuda a correlacionar eventos de diferentes componentes.

O Storport e os registros de armazenamento fornecem informações sobre operações de I/O.

O FLTMC permite identificar filtros de sistema de arquivos.

O Process Monitor ajuda a localizar operações demoradas e padrões de acesso.

O PowerShell complementa a investigação com consultas a eventos, processos e serviços.

A combinação dessas ferramentas permite formular hipóteses mais precisas e reduzir o risco de correções desnecessárias.

Soluções avançadas e otimização segura | Novembro de 2026

Nas três primeiras partes deste guia, investigamos por que o Windows 11 pode apresentar lentidão mesmo quando o Gerenciador de Tarefas mostra baixo consumo de processador, memória RAM disponível e pouca atividade do SSD.

Aprendemos a utilizar o Monitor de Recursos, Performance Monitor, PowerShell, Windows Performance Recorder (WPR), Windows Performance Analyzer (WPA), Process Monitor e ferramentas de diagnóstico de armazenamento.

Também analisamos threads em espera, latência de I/O, interrupções DPC/ISR, hard faults, controladores NVMe, Storport e minifilters.

Agora chegamos à etapa mais importante: transformar as evidências coletadas em correções específicas, seguras e verificáveis.

Nesta quarta e última parte, vamos organizar as soluções por causa, apresentar um roteiro de diagnóstico profissional, explicar como prevenir novos problemas e responder às dúvidas mais frequentes.

39. Como corrigir a lentidão do Windows 11 quando CPU, RAM e SSD parecem normais

O primeiro erro a evitar é aplicar várias alterações simultaneamente.

Se o técnico atualizar drivers, modificar o plano de energia, desativar serviços e alterar configurações de armazenamento ao mesmo tempo, ficará difícil identificar qual mudança realmente resolveu o problema.

O procedimento recomendado é:

1. Identificar o sintoma predominante.
2. Reproduzir a lentidão.
3. Coletar indicadores durante a ocorrência.
4. Formular uma hipótese técnica.
5. Aplicar uma correção específica.
6. Repetir o teste nas mesmas condições.
7. Comparar os resultados anteriores e posteriores.

Esse método reduz intervenções desnecessárias e facilita a identificação de problemas recorrentes.

39.1. Diferencie três tipos de lentidão

Tipo	Comportamento	Primeira investigação
Lentidão contínua	O sistema responde lentamente o tempo todo	Energia, CPU, armazenamento e processos
Lentidão intermitente	O computador congela por alguns segundos	Latência, eventos e ETW
Lentidão localizada	Apenas um programa ou operação apresenta atraso	Dependências, ProcMon e serviços

Essa classificação ajuda a escolher as ferramentas adequadas.

40. Solução 1 — Corrigir latência elevada do SSD NVMe

Um SSD NVMe pode apresentar excelente desempenho em testes sequenciais e ainda sofrer atrasos em operações específicas.

Isso acontece porque a velocidade máxima de transferência não representa necessariamente o tempo de resposta de cada solicitação.

40.1. Confirme a latência antes de alterar configurações

Abra o Monitor de Recursos:

Win + R → resmon

Na guia Disco, observe o tempo de resposta enquanto reproduz o problema.

Também é possível utilizar o PowerShell:

Get-Counter `
  -Counter "\PhysicalDisk(*)\Avg. Disk sec/Read" `
  -SampleInterval 1 `
  -MaxSamples 10

Em sistemas com contadores localizados, adapte o nome do contador.

Lembre-se de que os resultados são apresentados em segundos.

Para converter em milissegundos, multiplique por 1.000.

Uma latência elevada isolada não comprova defeito. Procure padrões persistentes associados ao sintoma.

40.2. Verifique os eventos de armazenamento

Consulte os eventos 129 e 153:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 129,153
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-List

O evento 129 pode estar associado a uma solicitação de redefinição no caminho de armazenamento.

O evento 153 pode indicar operações de I/O repetidas.

A interpretação depende do provedor e da mensagem.

40.3. Verifique a saúde do dispositivo

Get-PhysicalDisk |
Select-Object FriendlyName, MediaType, BusType,
              HealthStatus, OperationalStatus, Size

Quando disponível:

Get-PhysicalDisk |
Get-StorageReliabilityCounter |
Format-List *

Essas consultas podem apresentar informações sobre a confiabilidade do dispositivo.

Entretanto, um estado Healthy não garante ausência de falhas intermitentes.

40.4. Correções recomendadas

Quando a investigação indicar problemas no caminho de armazenamento:

• Verifique se existe firmware oficial atualizado para o SSD.
• Consulte atualizações de BIOS/UEFI recomendadas pelo fabricante.
• Confirme a compatibilidade dos drivers de armazenamento.
• Verifique temperatura e condições de refrigeração.
• Examine eventos de erros e redefinições.
• Avalie problemas de comunicação PCIe quando houver evidências.
• Preserve os dados antes de executar procedimentos potencialmente invasivos.

Atualizações de firmware devem seguir as instruções oficiais do fabricante e exigir backup prévio.

Não execute testes intensivos de gravação em um SSD com suspeita de falha sem antes proteger os dados importantes.

41. Solução 2 — Corrigir problemas relacionados a Storport e controladores

O Storport participa da infraestrutura de armazenamento utilizada por determinados controladores do Windows.

Atrasos podem envolver drivers, firmware, controladores e dispositivos.

41.1. Identifique o controlador utilizado

Abra:

Gerenciador de Dispositivos → Controladores de armazenamento

Examine os dispositivos apresentados.

Dependendo da configuração, o computador pode utilizar controladores e drivers diferentes.

Em alguns equipamentos, o SSD NVMe utiliza o driver padrão da Microsoft.

Em outros, existem componentes específicos do fabricante ou da plataforma.

41.2. Quando atualizar drivers?

Considere a atualização quando:

• O fabricante documentar uma correção relevante.
• Existirem problemas de compatibilidade conhecidos.
• Os eventos indicarem falhas relacionadas ao controlador.
• O diagnóstico apontar comportamento inadequado do driver.

Prefira os pacotes disponibilizados pelo fabricante do equipamento ou do componente.

Não instale drivers de armazenamento aleatórios.

41.3. Evite alterações indiscriminadas de energia PCIe

Algumas configurações de economia de energia influenciam o comportamento dos dispositivos PCI Express.

Entretanto, desativar recursos como ASPM não é uma solução universal.

Essas alterações podem aumentar o consumo de energia e afetar a autonomia de notebooks.

A investigação deve considerar o hardware, o firmware e as recomendações do fabricante.

42. Solução 3 — Corrigir atrasos relacionados a DPC e ISR

DPCs e ISRs fazem parte do processamento normal de interrupções no Windows.

O problema pode surgir quando determinadas rotinas apresentam duração ou frequência que prejudica atividades sensíveis à latência.

42.1. Confirme a correlação com o problema

Utilize um rastreamento WPR apropriado e examine as informações no WPA.

Procure visualizações relacionadas a:

Computation → DPC/ISR

Observe o intervalo correspondente à lentidão.

Analise:

• Duração das rotinas.
• Frequência.
• Módulos associados.
• Processadores envolvidos.
• Relação temporal com o sintoma.

42.2. Identifique o dispositivo relacionado

Um módulo associado a determinada atividade pode indicar qual componente merece investigação.

Por exemplo, um driver de rede pode aparecer durante processamento de pacotes.

Entretanto, isso não comprova que ele esteja defeituoso.

É necessário avaliar o contexto.

42.3. Correções seguras

Quando houver evidências consistentes:

1. Identifique o dispositivo e o driver.
2. Registre a versão instalada.
3. Consulte atualizações oficiais.
4. Verifique problemas conhecidos.
5. Instale uma atualização compatível, quando indicada.
6. Repita a medição.
7. Compare o comportamento.

Se o problema começou após uma atualização, uma reversão suportada pelo fabricante pode ser considerada, desde que exista uma versão anterior confiável e compatível.

Não desative dispositivos essenciais apenas para reduzir indicadores de DPC.

43. Solução 4 — Corrigir hard faults e problemas de paginação

Hard faults não representam necessariamente falta de RAM.

Eles ocorrem quando páginas necessárias precisam ser recuperadas de uma fonte de armazenamento.

Isso pode envolver arquivos mapeados ou o arquivo de paginação.

43.1. Quando investigar?

A investigação é recomendada quando:

• O sistema apresenta pausas ao alternar aplicativos.
• O Monitor de Recursos mostra hard faults frequentes durante as pausas.
• Existe latência elevada de armazenamento no mesmo período.
• O problema se repete em condições semelhantes.

43.2. Verifique a memória disponível

Abra:

Win + R → resmon

Selecione Memória.

Observe:

• Memória disponível.
• Memória em uso.
• Hard faults por processo.
• Comportamento durante a lentidão.

43.3. Verifique o arquivo de paginação

O Windows utiliza mecanismos de gerenciamento de memória que podem envolver o arquivo de paginação.

Em muitos computadores, manter o gerenciamento automático é a opção mais adequada.

Não desative o arquivo de paginação apenas porque existe memória RAM disponível.

Isso pode provocar problemas de alocação de memória, compatibilidade e geração de determinados arquivos de diagnóstico.

43.4. Correções recomendadas

Se a análise confirmar pressão de memória:

• Identifique os aplicativos responsáveis.
• Verifique consumo anormal ou vazamentos de memória.
• Atualize aplicativos com problemas conhecidos.
• Avalie a quantidade de RAM em relação à carga de trabalho.
• Preserve o gerenciamento adequado da memória virtual.

Se houver memória disponível, investigue também arquivos mapeados e latência de armazenamento antes de recomendar um upgrade.

44. Solução 5 — Corrigir lentidão relacionada a minifilters

Drivers minifilter podem participar das operações de sistema de arquivos.

Eles são utilizados por antivírus, backup, criptografia e outros softwares.

A presença de filtros não significa necessariamente problema.

44.1. Liste os filtros instalados

<CodeBlock language=”powershell” editable>
fltmc filters
</CodeBlock>

Para consultar instâncias:

<CodeBlock language=”powershell” editable>
fltmc instances
</CodeBlock>

Registre os filtros encontrados.

44.2. Correlacione com operações lentas

Utilize o Process Monitor para identificar operações demoradas.

Depois, examine quais componentes participam do caminho de I/O.

Quando possível, utilize rastreamentos adicionais para aprofundar a análise.

O simples fato de um filtro estar instalado não comprova que ele introduz latência.

44.3. Correção segura

Se a investigação apontar um produto específico:

• Verifique atualizações oficiais.
• Consulte problemas conhecidos.
• Confirme compatibilidade com a versão do Windows.
• Utilize os procedimentos de reparo do fornecedor.
• Em ambientes corporativos, envolva o administrador responsável.

Não descarregue minifilters indiscriminadamente.

Filtros de segurança e criptografia podem ser essenciais para a proteção e o acesso aos dados.

45. Solução 6 — Corrigir problemas de gerenciamento de energia

O Windows 11 utiliza diferentes mecanismos para equilibrar desempenho, consumo e temperatura.

Esses mecanismos dependem do processador, firmware, drivers e configuração do equipamento.

45.1. Verifique o modo de energia

Abra:

Configurações → Sistema → Energia e bateria

Quando disponível, examine o modo selecionado.

Um modo de economia de energia pode limitar determinadas características de desempenho.

Entretanto, isso não significa que todos os computadores devam utilizar permanentemente o modo de maior desempenho.

45.2. Consulte os planos disponíveis

<CodeBlock language=”powershell” editable>
powercfg /list
</CodeBlock>

Para identificar o plano ativo:

<CodeBlock language=”powershell” editable>
powercfg /getactivescheme
</CodeBlock>

Esses comandos não modificam o sistema.

45.3. Verifique temperatura e limitações de potência

O desempenho pode ser afetado por limitações térmicas ou elétricas.

Em notebooks, também considere:

• Estado do carregador.
• Potência disponível.
• Condições da bateria.
• Configurações do fabricante.
• Temperatura.
• Limites de potência da plataforma.

Uma frequência baixa durante o repouso é normal.

O diagnóstico deve verificar o comportamento sob uma carga de trabalho apropriada.

45.4. Evite ajustes agressivos

Não desative mecanismos de proteção térmica.

Não altere limites de potência ou parâmetros de firmware sem compreender as consequências.

Esses mecanismos ajudam a proteger o hardware.

46. Solução 7 — Aplicativos lentos por serviços e dependências

Um aplicativo pode apresentar lentidão porque depende de outro processo ou serviço.

Nesse cenário, o executável principal pode consumir pouca CPU enquanto aguarda uma resposta.

46.1. Identifique o processo afetado

Abra o Gerenciador de Tarefas e identifique o aplicativo.

Depois, consulte os serviços relacionados quando necessário.

<CodeBlock language=”powershell” editable>
Get-CimInstance Win32_Service |
Where-Object {
$_.State -eq “Running”
} |
Select-Object Name, DisplayName, ProcessId
</CodeBlock>

O comando ajuda a relacionar serviços em execução aos respectivos processos.

46.2. Investigue com WPA

Se o rastreamento possuir os eventos necessários, examine as threads e seus intervalos de espera.

O objetivo é descobrir se o aplicativo aguarda:

• Operação de I/O.
• Serviço local.
• Sincronização.
• Comunicação entre processos.
• Recurso de rede.

46.3. Corrija a dependência

A correção depende do componente identificado.

Pode envolver reparo do aplicativo, atualização de um serviço ou correção de problemas de conectividade.

Não desative serviços aleatoriamente.

47. Como utilizar WPR e WPA para confirmar que a correção funcionou

O diagnóstico não termina quando o computador parece mais rápido.

É importante verificar se os indicadores melhoraram.

47.1. Registre uma medição inicial

Antes da correção, registre:

• Tempo de resposta da operação afetada.
• Latência de armazenamento.
• Eventos relevantes.
• Comportamento de threads.
• Atividades DPC/ISR, quando pertinentes.

47.2. Aplique uma alteração por vez

Modifique somente o componente associado à hipótese.

Isso facilita identificar o efeito da correção.

47.3. Repita o teste

Reproduza a mesma operação em condições semelhantes.

Por exemplo, se o Explorador demorava vários segundos para abrir determinada pasta, repita o teste com a mesma pasta.

47.4. Compare os resultados

Indicador	Antes (exemplo)	Depois (exemplo)
Tempo para abrir pasta	4,2 s	0,7 s
Latência observada de I/O	620 ms	12 ms
Pausas percebidas	Frequentes	Não observadas no teste
Eventos de armazenamento	Presentes	Nenhum novo no período

<caption>Valores hipotéticos, apenas para demonstrar a comparação. Não representam resultados reais de um equipamento.</caption>

A ausência de novos eventos durante um teste curto não garante que uma falha intermitente tenha sido eliminada definitivamente.

Para problemas ocasionais, pode ser necessário acompanhar o sistema por mais tempo.

48. Tabela definitiva de diagnóstico e correções

Sintoma	Possível causa	Evidência	Correção recomendada
Pastas demoram para abrir	Latência de armazenamento	Resource Monitor/WPA	Investigar SSD, driver e controlador
SSD apresenta pausas	Problemas no caminho de I/O	Eventos 129/153	Verificar firmware e drivers oficiais
Microtravamentos	DPC/ISR	WPA	Investigar driver e dispositivo
Lentidão ao alternar apps	Recuperação de páginas	Hard faults e I/O	Investigar memória e armazenamento
Aplicativo congela com CPU baixa	Thread aguardando	WPA	Identificar dependência
Arquivos demoram para abrir	Filtro de sistema de arquivos	ProcMon e análise de filtros	Investigar software responsável
Desempenho inconsistente	Energia ou temperatura	Ferramentas de monitoramento	Verificar configuração e refrigeração
Lentidão em aplicativo específico	Serviço ou componente	ETW/ProcMon	Reparar dependência
Lentidão após atualização	Incompatibilidade	Histórico e eventos	Avaliar atualização ou reversão suportada
Erros de hardware	Falha de componente	WHEA e diagnósticos	Investigar hardware antes de substituir

49. Checklist de diagnóstico profissional VMIA

{@body const tasks = [“Identificar o sintoma predominante”,”Registrar horário e frequência das pausas”,”Verificar Monitor de Recursos e latência de disco”,”Consultar eventos de armazenamento e WHEA”,”Examinar memória e hard faults”,”Investigar DPC/ISR quando houver indícios”,”Verificar minifilters e dependências relevantes”,”Coletar WPR e analisar WPA se necessário”,”Confirmar backup antes de intervenções”,”Aplicar uma correção por vez”,”Repetir o teste e comparar os resultados”,”Documentar a solução e acompanhar recorrência”]}
{@body const [completed,setCompleted] = DIL.useState([])}
<box border radius=”xl” padding={3} gap={3}>
<row align=”center” justify=”between”>
Checklist interativo
<text color=”secondary” weight=”medium” tabularNums>{completed.length}/{tasks.length}</text>
</row>
<box background=”surface-tertiary” height=”7px” radius=”full” clip>
<box background=”rgba(22,163,74,0.85)” height=”100%” width={$DIL0%} radius=”full”/>
</box>
{#each tasks as task,i}
<checkbox key={i} checked={completed.includes(i)} onChange={v=>setCompleted(old=>v?[…old,i]:old.filter(x=>x!==i))}>{task}</checkbox>
{/each}
<row justify=”end”>
<button size=”sm” variant=”outline” color=”secondary” onClick={()=>setCompleted([])}>Reiniciar checklist</button>
</row>
</box>

50. Como prevenir lentidão invisível no Windows 11

A manutenção preventiva ajuda a reduzir problemas de desempenho e facilita a identificação de alterações.

50.1. Mantenha drivers e firmware compatíveis

Utilize atualizações oficiais do fabricante.

Priorize atualizações relacionadas a problemas documentados.

Evite instalar drivers apenas porque possuem números de versão mais recentes.

50.2. Monitore a saúde do armazenamento

Verifique periodicamente:

• Estado de saúde informado.
• Temperatura.
• Eventos de armazenamento.
• Espaço disponível.
• Comportamento de latência.

Esses indicadores ajudam a identificar alterações relevantes.

50.3. Preserve backups

Mantenha cópias atualizadas dos arquivos importantes.

Uma estratégia conhecida é a regra 3-2-1:

• Três cópias dos dados.
• Duas formas ou mídias de armazenamento.
• Uma cópia externa ou isolada.

O backup é especialmente importante quando existem sinais de falha de armazenamento.

50.4. Evite programas de otimização desconhecidos

Ferramentas que prometem acelerar o Windows com um único clique podem modificar configurações sem identificar a causa da lentidão.

Prefira diagnósticos específicos e ferramentas confiáveis.

50.5. Acompanhe o histórico de alterações

Registre instalações de programas, atualizações de drivers e modificações importantes.

Quando a lentidão começa após uma alteração, esse histórico ajuda a formular hipóteses.

50.6. Preserve espaço livre no SSD

A falta de espaço pode afetar atualizações, arquivos temporários e determinadas operações.

Entretanto, não existe uma porcentagem universal de espaço livre que garanta desempenho ideal para todos os SSDs.

Considere as recomendações do fabricante e as necessidades da carga de trabalho.

51. FAQ — Perguntas frequentes sobre Windows 11 lento com CPU, RAM e SSD normais

1. Por que o Windows 11 fica lento se o processador está usando apenas 10%?

A utilização de CPU não representa diretamente o tempo de resposta do sistema.

Um aplicativo pode estar aguardando armazenamento, rede, serviços ou outros recursos.

Durante essa espera, o processador pode permanecer com baixa utilização.

Ferramentas como Monitor de Recursos e WPA ajudam a investigar essas condições.

2. O SSD pode causar lentidão mesmo mostrando 0% ou 1% de atividade?

Sim.

A porcentagem apresentada pelo Gerenciador de Tarefas não revela necessariamente todos os atrasos individuais.

Uma operação pequena pode demorar muito sem gerar grande taxa de transferência.

Por isso, a latência deve ser analisada separadamente.

3. Um SSD NVMe rápido pode apresentar travamentos?

Sim.

A velocidade máxima anunciada pelo fabricante não garante ausência de atrasos.

Firmware, drivers, temperatura, controladores e condições de operação podem influenciar o comportamento.

O diagnóstico deve considerar latência e eventos, não apenas testes sequenciais.

4. O que significa o evento 129 do Windows?

Em contextos de armazenamento, o evento 129 pode indicar uma solicitação de redefinição relacionada ao caminho de I/O.

A interpretação depende do provedor e da mensagem registrada.

Ele merece investigação quando aparece repetidamente ou coincide com problemas de desempenho.

5. O evento 153 significa que meu SSD está estragado?

Não necessariamente.

O evento 153 pode indicar uma operação de armazenamento repetida.

Isso pode envolver diferentes componentes do caminho de I/O.

O diagnóstico deve considerar drivers, controladores, dispositivo e outras evidências.

6. O que são DPC e ISR?

DPC e ISR são mecanismos utilizados pelo Windows para processar atividades relacionadas a interrupções de hardware.

Eles fazem parte do funcionamento normal do sistema.

Determinadas rotinas com duração ou frequência excessiva podem contribuir para problemas de latência.

7. Como descobrir qual driver está causando microtravamentos?

Rastreamentos WPR analisados no WPA podem apresentar informações sobre DPC, ISR e módulos associados.

Entretanto, a presença de um driver no relatório não comprova automaticamente sua responsabilidade.

É necessário correlacionar os dados com o sintoma.

8. Hard faults significam que a memória RAM está com defeito?

Não.

Hard faults representam situações em que páginas de memória precisam ser recuperadas de uma fonte de armazenamento.

Eles podem ocorrer durante o funcionamento normal do Windows.

Não devem ser confundidos com falhas físicas de RAM.

9. Aumentar a memória RAM resolve a lentidão?

Depende.

Se existir pressão real de memória, um upgrade pode melhorar o desempenho.

Entretanto, se a causa estiver em drivers, armazenamento ou serviços, adicionar RAM pode não resolver.

O diagnóstico deve identificar o gargalo.

10. O que são minifilters do Windows?

Minifilters são drivers que participam de determinadas operações de sistema de arquivos.

Eles podem ser utilizados por antivírus, backup, criptografia e outros softwares.

Sua presença é normal.

A investigação deve procurar evidências de atrasos antes de atribuir o problema a um filtro.

11. Posso desativar serviços do Windows para melhorar o desempenho?

Não é recomendável desativar serviços indiscriminadamente.

Muitos serviços possuem dependências e funções importantes.

Uma alteração inadequada pode provocar instabilidade ou comprometer recursos de segurança.

O procedimento correto é identificar um serviço específico que esteja causando problemas.

12. O Windows Performance Analyzer é gratuito?

O WPA é disponibilizado pela Microsoft como parte das ferramentas de desempenho do Windows.

Ele pode ser utilizado para analisar rastreamentos ETW.

A ferramenta é voltada principalmente a diagnóstico técnico e análise de desempenho.

13. O Process Monitor mostra exatamente por que o computador está lento?

Não necessariamente.

Ele permite observar operações de arquivos, Registro, processos e outros eventos.

Essas informações ajudam a identificar padrões e operações demoradas.

Entretanto, determinados problemas exigem análise complementar com WPA, eventos ou outras ferramentas.

14. Formatar o Windows 11 resolve a lentidão?

A reinstalação pode corrigir determinados problemas de software.

Entretanto, não resolve necessariamente falhas de hardware, firmware ou problemas de compatibilidade.

Antes de formatar, é recomendável investigar a causa.

15. Quando devo procurar assistência técnica?

Procure suporte quando a lentidão for recorrente, afetar atividades importantes ou estiver acompanhada de erros de armazenamento, travamentos ou comportamento inconsistente.

Um diagnóstico técnico pode evitar substituições desnecessárias e identificar problemas que não aparecem claramente no Gerenciador de Tarefas.

52. Conclusão geral: desempenho não depende apenas de CPU, RAM e SSD

O Windows 11 pode apresentar lentidão mesmo quando os indicadores tradicionais parecem normais.

Isso acontece porque a experiência de uso depende de fatores como latência, agendamento de threads, operações de armazenamento, drivers, interrupções e gerenciamento de memória.

O Gerenciador de Tarefas é uma ferramenta importante, mas não revela sozinho todos os problemas.

O Monitor de Recursos permite examinar atividades de disco e memória.

O Performance Monitor registra indicadores ao longo do tempo.

O WPR e o WPA ajudam a investigar esperas, DPC/ISR e operações internas.

O Process Monitor permite analisar acessos a arquivos e outros recursos.

Já os eventos do Windows ajudam a identificar falhas e condições que podem acompanhar a lentidão.

O caminho mais confiável para resolver um Windows 11 lento é identificar a operação que está demorando, compreender sua causa e aplicar uma correção específica.

Isso evita alterações desnecessárias e aumenta a chance de uma solução duradoura.

53. Seu Windows 11 está lento e ninguém encontra o problema? Conte com a VMIA

Seu computador demora para abrir programas, apresenta pequenas pausas ou fica lento mesmo com CPU, memória e SSD aparentemente normais?

A VMIA — Manutenção e Configuração de Computadores oferece diagnóstico técnico de computadores e notebooks Windows.

O atendimento pode envolver análise de desempenho, drivers, armazenamento, erros do sistema, aplicativos e configurações.

<box border radius=”xl” padding={3} gap={3}>
<row align=”center” gap={3}>
<box background=”surface-secondary” radius=”lg” padding={3}>
<icon name=”monitor-cog” size=”2xl” color=”secondary”/>
</box>
<box flex=”1″ gap={1}>
<title size=”lg”>VMIA — Manutenção e Configuração</title>
<text color=”secondary” size=”sm”>São Paulo — SP | Atendimento remoto e presencial com agendamento</text>
</box>
</row>
**Serviços disponíveis:** diagnóstico de lentidão, Windows 10/11, SSD, drivers, software, redes e suporte técnico para usuários domésticos e profissionais.

<row align=”center” gap={2}>
<icon name=”clock” color=”secondary”/>
Atendimento mediante agendamento, com disponibilidade 24 horas
</row>
<row align=”center” gap={2}>
<icon name=”phone” color=”secondary”/>
**(11) 99779-7772**
</row>
<row align=”center” gap={2}>
<icon name=”mail” color=”secondary”/>
**suporte@vmia.com.br**
</row>
<button block onClick={()=>GenUI.openUrl(“https://whats.vmia.com.br”)}>
<icon name=”message-circle” inline/> Solicitar atendimento pelo WhatsApp
</button>
<row justify=”between” wrap=”wrap”>
<Link url=”https://vmia.site” title=”Site VMIA”/>
<Link url=”https://vmia.com.br” title=”Blog técnico”/>
<Link url=”https://avaliacao.vmia.com.br” title=”Avaliações”/>
</row>
</box>