O Windows 11 mostra 80%, 90% ou até mais da memória RAM em uso, mas quando você abre o Gerenciador de Tarefas e soma os programas aparentemente mais pesados, os números simplesmente não fecham.
Chrome está usando 1,5 GB.
Outlook, 500 MB.
Alguns programas menores consomem mais algumas centenas de megabytes.
Mesmo assim, um computador com 16 GB de RAM pode mostrar 14 GB ocupados.
Onde foi parar o restante da memória?
Existem várias explicações possíveis para essa diferença, porque a memória utilizada pelo Windows não pertence apenas aos aplicativos exibidos na guia Processos. O próprio sistema operacional, cache, kernel, drivers e outras estruturas também precisam de RAM.
Uma das informações que merece atenção durante esse diagnóstico aparece em:
Gerenciador de Tarefas → Desempenho → Memória
Na parte inferior da tela podemos encontrar valores como:
Pool paginado
Pool não paginado
Em inglês:
Paged pool
Non-paged pool
Esses números passam despercebidos para a maioria dos usuários.
Porém, quando o Pool não paginado cresce de maneira anormal e continua aumentando durante horas ou dias, ele pode revelar um problema completamente diferente de simplesmente “um programa está usando muita RAM”.
Em determinados casos, um driver pode estar alocando memória e não devolvendo corretamente esses recursos ao Windows.
Temos então um possível vazamento de memória no kernel.
E esse tipo de problema não aparece necessariamente de forma óbvia na lista comum de processos.
É justamente isso que vamos investigar neste artigo.
O que é o Pool não paginado do Windows 11?
Antes de procurar um driver problemático, precisamos entender o que estamos observando.
O Windows possui um kernel responsável por funções fundamentais do sistema operacional.
Drivers também executam tarefas importantes relacionadas a componentes como:
- placa de rede;
- Wi-Fi;
- Bluetooth;
- armazenamento;
- USB;
- áudio;
- vídeo;
- antivírus;
- filtros de sistema;
- dispositivos físicos e virtuais.
Esses componentes precisam solicitar memória ao sistema operacional.
Parte das alocações realizadas pelo kernel e pelos drivers utiliza áreas conhecidas como pools de memória.
Entre elas estão:
Paged Pool
e:
Nonpaged Pool
Em português, normalmente veremos:
Pool paginado
e:
Pool não paginado
A diferença entre eles é importante.
O que significa “não paginado”?
A palavra pode parecer estranha para quem acabou de conhecer o conceito de memória virtual.
De forma simplificada, páginas pertencentes ao Nonpaged Pool precisam permanecer residentes na memória física enquanto estiverem alocadas.
Elas não podem simplesmente ser retiradas da RAM e colocadas no arquivo de paginação como forma de liberar aquele espaço físico.
Isso existe porque determinados códigos e estruturas do kernel precisam estar disponíveis em situações nas quais acessar armazenamento para recuperar uma página não seria apropriado.
Por isso:
Pool não paginado ocupa memória física.
Essa característica torna um crescimento anormal especialmente importante.
Isso significa que qualquer Pool não paginado é ruim?
Não.
O Windows precisa dessa memória para funcionar.
Drivers precisam dela.
O kernel precisa dela.
Portanto, encontrar algo como:
Pool não paginado: 500 MB
não significa automaticamente que existe vazamento.
O erro seria tentar “otimizar” o Windows procurando fazer:
Pool não paginado = 0 MB
Isso não faz sentido.
O que precisamos observar é o comportamento ao longo do tempo.
O comportamento é mais importante que um número isolado
Imagine que você inicia o Windows e encontra:
Pool não paginado: 420 MB
Duas horas depois:
Pool não paginado: 470 MB
Mais tarde:
Pool não paginado: 440 MB
Existe alguma variação.
Isso pode fazer parte do funcionamento normal.
Agora imagine outro computador.
Após iniciar:
Pool não paginado: 500 MB
Duas horas depois:
Pool não paginado: 1,2 GB
Quatro horas depois:
Pool não paginado: 2,8 GB
Oito horas depois:
Pool não paginado: 5,6 GB
E continua aumentando.
Esse comportamento é muito mais interessante para diagnóstico.
O que é um memory leak?
Um memory leak, ou vazamento de memória, acontece quando software solicita memória, deixa de utilizá-la adequadamente e não libera os recursos como deveria.
Com o passar do tempo, o consumo pode continuar crescendo.
Em um aplicativo comum, podemos imaginar:
programa inicia
↓
aloca memória
↓
utiliza memória
↓
não libera determinada alocação
↓
repete
↓
consumo cresce
Depois de horas:
500 MB
↓
1 GB
↓
2 GB
↓
4 GB
Dependendo do problema, fechar o programa pode liberar seus recursos.
Mas existe outra possibilidade.
Drivers também podem apresentar vazamento de memória
Quando o problema ocorre em código relacionado ao kernel, a investigação muda.
Um driver pode realizar alocações de pool e, devido a um bug ou determinada condição, deixar de liberar parte delas corretamente.
Podemos ter:
driver
↓
aloca memória
↓
executa determinada operação
↓
memória deveria ser liberada
↓
isso não acontece corretamente
↓
processo se repete
↓
pool cresce
Se essas alocações pertencem ao Nonpaged Pool, podemos observar o Pool não paginado aumentando progressivamente.
Por que isso deixa o Windows lento?
A RAM é um recurso finito.
Imagine um computador com:
16 GB de RAM
No início:
Windows + programas = 7 GB
Pool não paginado = 500 MB
Depois de muitas horas:
Pool não paginado = 6 GB
Agora uma quantidade enorme da memória física está presa nessas alocações.
O Windows passa a ter menos espaço para:
- aplicativos;
- cache;
- dados;
- working sets;
- outras estruturas do sistema.
A pressão sobre a memória aumenta.
O usuário pode achar que o Chrome é o culpado
Esse é um cenário bastante comum em diagnósticos de memória.
O usuário abre o Gerenciador de Tarefas e vê:
Memória: 92%
Depois ordena a lista de processos pela coluna:
Memória
Chrome aparece em primeiro:
Chrome: 1,8 GB
A conclusão imediata é:
“O Chrome está consumindo toda a minha RAM.”
Mas o computador possui:
16 GB
Mesmo adicionando outros processos:
Chrome 1,8 GB
Outlook 600 MB
Explorer 300 MB
Antivírus 400 MB
Outros 2 GB
a conta ainda não explica 14 ou 15 GB ocupados.
Precisamos olhar além da guia Processos.
A coluna Memória não representa toda a RAM do computador
Esse é um conceito fundamental.
O Gerenciador de Tarefas apresenta diferentes visões da memória.
A guia:
Processos
é excelente para identificar aplicativos que estão consumindo muita memória.
Mas não devemos simplesmente somar essa coluna e esperar que o resultado seja exatamente igual ao total apresentado em:
Desempenho
→
Memória
Existem outros consumidores e categorias de memória.
Por isso, quando os números parecem não fechar, precisamos investigar o sistema como um todo.
Onde encontrar o Pool não paginado?
Abra o Gerenciador de Tarefas:
Ctrl + Shift + Esc
Entre em:
Desempenho
Depois:
Memória
Na parte inferior da janela, procure:
Pool paginado
e:
Pool não paginado
Dependendo da versão e idioma do Windows, os nomes apresentados podem variar na tradução, mas os conceitos correspondem a:
Paged Pool
Nonpaged Pool
Anote o valor
Não faça alterações ainda.
Registre:
Horário:
RAM total:
RAM em uso:
RAM disponível:
Pool paginado:
Pool não paginado:
Por exemplo:
09:00
RAM total: 16 GB
Em uso: 7,4 GB
Disponível: 8,1 GB
Pool paginado: 620 MB
Pool não paginado: 480 MB
Continue usando o computador normalmente.
Depois faça outra medição.
Crie uma pequena linha do tempo
Imagine:
09:00 — 480 MB
11:00 — 730 MB
13:00 — 1,1 GB
15:00 — 1,8 GB
17:00 — 2,7 GB
19:00 — 3,9 GB
Agora temos algo muito mais útil do que:
“Minha RAM está alta.”
Temos um crescimento progressivo.
Esse padrão merece investigação.
Reiniciar o computador reduz o Pool não paginado?
Esse é outro teste muito interessante.
Imagine:
Antes de reiniciar:
Pool não paginado = 5,2 GB
Reiniciamos.
Depois:
Após reiniciar:
Pool não paginado = 450 MB
O computador fica normal.
Durante o dia:
450 MB
↓
900 MB
↓
1,8 GB
↓
3,4 GB
↓
5 GB
No dia seguinte, o problema retorna.
Esse padrão é bastante compatível com algum tipo de vazamento ou crescimento acumulativo que precisa ser identificado.
Reiniciar resolveu?
Não necessariamente.
O reinício pode liberar as alocações e reinicializar drivers.
O sintoma desaparece.
Mas se o mesmo crescimento retorna, a causa continua presente.
Podemos representar assim:
reinicia
↓
memória volta ao normal
↓
driver começa a trabalhar
↓
alocações crescem
↓
RAM fica cheia
↓
Windows fica lento
↓
reinicia
↓
ciclo começa novamente
Nesse caso, reiniciar é uma mitigação temporária.
Não é o diagnóstico.
O computador pode ficar normal por várias horas
Sim.
Isso torna esse problema especialmente confuso.
Imagine um driver que perde uma pequena quantidade de memória sempre que determinado evento acontece.
Por exemplo:
evento ocorre
↓
perde 200 KB
Uma única ocorrência não importa muito.
Mas se o evento acontece milhares de vezes:
200 KB
×
milhares de eventos
o consumo acumulado pode se tornar enorme.
Por isso, alguns computadores apresentam problema apenas depois de:
- muitas horas;
- vários dias ligados;
- várias suspensões;
- muito tráfego de rede;
- determinado uso de dispositivo.
O vazamento pode depender de uma atividade específica
Esse é um dos pontos mais importantes do diagnóstico.
Imagine:
Computador parado
↓
Pool não paginado estável
Começamos uma grande transferência de rede:
Pool começa a crescer
Terminamos a transferência:
Pool permanece alto
Fazemos outra transferência:
Pool cresce novamente
Agora existe uma possível relação com o subsistema de rede.
Ainda não sabemos qual driver é responsável, mas temos uma pista.
Rede é uma possível origem
Drivers de rede trabalham intensamente com o kernel.
Isso inclui:
- Ethernet;
- Wi-Fi;
- VPN;
- adaptadores virtuais;
- filtros;
- firewalls;
- softwares de segurança.
Se o crescimento acontece somente durante atividade de rede, precisamos observar essa relação.
Por exemplo:
Wi-Fi desligado
↓
Pool estável
Wi-Fi ligado
↓
tráfego intenso
↓
Pool cresce continuamente
Essa diferença merece investigação.
Isso significa que ndis.sys está com defeito?
Não podemos concluir isso apenas porque o problema envolve rede.
Assim como vimos no diagnóstico de Interrupções do Sistema, componentes genéricos do Windows podem participar da pilha sem representar a causa raiz.
A origem pode estar em:
- driver do adaptador;
- filtro de terceiros;
- VPN;
- antivírus;
- software de virtualização;
- outro componente relacionado.
Precisamos identificar quem está realizando as alocações.
Armazenamento também pode participar
Drivers relacionados a:
- SSD;
- HD;
- controladores;
- filtros de arquivos;
- backup;
- antivírus;
- criptografia;
também trabalham em nível de sistema.
Se o crescimento aparece durante cópias, backups ou acesso intenso ao armazenamento, anote essa informação.
O objetivo é descobrir:
qual atividade
↓
faz o Pool não paginado crescer
USB também pode estar envolvido
Imagine que o computador funciona normalmente sem determinado dispositivo.
Conectamos:
adaptador USB
Depois de algumas horas:
Pool não paginado = 3 GB
Reiniciamos sem o dispositivo.
Após o mesmo período:
Pool não paginado = 500 MB
Esse é um excelente teste comparativo.
O problema pode estar:
- no driver;
- no dispositivo;
- no software associado;
- em algum componente do subsistema USB.
VPN pode causar crescimento de memória do kernel?
Softwares VPN frequentemente instalam componentes de rede, adaptadores virtuais e filtros.
Isso não significa que VPNs normalmente apresentem vazamentos.
Mas se o problema começou após instalar ou atualizar um cliente específico, vale incluir essa variável no diagnóstico.
Compare:
VPN desconectada
↓
Pool estável
com:
VPN conectada
↓
Pool cresce
Repita o teste antes de concluir.
Antivírus também trabalha em baixo nível
Softwares de segurança podem instalar drivers e filtros para observar:
- arquivos;
- rede;
- processos;
- comportamento do sistema.
Por isso, determinados bugs nesses componentes podem afetar memória do kernel.
Isso não significa que a solução seja:
desativar antivírus permanentemente
O objetivo seria identificar:
- componente;
- versão;
- atualização;
- incompatibilidade.
Depois aplicar uma correção adequada.
Driver de vídeo pode provocar Pool não paginado alto?
Drivers gráficos são componentes complexos e também utilizam recursos do kernel.
Portanto, fazem parte das possibilidades.
Mas o diagnóstico não deve começar com:
“Pool alto? Reinstale o driver NVIDIA.”
Primeiro precisamos encontrar evidências.
Se o crescimento acontece apenas durante:
- jogos;
- reprodução de vídeo;
- uso de GPU;
- múltiplos monitores;
- determinada aplicação gráfica;
essa informação aumenta a relevância do subsistema gráfico.
Pool paginado e Pool não paginado são a mesma coisa?
Não.
Os dois fazem parte da memória utilizada pelo kernel, mas possuem características diferentes.
Simplificando:
Pool paginado
Determinadas páginas podem ser paginadas quando apropriado.
Pool não paginado
As páginas precisam permanecer residentes na memória física enquanto estiverem alocadas.
Essa diferença explica por que um vazamento grande no Nonpaged Pool pode exercer pressão importante sobre a RAM.
Pagefile.sys resolve um vazamento de Nonpaged Pool?
Não da forma como algumas pessoas imaginam.
Aumentar o arquivo:
pagefile.sys
não transforma o Nonpaged Pool em memória que pode simplesmente ser descarregada para o SSD.
A característica essencial do Nonpaged Pool é justamente a necessidade de permanecer residente.
Portanto, se um driver está vazando memória nessa área, aumentar o arquivo de paginação não corrige a causa.
Colocar mais RAM resolve?
Pode adiar o sintoma.
Imagine um vazamento de:
500 MB por hora
Em um computador com 8 GB, o problema aparece rapidamente.
Com 32 GB, talvez demore muito mais.
Mas:
500 MB/h
continua sendo:
500 MB/h
Se o crescimento não possui limite e decorre de um bug, mais RAM apenas aumenta o tempo até a pressão de memória se tornar perceptível.
Por isso precisamos encontrar quem está alocando a memória
O Gerenciador de Tarefas consegue mostrar:
Pool não paginado = 4,8 GB
Mas ainda falta responder:
Quem está usando esses 4,8 GB?
É aqui que o diagnóstico começa a ficar mais interessante.
Precisamos sair da visão geral do Gerenciador de Tarefas e analisar as alocações de memória do kernel.
Existem ferramentas capazes de ajudar nessa investigação.
Uma delas é:
RAMMap
Outra, muito importante em diagnósticos de pool, é:
PoolMon
O que é RAMMap?
RAMMap é uma ferramenta da suíte Sysinternals da Microsoft voltada para análise do uso de memória física do Windows.
Ela consegue mostrar categorias que o Gerenciador de Tarefas apresenta de maneira muito mais resumida.
Com ela podemos entender melhor para onde a RAM está sendo utilizada.
Isso é especialmente útil quando o usuário pergunta:
“Se meus programas não estão usando toda essa memória, quem está?”
O RAMMap substitui o Gerenciador de Tarefas?
Não.
As ferramentas se complementam.
Podemos começar com:
Gerenciador de Tarefas
↓
identificar Pool não paginado alto
Depois:
RAMMap
↓
entender melhor a distribuição da memória
E, quando precisamos identificar alocações de pool com mais detalhe:
PoolMon
O que é PoolMon?
PoolMon é uma ferramenta de diagnóstico voltada para acompanhar alocações dos pools de memória do kernel.
Em vez de mostrar apenas:
Pool não paginado = 4 GB
ela permite observar informações associadas às chamadas Pool Tags.
Isso abre uma nova etapa da investigação.
O que é uma Pool Tag?
Drivers e componentes do kernel podem associar identificadores às suas alocações de pool.
Esses identificadores ajudam a categorizar de onde determinadas alocações estão vindo.
Uma Pool Tag costuma possuir poucos caracteres.
Podemos imaginar um resultado conceitual como:
Tag Tipo Bytes
ABCD Nonp 3.200.000.000
EFGH Nonp 180.000.000
IJKL Paged 95.000.000
Se:
ABCD
está consumindo vários gigabytes e continua crescendo, encontramos uma pista muito mais específica.
Pool Tag não é necessariamente o nome do driver
Esse detalhe é fundamental.
Imagine encontrar:
ABCD
Isso não significa que exista:
ABCD.sys
A tag é um identificador utilizado nas alocações.
Precisamos depois relacioná-la ao componente ou driver correspondente.
Esse será um dos principais objetivos das próximas etapas.
O que realmente queremos encontrar?
Nosso diagnóstico ideal evolui assim:
Windows usando muita RAM
↓
programas não explicam o consumo
↓
Pool não paginado está muito alto
↓
Pool não paginado continua crescendo
↓
PoolMon identifica uma tag crescendo
↓
tag é relacionada a um driver/componente
↓
atividade do dispositivo confirma a hipótese
↓
driver é atualizado, revertido ou corrigido
↓
crescimento desaparece
Essa sequência transforma um problema aparentemente misterioso em um diagnóstico reproduzível.
Não comece removendo drivers aleatoriamente
Encontrar Pool não paginado alto não justifica:
remover driver Wi-Fi
remover driver de vídeo
remover chipset
desativar USB
desativar antivírus
tudo ao mesmo tempo.
Se fizer isso, talvez o problema desapareça.
Mas você não saberá por quê.
Use sempre:
medir
↓
criar hipótese
↓
alterar uma variável
↓
medir novamente
Faça o primeiro teste antes de instalar qualquer ferramenta
Por enquanto, você consegue realizar uma investigação muito útil apenas com o Gerenciador de Tarefas.
Registre:
Após reiniciar
Pool não paginado = ?
Depois de uma hora:
Pool não paginado = ?
Depois de algumas horas:
Pool não paginado = ?
E principalmente:
O que estava sendo feito quando começou a crescer?
Teste atividades como:
- rede;
- Wi-Fi;
- VPN;
- USB;
- armazenamento;
- jogos;
- suspensão;
- retorno da suspensão.
Procure uma correlação.
Um exemplo completo antes do PoolMon
Imagine um notebook com 16 GB de RAM.
Às:
08:00
Nonpaged Pool = 430 MB
O usuário trabalha normalmente.
Às:
10:00
Nonpaged Pool = 470 MB
Tudo normal.
Às 10:15 ele conecta uma VPN.
Às:
11:00
Nonpaged Pool = 1,1 GB
Às:
12:00
Nonpaged Pool = 2,3 GB
Desconecta a VPN.
O crescimento para.
Reinicia.
Repete o teste no dia seguinte.
O mesmo comportamento acontece.
Agora temos uma hipótese muito melhor:
cliente VPN
ou
driver/filtro relacionado
Isso torna a análise com PoolMon muito mais direcionada.
O padrão importa mais que o tamanho absoluto
Não existe um número universal do tipo:
Pool não paginado acima de X MB = defeito
Computadores possuem configurações, drivers, cargas e quantidades de RAM diferentes.
O sinal mais interessante é:
crescimento contínuo e inexplicável acompanhado de pressão de memória ou perda de desempenho.
Especialmente quando:
reiniciar
↓
reduz drasticamente
↓
uso específico
↓
faz crescer novamente
Esse padrão merece investigação.
Ainda não sabemos qual driver está consumindo a RAM
Neste ponto já conseguimos diferenciar duas perguntas.
A primeira:
“Existe um problema de Pool não paginado?”
A segunda:
“Qual driver está causando o crescimento?”
O Gerenciador de Tarefas ajuda muito na primeira.
Para responder a segunda, precisamos aprofundar a análise.
RAMMap e PoolMon: como descobrir quem está consumindo o Pool não paginado no Windows 11
Na primeira parte identificamos o principal padrão que merece investigação:
Windows inicia
↓
Pool não paginado está normal
↓
horas passam
↓
Pool não paginado cresce
↓
RAM disponível diminui
↓
computador começa a ficar lento
Também vimos que simplesmente olhar os programas no Gerenciador de Tarefas pode não explicar o consumo.
Agora precisamos responder uma pergunta muito mais específica:
qual componente está usando toda essa memória?
Para isso, vamos avançar para duas ferramentas importantes:
RAMMap
e:
PoolMon
Elas possuem funções diferentes.
O RAMMap ajuda a entender como a memória física está distribuída.
O PoolMon permite aprofundar a investigação das alocações de pool do kernel.
Antes das ferramentas: confirme novamente o crescimento
Não comece uma investigação avançada baseado em uma única leitura.
Abra:
Ctrl + Shift + Esc
Entre em:
Desempenho
→
Memória
Anote:
Em uso:
Disponível:
Confirmado:
Em cache:
Pool paginado:
Pool não paginado:
Imagine:
09:00
Em uso: 6,8 GB
Disponível: 8,7 GB
Pool paginado: 620 MB
Pool não paginado: 480 MB
Duas horas depois:
11:00
Em uso: 8,1 GB
Disponível: 7,4 GB
Pool paginado: 650 MB
Pool não paginado: 1,7 GB
Mais tarde:
14:00
Em uso: 11,6 GB
Disponível: 3,9 GB
Pool paginado: 670 MB
Pool não paginado: 5,1 GB
Agora temos uma evidência concreta.
O crescimento da RAM utilizada acompanha diretamente o crescimento do Nonpaged Pool.
Por que isso é diferente de um programa consumindo memória?
Se um navegador apresenta um vazamento, normalmente conseguimos observar seu consumo crescendo na lista de processos.
Por exemplo:
chrome.exe
800 MB
↓
1,5 GB
↓
3 GB
↓
5 GB
Nesse cenário, o processo oferece uma pista clara.
Com memória do kernel, podemos encontrar:
RAM usada = 14 GB
mas nenhum aplicativo aparece consumindo algo próximo disso.
O consumo pode estar em estruturas que não são representadas como memória privada de um processo comum.
RAMMap: uma visão muito mais detalhada da RAM
O RAMMap faz parte das ferramentas Sysinternals da Microsoft.
Ele foi desenvolvido justamente para permitir uma análise detalhada do uso da memória física no Windows.
Enquanto o Gerenciador de Tarefas resume:
Em uso
Disponível
Em cache
Pool paginado
Pool não paginado
o RAMMap permite examinar a memória sob diferentes perspectivas.
Isso ajuda muito quando os números parecem não fechar.
O RAMMap não é um “limpador de RAM”
Esse ponto merece destaque.
Algumas pessoas conhecem o RAMMap apenas porque ele possui opções relacionadas às listas de memória.
Mas seu principal valor em diagnóstico não está em clicar em opções para “liberar RAM”.
O objetivo aqui é:
entender para onde a memória foi.
Se existe um driver com vazamento, limpar determinada lista de memória não corrige o código responsável pelo vazamento.
Executando o RAMMap
Depois de obter a ferramenta pela fonte oficial da Microsoft Sysinternals, execute-a com os privilégios necessários para visualizar as informações do sistema.
Ao abrir, encontramos várias guias.
Entre elas podem aparecer áreas como:
Use Counts
Processes
Priority Summary
Physical Pages
Physical Ranges
File Summary
File Details
Cada uma apresenta a memória sob uma perspectiva diferente.
Para nosso problema, a guia:
Use Counts
é um excelente ponto de partida.
O que a guia Use Counts mostra?
Essa área agrupa páginas físicas conforme o tipo de utilização.
Dependendo do estado do sistema, podemos encontrar categorias relacionadas a:
- processos;
- arquivos mapeados;
- pool paginado;
- pool não paginado;
- metarquivos;
- tabelas de páginas;
- memória de drivers;
- estruturas do sistema.
O objetivo é confirmar que uma quantidade importante da memória está realmente associada à categoria que estamos investigando.
Active, Standby e outras colunas
O RAMMap também diferencia estados das páginas de memória.
Entre os conceitos que podemos encontrar estão:
Active
Standby
Modified
Modified no write
Transition
Zeroed
Free
Bad
Não precisamos transformar este artigo em uma documentação completa do gerenciador de memória do Windows.
Mas uma diferença é especialmente importante:
memória em Standby não deve ser confundida automaticamente com um vazamento de Nonpaged Pool.
Standby Memory alta não é a mesma coisa que Nonpaged Pool alto
Imagine um computador com bastante memória em:
Standby
O Windows pode estar utilizando RAM disponível para cache.
Essa memória pode ser reaproveitada conforme outras demandas aparecem.
Agora compare com vários gigabytes presos em:
Nonpaged Pool
São situações diferentes.
Por isso, simplesmente dizer:
“O Windows está usando muita RAM.”
não é diagnóstico suficiente.
Precisamos descobrir qual categoria está usando a RAM.
Por que programas que “limpam RAM” podem enganar?
Imagine que o computador possui vários gigabytes em cache.
Um programa de “otimização” força a remoção de dados dessas listas.
O usuário observa:
Antes:
RAM usada = alta
Depois:
RAM usada = menor
e conclui:
“O programa consertou minha memória.”
Mas o Windows poderia reutilizar grande parte daquele cache automaticamente quando necessário.
Além disso, remover cache pode obrigar o sistema a buscar novamente informações no armazenamento posteriormente.
Isso é muito diferente de corrigir um driver que está vazando memória do Nonpaged Pool.
O RAMMap ajuda a confirmar a categoria, mas ainda precisamos encontrar o responsável
Imagine que o RAMMap confirma:
Nonpaged Pool
5,4 GB
Agora sabemos que nossa suspeita estava correta.
Mas ainda falta responder:
“Qual driver ou componente criou essas alocações?”
É aqui que o PoolMon se torna especialmente importante.
O que é PoolMon?
PoolMon significa:
Pool Monitor
É uma ferramenta usada para acompanhar alocações nos pools de memória do kernel.
Ela permite observar como diferentes Pool Tags estão utilizando memória.
Em vez de enxergar apenas:
Nonpaged Pool = 5 GB
podemos chegar a uma visão parecida com:
Tag Type Allocs Frees Diff Bytes
ABCD Nonp 900000 10000 890000 3,8 GB
EFGH Nonp 20000 19800 200 40 MB
IJKL Paged 70000 69500 500 25 MB
Agora temos muito mais informação.
Onde está o PoolMon?
O PoolMon está associado às ferramentas de desenvolvimento e diagnóstico da Microsoft, normalmente disponibilizado através do Windows Driver Kit (WDK).
Isso significa que ele não deve ser tratado como um executável aleatório para baixar de qualquer site.
Quando precisar utilizá-lo, priorize a distribuição oficial da Microsoft.
PoolMon precisa de privilégios administrativos?
Para uma análise adequada do sistema, normalmente utilizamos um terminal com privilégios administrativos.
Abra o Terminal do Windows como administrador e execute o PoolMon a partir do local em que a ferramenta está instalada.
A interface é baseada em texto.
Isso pode assustar quem está acostumado apenas ao Gerenciador de Tarefas, mas as informações são extremamente úteis.
Como é a tela do PoolMon?
Uma visualização simplificada pode apresentar colunas como:
Tag
Type
Allocs
Frees
Diff
Bytes
Per Alloc
Essas colunas ajudam a responder perguntas diferentes.
Vamos entender cada uma.
Tag
A coluna:
Tag
apresenta a Pool Tag associada àquela categoria de alocação.
Podemos imaginar:
ABCD
File
NDxx
XYZ1
Esses identificadores ajudam a relacionar as alocações com componentes do sistema ou drivers.
A tag não precisa ser igual ao nome do arquivo .sys.
Esse é um erro importante que devemos evitar.
Type
A coluna:
Type
indica o tipo de pool.
Podemos encontrar algo relacionado a:
Paged
ou:
Nonp
Para nosso cenário, estamos especialmente interessados nas entradas relacionadas ao:
Nonp
ou Nonpaged Pool.
Se o Gerenciador de Tarefas mostra vários gigabytes de Pool não paginado, queremos descobrir quais tags estão contribuindo para esse total.
Allocs
A coluna:
Allocs
representa o número de alocações observadas para aquela tag.
Imagine:
Allocs = 1.500.000
É um número grande.
Mas isso sozinho não significa vazamento.
Precisamos observar também quantas alocações foram liberadas.
Frees
A coluna:
Frees
mostra as liberações correspondentes.
Por exemplo:
Allocs = 1.500.000
Frees = 1.499.800
Apesar do número enorme de alocações, a diferença é pequena.
Agora compare com:
Allocs = 1.500.000
Frees = 100.000
Existe uma diferença muito maior.
É aí que outra coluna se torna importante.
Diff
A coluna:
Diff
representa a diferença entre alocações e liberações.
De maneira simplificada:
Diff = Allocs - Frees
Exemplo:
Allocs = 500.000
Frees = 499.900
Diff = 100
Agora:
Allocs = 500.000
Frees = 50.000
Diff = 450.000
O segundo cenário merece muito mais atenção, principalmente se o valor continuar aumentando.
Diff alto significa automaticamente vazamento?
Não.
Essa é uma regra importante.
Uma tag pode legitimamente possuir muitas alocações ativas.
O diagnóstico depende do comportamento.
Queremos descobrir se:
Diff
continua aumentando ao mesmo tempo em que:
Bytes
cresce continuamente e o:
Pool não paginado
do sistema também aumenta.
Essa combinação é muito mais significativa.
Bytes
A coluna:
Bytes
é uma das mais interessantes.
Ela mostra a quantidade de memória associada às alocações ativas daquela tag.
Imagine:
Tag Type Bytes
AAAA Nonp 45 MB
BBBB Nonp 72 MB
CCCC Nonp 110 MB
DDDD Nonp 4 GB
Se o Pool não paginado total está em torno de 5 GB, a tag:
DDDD
merece atenção imediata.
Mas o maior consumidor nem sempre é o vazamento
Esse é outro detalhe importante.
Imagine:
Tag A = 800 MB estáveis
e:
Tag B = 300 MB
Dez minutos depois:
Tag A = 800 MB
Tag B = 700 MB
Depois:
Tag A = 810 MB
Tag B = 1,3 GB
Mais tarde:
Tag A = 805 MB
Tag B = 2,1 GB
Qual é mais interessante?
A Tag B.
Mesmo que inicialmente ela fosse menor, seu crescimento contínuo indica um comportamento que merece investigação.
Tire fotografias dos valores ao longo do tempo
Não precisa literalmente fotografar a tela, embora uma captura possa ajudar.
Registre:
10:00
Tag ABCD
Bytes = 400 MB
Diff = 50.000
Depois:
11:00
Tag ABCD
Bytes = 1,1 GB
Diff = 160.000
Depois:
12:00
Tag ABCD
Bytes = 2,4 GB
Diff = 340.000
Enquanto isso:
Pool não paginado:
500 MB
↓
1,3 GB
↓
2,7 GB
Agora temos uma correlação muito forte.
Ordenando o PoolMon
O PoolMon possui comandos de teclado para alterar a forma como os dados são classificados.
Uma das análises mais úteis consiste em ordenar pelo consumo em:
Bytes
Isso permite colocar os maiores consumidores em destaque.
Dependendo da versão da ferramenta, comandos de teclado permitem classificar por diferentes colunas.
Antes de usar atalhos encontrados em tutoriais antigos, confira a ajuda da versão instalada.
O princípio importante é:
queremos encontrar quais tags estão usando mais memória e quais continuam crescendo.
Não olhe apenas a primeira linha
Uma tag legítima pode ser naturalmente grande.
Por isso, o diagnóstico correto não é:
primeira linha
=
culpado
Faça:
medição 1
↓
medição 2
↓
medição 3
e compare.
O vazamento geralmente revela um padrão.
Exemplo prático de vazamento
Vamos imaginar que encontramos:
09:00
Tag Type Diff Bytes
Leak Nonp 20.000 180 MB
Uma hora depois:
10:00
Tag Type Diff Bytes
Leak Nonp 90.000 750 MB
Mais tarde:
11:00
Tag Type Diff Bytes
Leak Nonp 180.000 1,5 GB
E:
12:00
Tag Type Diff Bytes
Leak Nonp 350.000 3,1 GB
Ao mesmo tempo, o Gerenciador de Tarefas mostra:
Pool não paginado:
400 MB
↓
1 GB
↓
1,8 GB
↓
3,5 GB
Esse padrão é extremamente relevante.
Agora precisamos descobrir quem usa a Pool Tag
Encontrar a tag é apenas metade do trabalho.
Precisamos relacionar:
Pool Tag
a:
driver
ou:
componente
Essa etapa exige cuidado porque uma mesma tag pode exigir contexto adicional, e simplesmente pesquisar quatro caracteres na Internet pode gerar resultados errados.
Não confie cegamente em listas antigas de Pool Tags
Existem referências e bancos de dados históricos de tags.
Eles podem ajudar.
Mas drivers mudam.
Versões mudam.
Fabricantes podem reutilizar identificadores.
O próprio contexto do computador é essencial.
Por isso, se você encontrou:
ABCD
não conclua automaticamente:
“ABCD pertence ao driver X porque encontrei isso em um fórum de 2014.”
Precisamos verificar o sistema atual.
Procurando a tag dentro dos drivers
Uma estratégia técnica consiste em pesquisar a sequência correspondente à Pool Tag nos arquivos de drivers instalados.
O objetivo é encontrar quais binários contêm aquela identificação.
Isso pode aproximar:
Tag ABCD
de:
driverXYZ.sys
Mas mesmo essa relação precisa ser interpretada corretamente.
Encontrar uma sequência dentro de um binário cria uma pista; o comportamento do sistema ainda precisa confirmar a hipótese.
O utilitário Strings pode ajudar
Outra ferramenta da família Sysinternals é o:
Strings
Ela consegue procurar sequências de caracteres dentro de arquivos binários.
Em uma investigação avançada, podemos utilizá-la para procurar determinada Pool Tag dentro de drivers.
Conceitualmente:
PoolMon
↓
identifica ABCD
↓
Strings
↓
procura ABCD nos drivers
↓
encontra driverXYZ.sys
Agora temos um candidato.
Não execute buscas destrutivas nem altere os drivers
Pesquisar arquivos é uma coisa.
Apagar ou substituir manualmente arquivos .sys é completamente diferente.
Não faça:
del driverXYZ.sys
porque encontrou uma tag relacionada a ele.
Drivers podem ser essenciais para:
- inicialização;
- armazenamento;
- rede;
- segurança;
- hardware.
O objetivo dessa etapa é identificar, não destruir o componente.
Driver identificado: o que verificar?
Depois de chegar a um possível arquivo:
driverXYZ.sys
precisamos descobrir:
Qual fabricante?
Qual versão?
Qual dispositivo?
Quando foi instalado?
O problema começou depois de atualização?
Existe versão mais recente?
Existe versão anterior estável?
O dispositivo pode ser testado separadamente?
Essas perguntas transformam um nome técnico em um diagnóstico.
Como descobrir informações sobre um arquivo de driver?
O próprio Windows possui várias formas de relacionar drivers e dispositivos.
O Gerenciador de Dispositivos é uma das mais acessíveis.
Abra:
devmgmt.msc
Localize o hardware suspeito.
Entre em:
Propriedades
→
Driver
Observe:
Fornecedor
Data
Versão
Também podemos examinar os detalhes relacionados aos arquivos utilizados pelo dispositivo.
PowerShell também pode ajudar
Em uma investigação técnica, o PowerShell permite consultar informações do sistema.
Um exemplo útil para listar drivers assinados reconhecidos pelo Windows é:
Get-CimInstance Win32_PnPSignedDriver |
Select-Object DeviceName, DriverProviderName, DriverVersion, InfName
Isso pode ajudar a relacionar:
- dispositivo;
- fabricante;
- versão;
- pacote INF.
Não identifica sozinho qual driver está vazando memória, mas complementa a investigação depois que temos um candidato.
DriverQuery também oferece informações
O Windows possui:
driverquery
que pode listar drivers instalados/carregados com diferentes níveis de informação.
Por exemplo:
driverquery
e opções adicionais podem fornecer uma visão mais detalhada.
Novamente, o objetivo não é olhar uma lista enorme e adivinhar.
Use essas informações depois que PoolMon e outros testes já reduziram o número de suspeitos.
O nome do arquivo pode revelar o fabricante?
Às vezes.
Mas não confie apenas no nome.
Arquivos como:
xxxxx.sys
podem utilizar abreviações pouco intuitivas.
Verifique:
- propriedades do arquivo;
- assinatura digital;
- fabricante;
- dispositivo associado;
- pacote de driver.
Essas informações são mais confiáveis.
Exemplo: Pool Tag relacionada à rede
Imagine que o PoolMon mostra uma tag crescendo continuamente.
A investigação relaciona essa tag a um driver do adaptador Wi-Fi.
Agora precisamos confirmar.
Faça um teste:
Reinicia
↓
Wi-Fi desligado
↓
usa Ethernet
↓
Pool permanece estável
Depois:
Reinicia
↓
Wi-Fi ligado
↓
usa normalmente
↓
Pool começa a crescer
Repita.
Essa evidência é muito mais forte do que simplesmente encontrar o nome do driver.
Exemplo: VPN
Imagine:
Tag ABCD
↓
driver de filtro da VPN
Faça:
VPN desconectada
↓
Pool estável
Depois:
VPN conectada
↓
Tag ABCD começa a crescer
Se o padrão se repete, temos uma excelente pista.
Agora podemos verificar:
- atualização do cliente;
- versão anterior;
- documentação do fabricante;
- compatibilidade com a versão atual do Windows.
Exemplo: dispositivo USB
Outro cenário:
Tag EFGH
↓
driver relacionado ao dispositivo USB
Teste:
dispositivo desconectado
↓
tag permanece estável
Conecte:
dispositivo conectado
↓
tag começa a crescer
Repita.
Agora podemos investigar:
- driver;
- firmware;
- software do equipamento;
- dispositivo físico.
O valor pode parar de crescer quando desabilitamos o dispositivo
Esse comportamento é extremamente útil.
Imagine:
Pool não paginado = 3 GB
Desabilitamos temporariamente um dispositivo suspeito de maneira segura.
O valor pode não cair imediatamente porque determinadas alocações permanecem até o driver ser descarregado ou até o sistema reiniciar.
Mas o ponto importante pode ser:
antes:
+500 MB por hora
depois:
crescimento parou
Isso já fornece uma evidência importante.
Não espere que toda memória seja devolvida instantaneamente
Essa é uma armadilha.
Você identifica um driver suspeito e interrompe a atividade relacionada.
O usuário espera:
4 GB
↓
500 MB instantaneamente
Isso pode não acontecer.
Dependendo do componente e de como ele funciona, determinadas alocações podem permanecer até:
- driver descarregar;
- dispositivo reinicializar;
- serviço reiniciar;
- Windows reiniciar.
Por isso, além do valor absoluto, observe se o crescimento continua.
Reinicie para criar um teste limpo
Depois de identificar um candidato, uma comparação bastante útil é:
Reinicia
↓
anota Pool inicial
↓
não utiliza componente suspeito
↓
mede durante algumas horas
Depois, em outro teste:
Reinicia
↓
anota Pool inicial
↓
utiliza componente suspeito
↓
mede novamente
Se os resultados forem drasticamente diferentes, a hipótese ganha força.
Um gráfico simples ajuda muito
Podemos representar:
Horas Sem VPN Com VPN
0 h 450 MB 460 MB
1 h 470 MB 900 MB
2 h 460 MB 1,5 GB
3 h 480 MB 2,3 GB
4 h 475 MB 3,2 GB
Visualmente, o comportamento fica óbvio.
Não precisamos de uma ferramenta sofisticada para perceber a tendência.
PoolMon pode mostrar muitas tags
Sim.
Uma máquina real pode apresentar uma enorme quantidade de entradas.
Não tente pesquisar todas.
Procure primeiro:
- entradas do tipo Nonpaged;
- grande consumo em Bytes;
- Diff significativo;
- crescimento contínuo;
- correlação com o crescimento total do Nonpaged Pool.
Isso reduz bastante o trabalho.
A maior Pool Tag pode mudar
Isso também é normal.
O sistema está em constante atividade.
Uma tag pode temporariamente subir e depois liberar memória.
Outra pode ocupar mais espaço por determinado período.
Por isso, novamente:
uma captura isolada não basta.
Estamos procurando uma tendência.
Pool não paginado alto depois de dias pode ser normal?
O valor pode variar com a carga e configuração da máquina.
Não existe um limite universal em MB ou GB que sirva para qualquer computador.
Mas um comportamento como:
500 MB
↓
1 GB
↓
2 GB
↓
4 GB
↓
8 GB
sem estabilização, acompanhado de queda contínua da memória disponível, merece investigação.
Especialmente se reiniciar reduz drasticamente o valor e o mesmo crescimento começa novamente.
E se PoolMon não mostrar uma tag óbvia?
Nem todo caso será resolvido imediatamente.
Podemos ter:
- várias tags crescendo;
- componente complexo;
- alocações difíceis de relacionar;
- problema intermitente;
- comportamento que depende de evento específico.
Nesse caso, precisaremos de ferramentas e técnicas adicionais.
Uma delas é o Windows Performance Recorder, que já apareceu no artigo da VMIA sobre Interrupções do Sistema.
Também podemos avançar para recursos específicos de diagnóstico de drivers.
Driver Verifier entra nessa investigação?
Existe uma ferramenta do Windows chamada:
Driver Verifier
Ela pode ajudar desenvolvedores e técnicos a encontrar determinados comportamentos incorretos de drivers.
Porém, existe uma diferença enorme entre PoolMon e Driver Verifier.
PoolMon é principalmente uma ferramenta de observação.
Driver Verifier pode submeter drivers a verificações adicionais e provocar falhas intencionais do sistema quando detecta comportamento incorreto.
Isso significa que seu uso exige muito mais cuidado.
Ele não deve ser tratado como:
“Ative tudo e veja o que acontece.”
Em um computador de produção, essa estratégia pode gerar telas azuis e indisponibilidade.
Não precisamos começar com Driver Verifier
Para muitos casos, conseguimos avançar bastante com:
Gerenciador de Tarefas
↓
RAMMap
↓
PoolMon
↓
Pool Tag
↓
driver
↓
teste por eliminação
Driver Verifier deve ficar para situações específicas em que exista justificativa técnica e capacidade de recuperar o sistema caso ele deixe de inicializar normalmente.
Nosso diagnóstico agora ficou muito mais específico
Começamos com:
Meu Windows está usando 90% da RAM.
Depois descobrimos:
Os programas não explicam o consumo.
Avançamos:
Pool não paginado está com vários GB.
Agora:
PoolMon mostra uma Pool Tag crescendo.
O próximo objetivo é:
Pool Tag
↓
driver
↓
dispositivo/software
↓
teste
↓
correção
Como relacionar uma Pool Tag ao driver responsável no Windows 11
Depois de confirmar que o Pool não paginado está crescendo e identificar no PoolMon uma ou mais tags que acompanham esse crescimento, entramos na parte mais importante do diagnóstico:
descobrir qual driver, dispositivo ou software está por trás dessas alocações.
Até aqui, nosso caminho foi:
RAM alta
↓
programas não explicam o consumo
↓
Pool não paginado cresce
↓
PoolMon mostra uma tag crescendo
Agora queremos chegar a:
Pool Tag
↓
arquivo .sys
↓
driver
↓
dispositivo ou software
↓
teste de confirmação
Esse processo exige cuidado porque uma Pool Tag não é, necessariamente, o nome do driver.
Também não devemos assumir que o primeiro resultado encontrado na Internet identifica corretamente o componente instalado naquele computador.
Pool Tag e nome do driver são coisas diferentes
Imagine que o PoolMon mostra:
Tag: ABCD
Type: Nonp
Bytes: 2,8 GB
Não devemos concluir:
ABCD.sys
A tag funciona como um identificador associado a determinadas alocações.
O arquivo responsável pode ter um nome completamente diferente.
Por isso, precisamos procurar onde essa sequência aparece entre os drivers do sistema.
Antes de procurar o driver, confirme novamente que a tag realmente cresce
Uma tag grande pode ser perfeitamente legítima.
O que nos interessa é uma tendência.
Por exemplo:
09:00
ABCD = 250 MB
10:00
ABCD = 720 MB
11:00
ABCD = 1,4 GB
12:00
ABCD = 2,6 GB
Ao mesmo tempo:
Pool não paginado
500 MB
↓
1 GB
↓
1,8 GB
↓
3 GB
Essa correlação torna a tag muito mais relevante.
Compare Diff e Bytes
Uma investigação útil combina:
Diff
com:
Bytes
Imagine:
Tag ABCD
Diff:
20.000
↓
80.000
↓
170.000
↓
320.000
Enquanto:
Bytes:
200 MB
↓
700 MB
↓
1,5 GB
↓
2,9 GB
Isso mostra que existem cada vez mais alocações ativas associadas àquela tag.
Esse padrão merece atenção.
Como procurar a Pool Tag nos drivers
Uma abordagem técnica consiste em procurar a sequência da Pool Tag dentro dos arquivos .sys instalados no Windows.
Drivers normalmente ficam em áreas como:
C:\Windows\System32\drivers
Mas isso não significa que devemos abrir essa pasta e começar a alterar arquivos.
A ideia é apenas procurar referências.
Strings pode ajudar
A ferramenta Strings, da Microsoft Sysinternals, consegue extrair sequências legíveis de arquivos binários.
Em uma análise direcionada, podemos utilizá-la para procurar determinada tag em arquivos de driver.
Conceitualmente:
PoolMon
↓
Tag ABCD
↓
Strings
↓
procura ABCD nos arquivos .sys
↓
encontra possível driver
Essa informação cria uma pista.
Ainda precisamos confirmar.
Uma busca conceitual com Strings
A sintaxe pode variar conforme a versão e a forma como a ferramenta está instalada, mas o objetivo é pesquisar a Pool Tag dentro dos arquivos .sys.
Por exemplo, a lógica seria:
strings
+
arquivos .sys
+
procurar ABCD
Não copie comandos de sites antigos sem verificar a documentação da versão instalada.
Ferramentas Sysinternals evoluem, e parâmetros podem mudar.
O princípio é mais importante do que decorar um comando específico.
PowerShell também pode ajudar a localizar arquivos
Podemos usar o PowerShell para enumerar drivers existentes em:
C:\Windows\System32\drivers
Por exemplo:
Get-ChildItem C:\Windows\System32\drivers\*.sys
Isso apenas lista os arquivos.
Não revela automaticamente qual deles contém a tag.
Mas ajuda a entender o universo de drivers instalado.
Não faça pesquisa binária improvisada em centenas de arquivos sem necessidade
Se o PoolMon já mostra uma tag muito específica e o problema acontece somente com Wi-Fi, por exemplo, não precisamos investigar todos os drivers do Windows.
Use o contexto.
Imagine:
Pool Tag ABCD cresce
e:
Wi-Fi desligado
↓
crescimento para
Agora faz mais sentido investigar os drivers relacionados ao adaptador de rede do que cada arquivo .sys do sistema.
Descubra primeiro qual dispositivo está associado ao comportamento
Antes mesmo de chegar ao arquivo do driver, tente descobrir qual categoria provoca o crescimento.
Teste:
Wi-Fi
Ethernet
Bluetooth
USB
VPN
armazenamento
áudio
GPU
suspensão
Uma variável por vez.
Esse método reduz drasticamente o número de candidatos.
Exemplo: suspeita de Wi-Fi
Imagine:
Após reiniciar:
Nonpaged Pool = 480 MB
Com Ethernet durante quatro horas:
520 MB
Depois reiniciamos e utilizamos somente Wi-Fi.
Após quatro horas:
3,1 GB
Além disso, uma Pool Tag específica acompanha o crescimento.
Agora temos duas evidências:
Wi-Fi
+
Pool Tag
A investigação pode se concentrar no driver do adaptador sem fio e em componentes relacionados.
Como descobrir qual driver o adaptador usa
Abra:
devmgmt.msc
Depois:
Adaptadores de rede
↓
adaptador Wi-Fi
↓
Propriedades
↓
Driver
Registre:
Fornecedor
Data
Versão
Depois procure:
Detalhes do Driver
Essa área pode mostrar os arquivos associados ao dispositivo.
Podemos encontrar um ou mais arquivos .sys.
Agora temos nomes concretos para comparar com a Pool Tag e com outros resultados.
O PowerShell pode ajudar a documentar o driver
Use:
Get-CimInstance Win32_PnPSignedDriver |
Where-Object {$_.DeviceName -like "*Wi-Fi*"} |
Select-Object DeviceName, DriverProviderName, DriverVersion, InfName
Dependendo do nome do hardware, pode ser necessário ajustar o filtro.
Também podemos listar tudo:
Get-CimInstance Win32_PnPSignedDriver |
Select-Object DeviceName, DriverProviderName, DriverVersion, InfName
Depois procure o dispositivo de interesse.
O arquivo INF também é importante
Drivers do Windows geralmente são instalados a partir de pacotes INF.
Por isso, saber:
InfName
pode ajudar a identificar exatamente qual pacote está associado ao hardware.
Isso é útil quando existem várias versões do mesmo driver instaladas no Driver Store.
Driver Store não é uma pasta para limpeza manual
O Windows mantém pacotes de drivers em seu Driver Store.
Não apague arquivos manualmente dessa estrutura para “limpar drivers antigos”.
Isso pode quebrar reinstalações, rollback e funcionamento de dispositivos.
Se for necessário remover um pacote, use mecanismos apropriados do Windows e faça isso apenas quando houver uma justificativa clara.
pnputil pode mostrar drivers instalados
O Windows possui:
pnputil
Uma opção útil é listar pacotes de drivers instalados.
Por exemplo:
pnputil /enum-drivers
Podemos encontrar informações como:
Published Name
Original Name
Provider Name
Class Name
Driver Version
Signer Name
Isso ajuda bastante quando precisamos relacionar um dispositivo ao pacote instalado.
Não remova um driver porque a versão parece antiga
A data ou número da versão precisa ser interpretada no contexto do equipamento.
Notebooks e PCs OEM podem utilizar versões específicas testadas pelo fabricante.
O driver “mais novo” disponível diretamente no fabricante do chip nem sempre é o mais apropriado para determinado notebook.
Primeiro confirme:
hardware exato
+
versão instalada
+
origem do driver
+
momento em que o problema começou
Exemplo: atualização que introduziu o vazamento
Imagine:
Driver Wi-Fi versão A
↓
Pool estável
O Windows ou o fabricante instala:
versão B
Depois:
Pool não paginado começa a crescer
Voltamos temporariamente para uma versão anterior oficialmente compatível.
Resultado:
Pool estável novamente
Essa é uma evidência muito forte de regressão no driver.
Atualizar também pode corrigir
Agora imagine o cenário oposto.
Driver antigo:
2 GB de Nonpaged Pool após algumas horas
Instalamos uma atualização oficial que menciona correções de estabilidade.
Depois:
Pool permanece estável
Nesse caso, a atualização pode ter corrigido o problema.
O ponto é:
atualizar ou reverter deve ser parte de um teste, não um ritual automático.
Rede não envolve apenas o driver físico
Se a Pool Tag parece relacionada à rede, também precisamos considerar software que instala componentes na pilha.
Exemplos:
- VPN;
- firewall de terceiros;
- antivírus;
- ferramentas de captura;
- software de virtualização;
- adaptadores virtuais;
- filtros de tráfego.
Por isso:
rede = problema
não significa necessariamente:
placa Wi-Fi = defeito
VPN é uma variável importante
Clientes VPN podem adicionar drivers ou filtros.
Imagine:
VPN instalada, mas desconectada
↓
Pool estável
Depois:
VPN conectada
↓
Pool Tag começa a crescer
Desconecta:
crescimento para
Reinicia e repete.
O comportamento volta.
Agora a investigação deve incluir o cliente VPN e seus componentes.
Antivírus também pode instalar drivers de filtro
Softwares de segurança precisam observar diversos tipos de atividade.
Eles podem instalar componentes relacionados a:
- sistema de arquivos;
- rede;
- processos;
- proteção em baixo nível.
Se o problema começou depois de uma atualização do antivírus, essa informação merece atenção.
Mas não desative permanentemente a proteção como solução.
Primeiro procure:
- atualização corretiva;
- versão problemática;
- conflito conhecido;
- configuração;
- suporte oficial do fornecedor.
Drivers de armazenamento podem causar vazamento?
Podem existir bugs relacionados a drivers de armazenamento e filtros associados.
Possíveis componentes incluem:
- controlador SATA;
- NVMe;
- software de backup;
- criptografia;
- antivírus;
- filtros de sistema de arquivos;
- software de sincronização.
Se o Pool cresce principalmente durante:
cópias
backup
uso intenso de disco
essa correlação merece investigação.
Procure erros no Visualizador de Eventos
Abra:
eventvwr.msc
Observe principalmente eventos próximos dos horários em que:
Pool começa a crescer
ou:
sistema apresenta lentidão
Procure eventos relacionados ao dispositivo suspeito.
O Visualizador de Eventos pode não mostrar nada.
Isso não elimina a hipótese.
Mas se encontramos um erro do mesmo dispositivo exatamente no horário do problema, a evidência fica mais forte.
USB: driver ou dispositivo físico?
Imagine que a Pool Tag foi relacionada a um driver de um equipamento USB.
Precisamos separar:
driver
de:
hardware
Faça:
Dispositivo conectado
↓
Pool cresce
Depois:
Dispositivo desconectado
↓
Pool permanece estável
Agora, quando possível, teste:
outro dispositivo igual
ou:
mesmo dispositivo em outro computador
Essas comparações ajudam a descobrir se o problema acompanha o hardware.
Cabo e hub também fazem parte do cenário USB
Não ignore:
- cabo;
- hub;
- dock;
- porta;
- alimentação.
Imagine:
dispositivo conectado pelo hub
↓
Pool cresce
Depois:
mesmo dispositivo diretamente no computador
↓
Pool estável
A hipótese muda.
Talvez o dispositivo esteja correto e o problema esteja no caminho de conexão.
Vídeo: Pool alto durante jogos não prova problema de GPU
Drivers gráficos podem utilizar grandes quantidades de memória e estruturas do kernel.
Mas precisamos distinguir:
uso legítimo durante carga
de:
crescimento sem liberação
Imagine:
Abre jogo:
Pool sobe de 500 MB para 900 MB
Fecha o jogo:
Pool estabiliza
Isso pode ser normal.
Agora:
cada vez que abre e fecha o jogo
Pool aumenta mais 500 MB
Depois de várias execuções:
4 GB
sem retornar ou estabilizar.
Esse padrão é muito mais suspeito.
O mesmo vale para áudio
Imagine um driver de interface de áudio.
Ao abrir o programa:
Pool aumenta um pouco
Ao fechar:
estabiliza
Isso pode ser legítimo.
Agora:
inicia gravação
↓
+100 MB
encerra
↓
não libera
repete
↓
+100 MB
Depois de dezenas de operações, o consumo se torna enorme.
Esse comportamento é típico do tipo de padrão que estamos tentando encontrar.
Suspensão pode disparar um vazamento
Alguns problemas aparecem apenas depois de:
Suspender
↓
Retomar
Faça uma medição.
Exemplo:
Após reiniciar:
Nonpaged Pool = 450 MB
Suspenda e retome:
700 MB
Repita:
1,1 GB
Repita novamente:
1,6 GB
Se cada ciclo adiciona memória que não volta, existe uma pista muito forte.
Descubra qual dispositivo muda de estado durante suspensão
Teste, quando fizer sentido:
Wi-Fi desligado antes da suspensão
Depois:
Bluetooth desligado
Depois:
dock removido
Uma variável por vez.
Se o crescimento desaparece ao retirar determinado componente do cenário, temos uma direção clara.
Driver Verifier: ferramenta poderosa, mas não é um teste inocente
O Windows possui o:
verifier.exe
conhecido como Driver Verifier.
Ele consegue aplicar verificações adicionais sobre drivers.
Seu objetivo é ajudar a revelar comportamento incorreto.
Mas existe uma característica importante:
ele pode provocar telas azuis propositalmente quando detecta uma violação.
Isso faz parte do funcionamento da ferramenta.
Por que Driver Verifier exige cuidado?
Se configurado indiscriminadamente, ele pode:
- reduzir desempenho;
- provocar BSOD;
- tornar o Windows instável;
- complicar a inicialização;
- dificultar o trabalho em um computador de produção.
Por isso, não use a estratégia:
verifier
↓
selecionar todos os drivers
↓
reiniciar
↓
ver o que acontece
como primeira tentativa.
Quando Driver Verifier faz sentido?
Ele pode ser útil quando:
- já existe um grupo pequeno de drivers suspeitos;
- existe capacidade técnica para analisar dumps;
- o computador possui backup;
- sabemos como desfazer a configuração;
- a máquina pode ficar temporariamente indisponível.
É uma ferramenta de diagnóstico avançado, não uma opção de “otimização”.
Não use Driver Verifier sem plano de recuperação
Antes de ativá-lo, o técnico precisa saber como:
- entrar em ambiente de recuperação;
- inicializar em Modo de Segurança;
- desativar o Verifier;
- analisar eventual dump.
Se o usuário depende do computador para trabalho e não possui alternativa, o risco precisa ser considerado.
Como desativar o Driver Verifier
Uma forma conhecida de limpar sua configuração é:
verifier /reset
Normalmente será necessário reiniciar o computador para que a alteração seja aplicada completamente.
Essa informação é importante antes de qualquer teste.
Não vamos transformar o artigo em um tutorial de crash intencional
Para investigar Nonpaged Pool, muitas vezes nem precisamos chegar ao Driver Verifier.
Primeiro esgote métodos menos invasivos:
Gerenciador de Tarefas
↓
RAMMap
↓
PoolMon
↓
Pool Tag
↓
driver
↓
teste por eliminação
↓
atualização/reversão
Se isso resolver, não existe motivo para aumentar a complexidade.
Windows Performance Recorder pode complementar o diagnóstico
Outro caminho avançado utiliza:
Windows Performance Recorder
e:
Windows Performance Analyzer
Essas ferramentas ajudam a registrar atividade ao longo do tempo.
São úteis quando precisamos correlacionar:
atividade específica
+
crescimento de memória
+
driver
+
momento exato
Por que uma linha do tempo ajuda?
Imagine que o Pool cresce somente quando um programa específico faz upload pela rede.
Você inicia uma captura.
Depois:
10:01 — abre aplicativo
10:02 — inicia upload
10:03 — Pool cresce rapidamente
10:05 — upload termina
10:05 — memória não é liberada
Agora temos uma janela muito bem definida para investigar.
Isso é muito melhor do que analisar várias horas de atividade sem saber quando o problema aconteceu.
WPR/WPA substituem PoolMon?
Não.
As ferramentas resolvem perguntas diferentes.
Podemos pensar assim:
Gerenciador de Tarefas
↓
Existe Pool alto?
RAMMap
↓
Como a memória física está distribuída?
PoolMon
↓
Qual Pool Tag está consumindo?
WPR/WPA
↓
O que aconteceu no sistema quando o crescimento ocorreu?
Essa combinação pode tornar um diagnóstico difícil muito mais claro.
E se a tag aponta para um driver da Microsoft?
Não conclua imediatamente que o Windows está com defeito.
Um driver da Microsoft pode fazer parte de uma cadeia maior.
Imagine:
aplicativo
↓
driver de terceiro
↓
componente do Windows
↓
alocação
A ferramenta pode destacar uma parte intermediária.
Precisamos correlacionar com:
- hardware;
- software instalado;
- evento que dispara o crescimento.
SFC resolve Pool não paginado alto?
O comando:
sfc /scannow
verifica integridade de arquivos de sistema protegidos.
Ele pode ser útil quando existem indícios de corrupção do Windows.
Mas não corrige automaticamente:
driver de terceiro com memory leak
Se um driver está programado de maneira incorreta e continua alocando memória, SFC não reescreve esse driver para corrigir o bug.
DISM resolve?
O DISM pode reparar determinados componentes da imagem do Windows.
Novamente, isso pode ser útil em problemas de integridade do sistema.
Mas não é uma solução genérica para vazamentos de Pool não paginado.
Não devemos transformar:
DISM /Online /Cleanup-Image /RestoreHealth
em resposta automática para qualquer problema de memória.
Pagefile maior também não resolve a causa
Reforçando um ponto importante:
Nonpaged Pool
precisa permanecer residente na memória física enquanto alocado.
Aumentar:
pagefile.sys
pode ajudar o sistema em outros tipos de pressão de memória, mas não corrige o driver responsável pelo vazamento.
Mais RAM também pode apenas esconder o problema
Imagine:
vazamento = 1 GB a cada 6 horas
Com 8 GB:
problema aparece rapidamente
Com 32 GB:
problema demora muito mais
Mas o bug continua.
Se o computador permanece ligado por muitos dias, o problema pode reaparecer.
Reinicialização periódica também é apenas uma mitigação
Configurar:
reiniciar toda madrugada
pode impedir que o consumo chegue a níveis críticos.
Em alguns servidores ou sistemas temporários, isso pode até ser usado como contingência.
Mas em um PC onde queremos corrigir a causa, o ideal é encontrar:
qual driver está vazando
e resolver o problema na origem.
Quando o hardware começa a ser um suspeito mais forte?
A suspeita aumenta quando:
- várias versões corretas do driver apresentam o mesmo comportamento;
- o problema acompanha o dispositivo em outro computador;
- outro dispositivo equivalente não causa o vazamento;
- existe firmware atualizado e o problema continua;
- há outros sintomas físicos ou erros;
- reinstalar o Windows não altera o comportamento.
Mesmo assim, cada caso precisa ser analisado individualmente.
Exemplo completo: driver Wi-Fi com vazamento
Vamos montar um diagnóstico do início ao fim.
Após reiniciar:
Nonpaged Pool = 450 MB
Depois de quatro horas no Wi-Fi:
3,2 GB
PoolMon mostra:
Tag ABCD
Bytes = 2,5 GB
A tag é relacionada ao driver do adaptador Wi-Fi.
Testamos Ethernet:
4 horas
Nonpaged Pool = 500 MB
Voltamos ao Wi-Fi:
4 horas
Nonpaged Pool = 3 GB
Revertemos para uma versão anterior oficialmente suportada.
Novo teste:
4 horas no Wi-Fi
Nonpaged Pool = 520 MB
Agora existe uma cadeia de evidências bastante forte.
Outro exemplo: VPN
Cenário inicial:
Após reiniciar = 500 MB
VPN desconectada por seis horas:
560 MB
VPN conectada:
500 MB
↓
1,2 GB
↓
2,1 GB
↓
3,6 GB
PoolMon mostra uma tag relacionada ao driver do cliente VPN.
Atualizamos o software.
Novo teste:
VPN conectada por seis horas
Nonpaged Pool = 610 MB
Esse é um diagnóstico muito mais sólido do que simplesmente dizer:
“A RAM estava alta e atualizei os drivers.”
Outro exemplo: dispositivo USB
Após reiniciar:
Pool = 430 MB
Conectamos um equipamento USB específico:
1 hora = 900 MB
2 horas = 1,5 GB
3 horas = 2,2 GB
Sem o equipamento:
3 horas = 470 MB
PoolMon aponta uma tag associada ao driver do dispositivo.
Atualização do driver não resolve.
O mesmo dispositivo reproduz o problema em outro computador.
Outro dispositivo igual funciona normalmente.
Agora a suspeita física sobre aquela unidade aumenta bastante.
A melhor investigação combina software e teste prático
Ferramentas sozinhas podem produzir pistas.
Mas a confirmação normalmente vem de:
medição
+
Pool Tag
+
driver
+
atividade
+
repetibilidade
Essa combinação reduz bastante as chances de trocar peças ou reinstalar software sem necessidade.
Não pare no nome do .sys
Encontrar:
driverXYZ.sys
não é o fim.
Pergunte:
Quem instalou esse driver?
Qual dispositivo o utiliza?
O que dispara o crescimento?
Existe atualização?
Existe uma versão anterior estável?
O problema desaparece sem esse componente?
Só depois podemos falar em causa provável.
Estamos perto de fechar o diagnóstico
Agora conseguimos seguir:
Pool não paginado cresce
↓
PoolMon encontra tag
↓
tag é relacionada a um driver
↓
driver é associado a hardware ou software
↓
teste por eliminação confirma
↓
atualização, reversão ou correção
↓
Pool permanece estável
Checklist completo para diagnosticar Pool não paginado alto no Windows 11
Depois de entender o que é o Pool não paginado, confirmar que ele está crescendo, usar o RAMMap para visualizar melhor a distribuição da memória e recorrer ao PoolMon para localizar uma Pool Tag suspeita, podemos fechar o diagnóstico com um método organizado.
A ideia é evitar duas armadilhas comuns:
RAM alta
↓
culpar o primeiro programa da lista
ou:
Pool não paginado alto
↓
reinstalar todos os drivers
Nenhuma dessas abordagens é confiável.
O diagnóstico precisa responder três perguntas:
1. O crescimento é realmente anormal?
2. Qual componente está associado ao crescimento?
3. A hipótese se repete em testes controlados?
Primeiro: confirme que existe realmente um problema
O Windows utiliza memória agressivamente para melhorar desempenho.
RAM ocupada, isoladamente, não representa defeito.
Também não existe um valor universal do tipo:
Pool não paginado acima de 1 GB = problema
O que importa é o contexto.
Um cenário mais suspeito seria:
08:00 — 450 MB
10:00 — 900 MB
12:00 — 1,8 GB
14:00 — 3,2 GB
16:00 — 5,1 GB
principalmente quando a memória disponível diminui continuamente e o sistema começa a apresentar lentidão.
Agora compare com:
08:00 — 480 MB
10:00 — 520 MB
12:00 — 470 MB
14:00 — 560 MB
16:00 — 510 MB
Apesar das variações, existe estabilidade.
Essa diferença é essencial.
Sintomas que combinam com vazamento de Nonpaged Pool
Alguns comportamentos tornam a hipótese mais forte.
O computador pode começar funcionando perfeitamente e piorar depois de horas ou dias.
O usuário percebe:
- uso de RAM crescendo continuamente;
- poucos programas abertos;
- memória que não parece aparecer na guia Processos;
- Pool não paginado aumentando;
- redução constante da memória disponível;
- desempenho pior depois de muitas horas;
- normalização temporária após reiniciar;
- retorno progressivo do problema.
Esse conjunto é muito mais relevante do que qualquer número isolado.
Reiniciar é um excelente teste, mas não uma correção definitiva
Imagine:
Antes de reiniciar
RAM em uso = 15 GB
Pool não paginado = 6,2 GB
Depois:
Após reiniciar
RAM em uso = 5 GB
Pool não paginado = 480 MB
O computador volta ao normal.
Depois de algumas horas:
480 MB
↓
1,1 GB
↓
2,3 GB
↓
4,5 GB
Esse comportamento mostra que o consumo é acumulativo.
O reinício zerou o estado, mas não eliminou a causa.
Checklist completo de diagnóstico
Um método prático pode seguir esta sequência:
1. Reinicie o computador
2. Anote o Pool não paginado inicial
3. Anote RAM em uso e disponível
4. Use o computador normalmente
5. Registre novos valores em intervalos
6. Identifique qual atividade coincide com o crescimento
7. Confirme com RAMMap
8. Execute PoolMon
9. Identifique tags que crescem
10. Compare Diff e Bytes
11. Relacione a tag ao driver
12. Identifique dispositivo ou software
13. Teste uma variável por vez
14. Atualize ou reverta o driver quando justificável
15. Repita exatamente o mesmo teste
16. Confirme se o crescimento desapareceu
O passo mais importante é o último.
Uma alteração só é considerada relevante quando o comportamento melhora de maneira reproduzível.
Crie uma linha de base depois de reiniciar
Após reiniciar, abra:
Ctrl + Shift + Esc
Depois:
Desempenho
→
Memória
Anote:
RAM total:
Em uso:
Disponível:
Confirmado:
Em cache:
Pool paginado:
Pool não paginado:
Exemplo:
09:00
RAM total: 16 GB
Em uso: 5,9 GB
Disponível: 9,6 GB
Pool paginado: 580 MB
Pool não paginado: 460 MB
Esse será o ponto de referência.
Faça novas medições
Uma hora depois:
10:00
Em uso: 6,2 GB
Disponível: 9,3 GB
Pool não paginado: 490 MB
Depois:
12:00
Em uso: 7,8 GB
Disponível: 7,7 GB
Pool não paginado: 2 GB
Agora pergunte:
O que mudou entre 10:00 e 12:00?
Talvez o usuário tenha:
- conectado VPN;
- iniciado backup;
- usado Wi-Fi intensamente;
- conectado dock USB;
- ligado uma interface de áudio;
- voltado da suspensão;
- iniciado um jogo;
- transferido muitos arquivos.
Essa informação direciona o próximo teste.
Use uma variável por vez
Imagine que entre 10:00 e 12:00 aconteceram três coisas:
VPN
+
dock USB
+
backup
Se você simplesmente repetir tudo, não saberá qual delas influencia o comportamento.
Teste separadamente.
Dia 1:
VPN ligada
dock desconectado
sem backup
Dia 2:
VPN desligada
dock conectado
sem backup
Dia 3:
VPN desligada
dock desconectado
backup ativo
Esse método pode parecer mais demorado, mas economiza muito tempo em diagnósticos difíceis.
Use o RAMMap para confirmar para onde a RAM foi
Se o Gerenciador de Tarefas mostra:
RAM usada = 14 GB
e os processos visíveis não explicam esse número, abra o RAMMap.
Procure confirmar se existe uma parcela grande associada ao:
Nonpaged Pool
Se o valor do RAMMap acompanha o mostrado pelo Gerenciador de Tarefas, nossa investigação ganha consistência.
Quando o problema pode ser Standby Memory e não Pool não paginado
Imagine:
RAM total = 16 GB
Disponível = 8 GB
Standby = vários GB
Nonpaged Pool = 450 MB
Nesse cenário, não temos evidência de um vazamento de Nonpaged Pool.
Memória em Standby é reutilizável pelo Windows conforme necessário.
Não confunda:
cache
com:
vazamento de memória
Essa distinção evita muita “otimização” desnecessária.
Quando o PoolMon entra
Se o problema é realmente:
Nonpaged Pool crescendo
execute o PoolMon e procure:
Type = Nonp
Observe principalmente:
Tag
Diff
Bytes
Não procure apenas a maior linha.
Procure a entrada que apresenta crescimento contínuo.
Um padrão convincente no PoolMon
Imagine:
10:00
Tag XYZ1
Bytes = 180 MB
Diff = 15.000
Depois:
11:00
Bytes = 850 MB
Diff = 74.000
Depois:
12:00
Bytes = 1,9 GB
Diff = 160.000
Ao mesmo tempo:
Nonpaged Pool
500 MB
↓
1,2 GB
↓
2,3 GB
Essa tag merece investigação.
Agora relacione a tag ao driver
O próximo passo é descobrir qual driver ou componente utiliza aquela Pool Tag.
Ferramentas como Strings podem ajudar a procurar a tag dentro dos binários dos drivers.
Também utilize informações do próprio Windows:
devmgmt.msc
driverquery
pnputil /enum-drivers
e:
Get-CimInstance Win32_PnPSignedDriver
O objetivo é transformar:
Tag XYZ1
em algo como:
driverXYZ.sys
↓
adaptador Wi-Fi
↓
Fabricante X
↓
versão Y
Agora temos um candidato real.
Teste o componente suspeito
Suponha que chegamos ao Wi-Fi.
Teste:
Wi-Fi desligado
Ethernet ligada
Use o computador pelo mesmo período.
Se:
Nonpaged Pool permanece estável
reinicie e faça o contrário:
Ethernet desligada
Wi-Fi ligada
Se o Pool volta a crescer, a hipótese fica muito mais forte.
Repita antes de concluir
Um único teste pode coincidir com outro evento.
O ideal é reproduzir.
Por exemplo:
Teste 1
Wi-Fi = Pool cresce
Teste 2
Ethernet = Pool estável
Teste 3
Wi-Fi = Pool cresce novamente
Agora existe repetibilidade.
Driver suspeito: atualizar ou fazer rollback?
Depende da cronologia.
Se o problema começou logo após uma atualização:
versão antiga
↓
normal
versão nova
↓
vazamento
um rollback controlado pode ser um teste válido.
Se a máquina utiliza uma versão antiga e existe uma atualização oficial posterior, atualizar também pode ser apropriado.
O importante é registrar:
versão antes
↓
resultado
↓
versão depois
↓
resultado
Evite atualizadores automáticos de drivers
Programas que prometem:
atualizar todos os drivers automaticamente
podem instalar versões inadequadas ou dificultar a rastreabilidade do diagnóstico.
Prefira:
- fabricante do computador;
- fabricante do componente;
- Windows Update quando apropriado;
- pacote oficial do fornecedor.
Quanto mais controlado for o processo, mais fácil saber qual alteração resolveu ou piorou o problema.
Chipset deve ser investigado?
Pode.
Drivers e componentes associados ao chipset participam da comunicação entre diferentes partes do sistema.
Mas não atualize chipset automaticamente apenas porque existe Pool alto.
Primeiro procure evidências que indiquem essa direção.
BIOS ou UEFI pode corrigir?
Em determinados equipamentos, atualizações de firmware podem corrigir problemas relacionados a energia, dispositivos e compatibilidade.
Mas BIOS não deve ser tratada como primeira solução para memória alta.
Considere-a quando:
- fabricante documenta correção relevante;
- problema está relacionado a suspensão ou hardware;
- outras evidências apontam nessa direção.
Atualizações de firmware exigem cuidado extra porque falhas durante o processo podem impedir a inicialização do equipamento.
Pool alto depois de suspensão
Se o vazamento aparece principalmente após:
Suspender
↓
Retomar
crie um teste específico.
Por exemplo:
Após reiniciar = 450 MB
Primeiro ciclo:
650 MB
Segundo:
900 MB
Terceiro:
1,3 GB
Quarto:
1,8 GB
Agora teste componentes individualmente antes da suspensão.
Wi-Fi desligado:
sem crescimento
Wi-Fi ligado:
crescimento retorna
Essa é uma pista muito forte para o subsistema de rede ou algum componente associado.
Inicialização Rápida pode confundir alguns testes
No Windows, desligar e ligar nem sempre equivale ao mesmo caminho interno de uma reinicialização completa.
Por isso, durante investigação de drivers, prefira:
Reiniciar
quando quiser criar uma linha de base limpa.
Isso reduz ambiguidades relacionadas ao estado anterior do sistema.
Quando remover temporariamente um software faz sentido
Imagine que o PoolMon aponta para um componente associado a:
VPN
e o comportamento desaparece quando a VPN não é utilizada.
Uma atualização não resolve.
Nesse cenário, remover temporariamente o cliente e repetir o teste pode ser útil.
Mas faça isso de maneira controlada.
Registre primeiro:
versão
configuração
nome do software
driver associado
Depois reinstale, se necessário, utilizando fonte oficial.
O mesmo vale para software de segurança
Se existe forte evidência envolvendo um filtro instalado por um antivírus de terceiros, a investigação pode exigir:
- atualização;
- suporte do fabricante;
- teste controlado;
- eventual reinstalação.
Não deixe o computador permanentemente sem proteção apenas para reduzir uso de memória.
Quando o hardware é mais provável
Drivers são frequentemente suspeitos em vazamentos de Nonpaged Pool, mas hardware também pode participar indiretamente.
A hipótese física ganha força quando:
mesmo dispositivo
↓
mesmo problema
↓
em outro computador
enquanto:
outro dispositivo equivalente
↓
funciona normalmente
Isso é especialmente útil em:
- adaptadores USB;
- placas de rede;
- docks;
- interfaces externas.
E se o problema continuar mesmo depois de reinstalar o Windows?
Uma instalação limpa pode eliminar muitos componentes de terceiros.
Imagine:
Windows limpo
↓
driver oficial
↓
problema ainda acontece com o mesmo dispositivo
Isso aumenta a suspeita sobre:
- driver oficial específico;
- firmware;
- hardware;
- interação entre componentes.
Mas não formate o computador cedo demais.
Por que formatar cedo pode atrapalhar?
Imagine que o sistema apresenta um vazamento apenas depois de instalar determinado software.
Se você formata tudo, perde várias pistas:
- versão instalada;
- eventos;
- drivers;
- configuração;
- cronologia.
O problema pode até desaparecer.
Mas você não saberá exatamente por quê.
Se depois reinstalar o mesmo componente, o vazamento pode retornar.
Quando uma instalação limpa é útil
Ela pode fazer sentido quando:
- diagnóstico já eliminou várias hipóteses;
- sistema está muito modificado;
- existem conflitos difíceis de reproduzir;
- backups estão garantidos;
- há tempo para testar progressivamente.
Uma boa instalação de diagnóstico segue:
Windows
↓
testa
↓
chipset
↓
testa
↓
rede
↓
testa
↓
software adicional
↓
testa
Assim conseguimos descobrir em que momento o problema aparece.
Driver Verifier: quando considerar
Driver Verifier pode ajudar em casos avançados nos quais:
- existe um pequeno grupo de drivers suspeitos;
- PoolMon não foi suficiente;
- o técnico consegue analisar dumps;
- existe plano de recuperação.
Ele não deve ser primeira escolha.
Ativá-lo de forma indiscriminada pode provocar instabilidade proposital.
O risco de marcar todos os drivers
Selecionar todos os drivers sem critério pode tornar o computador praticamente inutilizável durante o teste.
Além disso, aumenta o ruído do diagnóstico.
O melhor cenário é:
evidência
↓
pequeno grupo de suspeitos
↓
verificação direcionada
e não:
não sei qual driver é
↓
testar tudo
Se o Windows entrar em loop após Driver Verifier
Esse é justamente o motivo pelo qual a ferramenta exige conhecimento de recuperação.
O técnico deve saber utilizar opções como:
verifier /reset
e recorrer ao Modo de Segurança ou ambiente de recuperação quando necessário.
Não utilize Driver Verifier em uma máquina crítica sem conhecer previamente como desfazer a configuração.
Quando WPR e WPA entram
Se o vazamento depende de um evento específico e difícil de reproduzir visualmente, Windows Performance Recorder e Windows Performance Analyzer podem ajudar.
Exemplo:
10:00 — Pool normal
10:10 — conecta dock
10:12 — inicia transferência
10:15 — Pool começa a crescer
Capturar exatamente esse intervalo permite analisar o que aconteceu naquele momento.
Ferramentas não substituem raciocínio
Você pode ter:
- Task Manager;
- RAMMap;
- PoolMon;
- Strings;
- Process Explorer;
- WPR;
- WPA;
- Driver Verifier.
E ainda assim chegar a uma conclusão errada se não comparar cenários.
O valor real está em:
observar
↓
formular hipótese
↓
testar
↓
repetir
↓
confirmar
O que não fazer quando o Pool não paginado está alto
Evite começar por:
desativar serviços aleatoriamente
apagar arquivos .sys
baixar drivers de sites desconhecidos
usar limpadores de RAM
desabilitar pagefile
formatar imediatamente
comprar mais RAM sem investigar
Algumas dessas ações podem mascarar temporariamente o sintoma, e outras podem criar novos problemas.
Comprar mais RAM pode valer a pena?
Sim, quando o computador realmente possui pouca memória para a carga de trabalho.
Mas isso é outro diagnóstico.
Imagine:
8 GB de RAM
Chrome + Teams + Office + máquinas virtuais
Nesse caso, adicionar RAM pode ser uma melhoria legítima.
Agora imagine:
16 GB
↓
driver perde 500 MB por hora
Instalar 32 GB apenas faz o problema demorar mais para aparecer.
Precisamos distinguir falta de capacidade de vazamento.
Como diferenciar falta de RAM de vazamento de driver
Falta de RAM
O consumo geralmente acompanha os programas utilizados.
Exemplo:
abre VM
↓
+6 GB
Fecha:
memória é liberada/reutilizada
Vazamento de Nonpaged Pool
O comportamento pode ser:
atividade
↓
Pool cresce
↓
atividade termina
↓
Pool não retorna
↓
repete
↓
Pool cresce mais
Essa diferença ajuda bastante.
Como diferenciar cache de vazamento
Cache
O Windows utiliza RAM ociosa para melhorar desempenho.
Quando outro programa precisa de memória, o sistema pode reaproveitá-la.
Vazamento
A memória continua presa devido a alocações que não estão sendo liberadas corretamente.
No caso de Nonpaged Pool, essas páginas precisam permanecer residentes enquanto alocadas.
Por isso, observar a categoria correta é fundamental.
Como diferenciar um pico normal de crescimento anormal
Um pico:
500 MB
↓
900 MB
↓
600 MB
pode ser totalmente normal.
Um crescimento:
500 MB
↓
900 MB
↓
1,5 GB
↓
2,5 GB
↓
4 GB
sem estabilização merece investigação.
A palavra-chave é:
tendência.
FAQ — Pool não paginado no Windows 11
O que é Pool não paginado?
É uma área de memória utilizada pelo kernel e por drivers para alocações que precisam permanecer residentes na RAM enquanto estiverem em uso.
Pool não paginado é memória do Windows?
Sim. Ele faz parte da memória utilizada pelo kernel e componentes em modo kernel.
Não representa necessariamente a memória privada de um aplicativo comum.
Pool não paginado alto significa defeito na RAM?
Não.
Um valor alto pode ter várias causas e, quando existe crescimento anormal, drivers ou outros componentes de kernel podem estar envolvidos.
Defeitos físicos de RAM são investigados por outros métodos.
Quanto de Pool não paginado é normal?
Não existe um valor universal válido para todas as máquinas.
O tamanho depende da configuração, drivers, dispositivos, carga e quantidade de memória.
Mais importante do que um número isolado é observar se existe crescimento contínuo e perda progressiva de memória disponível.
1 GB de Pool não paginado é muito?
Depende do computador e da carga.
Um valor estável pode ser legítimo.
Já um valor que cresce continuamente de centenas de MB para vários GB merece investigação.
Reiniciar limpa o Pool não paginado?
O reinício recria o estado do sistema e normalmente reduz drasticamente alocações acumuladas.
Se existe um vazamento, porém, o consumo pode voltar a crescer depois.
O pagefile.sys reduz o Pool não paginado?
Não da mesma maneira que páginas pagináveis.
Nonpaged Pool precisa permanecer residente enquanto suas alocações estiverem ativas.
Aumentar pagefile não corrige um driver com vazamento nessa área.
Desativar o arquivo de paginação melhora?
Não é recomendado usar isso como solução para Pool não paginado alto.
Além de não corrigir a causa, pode prejudicar o gerenciamento de memória e determinados cenários de estabilidade.
RAMMap consegue descobrir qual driver está vazando?
RAMMap é excelente para mostrar como a memória física está sendo utilizada e confirmar categorias de consumo.
Para investigar Pool Tags e possíveis drivers responsáveis, PoolMon costuma ser mais adequado.
O que é PoolMon?
É uma ferramenta de diagnóstico que acompanha alocações de pool do kernel e apresenta informações como Pool Tag, tipo, número de alocações, liberações e quantidade de bytes.
O que significa Diff no PoolMon?
De forma simplificada, representa a diferença entre alocações e liberações.
Um Diff crescente acompanhado de aumento contínuo em Bytes pode ser uma pista de alocações que permanecem ativas.
Isso não representa prova isolada de vazamento.
O que significa Bytes?
Representa a quantidade de memória atualmente associada às alocações daquela entrada/tag.
Essa coluna ajuda a descobrir quais tags estão consumindo mais memória.
Pool Tag é o nome do driver?
Não necessariamente.
A Pool Tag é um identificador de alocações.
É necessário relacioná-la ao driver ou componente correspondente utilizando contexto e outras ferramentas.
Um antivírus pode causar Pool não paginado alto?
Softwares de segurança podem instalar drivers e filtros em modo kernel.
Um bug nesses componentes pode, em determinados casos, contribuir para vazamentos.
Isso não significa que antivírus normalmente causem esse problema nem que a solução seja desativá-los permanentemente.
VPN pode causar o problema?
Clientes VPN podem instalar adaptadores virtuais e filtros de rede.
Se o crescimento ocorre somente quando determinada VPN está ativa, vale investigar o driver e a versão do cliente.
Wi-Fi pode causar Pool alto?
Drivers de adaptadores Wi-Fi trabalham em modo kernel e podem participar de problemas desse tipo.
Teste Wi-Fi e Ethernet separadamente antes de concluir.
USB pode causar vazamento de memória?
Um driver associado a determinado dispositivo USB pode apresentar comportamento incorreto.
O diagnóstico deve comparar o sistema com e sem o dispositivo e, quando possível, testar outra porta, cabo, hub ou unidade equivalente.
Preciso formatar o Windows?
Normalmente não como primeira medida.
É melhor identificar a categoria de memória, Pool Tag e driver suspeito antes.
Uma instalação limpa pode ser utilizada posteriormente como teste controlado quando justificável.
SFC e DISM corrigem Pool não paginado?
SFC e DISM são úteis para problemas de integridade do Windows.
Eles não corrigem automaticamente bugs existentes em drivers de terceiros.
Driver Verifier é seguro?
É uma ferramenta legítima do Windows, mas pode provocar BSOD intencionalmente ao detectar comportamento incorreto de drivers.
Por isso, exige conhecimento técnico e plano de recuperação.
Mais RAM resolve?
Mais RAM pode melhorar um computador que realmente possui pouca capacidade.
Mas se existe um driver com vazamento contínuo, adicionar RAM apenas pode atrasar o momento em que o problema se torna perceptível.
Conclusão
Quando o Windows 11 mostra quase toda a RAM ocupada, mas os programas visíveis no Gerenciador de Tarefas não explicam o consumo, é importante olhar além da guia Processos.
O caminho começa em:
Gerenciador de Tarefas
→
Desempenho
→
Memória
Se o Pool não paginado estiver crescendo continuamente, registre o comportamento ao longo do tempo.
Depois utilize o RAMMap para entender melhor a distribuição da memória física e o PoolMon para localizar quais Pool Tags acompanham o crescimento.
A partir daí, transforme a investigação em uma sequência lógica:
Pool alto
↓
Tag crescendo
↓
driver
↓
dispositivo ou software
↓
teste controlado
↓
correção
↓
novo teste
Não existe vantagem em substituir drivers aleatoriamente, limpar RAM, aumentar o pagefile ou formatar o computador antes de entender a causa.
Quando conseguimos demonstrar que determinada atividade faz uma tag crescer, relacionamos essa tag a um driver e reproduzimos o comportamento várias vezes, deixamos de trabalhar com suposições.
Passamos a trabalhar com evidências.
E esse é justamente o ponto mais importante de qualquer diagnóstico técnico do Windows.
Precisa de ajuda para descobrir por que a memória RAM do Windows está desaparecendo?
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores com Windows, incluindo problemas de consumo excessivo de memória, drivers, lentidão, armazenamento, rede, Wi-Fi, impressoras e outros problemas de desempenho.
O atendimento pode ser realizado por acesso remoto ou presencialmente, conforme o tipo de problema e mediante agendamento.
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Telefone/WhatsApp: (11) 99779-7772
Antes de aumentar a memória RAM, formatar o computador ou trocar componentes, um diagnóstico correto pode mostrar onde o recurso realmente está sendo consumido.
Faça um comentário