Fuga de memória no Paged Pool do Windows Server 2019 pode derrubar VMs e hosts inteiros. Este guia prático reúne sintomas, diagnóstico com WPR/WPA, RAMMap e PoolMon, correção via updates (incluindo o CU de jan/2025), mitigação provisória e monitorização para impedir novas quedas.
Visão geral do problema
Em ambientes com Windows Server 2019 (versão 1809, build 17763), administradores observaram crescimento contínuo do Paged Pool até consumir toda a RAM. O servidor passa a trocar intensamente para disco, responde de forma errática a RDP/SMB/WinRM, torna-se inacessível e, por fim, pode bugcheckar (falha de sistema). Em casos reportados, a tag “SM00” — associada ao stack de virtualização/armazenamento (Hyper‑V/StorVSP) — aparece no topo da lista do PoolMon.
Como o leak se manifesta
- Memória: contadores de desempenho mostram Pool Paged Bytes e Pool Paged Resident Bytes subindo continuamente, sem liberação.
- Serviços afetados: quedas de SMB, falhas em VMs Hyper‑V, latências elevadas em aplicativos e timeouts em IIS/SQL.
- Eventos: logs de Kernel‑Memory e Warning/Errors genéricos por falta de recursos; por vezes, dumps incompletos devido à baixa memória.
- Após reinício: o problema reaparece em horas ou dias, sugerindo fuga de alocações e não simples pressão de carga.
Entendendo o Paged Pool no Windows
O Paged Pool é uma região de memória do kernel que pode ser paginada para disco. Drivers e componentes do sistema alocam blocos ali para metadados, buffers e estruturas internas. Fugas (leaks) surgem quando um componente aloca repetidamente sem liberar, fazendo o total crescer de forma monotônica.
Em x64 modernos, o limite do Paged Pool é elástico. Por isso, “tapar o sol com a peneira” (limitando artificialmente o pool) é prática desaconselhada: mascara o bug e cria instabilidade. O caminho correto é identificar a tag que vaza, mapear o driver e corrigir via atualização do sistema/driver.
Fluxo de resolução recomendado
| Fase | Ações recomendadas | Finalidade |
|---|---|---|
| Diagnóstico | Usar Windows Performance Recorder/Analyzer (WPR/WPA), RAMMap e PoolMon para descobrir qual processo/driver ou pool tag causa o vazamento. | Identificar a origem |
| Atualizações | Manter o sistema com Cumulative Updates e Servicing Stack Updates mais recentes. O CU de janeiro/2025 corrige o leak associado à tag SM00. Após o patch, o Paged Pool tipicamente estabiliza em ~18% da RAM. | Corrigir o bug |
| Mitigação temporária | Ajustar com parcimônia o valor SystemPtesLimit no Registro para conter crescimento anômalo de pools específicos. Uso estritamente provisório. | Ganhar tempo até o patch |
| Workaround para bugs conhecidos | Quando o vazamento provém de atualização problemática (ex.: LSASS em 2024), aplicar Known Issue Rollback (KIR) até a correção final. | Evitar reinicializações |
| Monitorização | Criar contadores de desempenho para Paged e Non‑Paged Pool, com alertas ao atingir limiares críticos. | Detecção precoce |
O que os administradores observaram na prática
- Dez/2024: início do leak em múltiplos ambientes mesmo “em dia” com patches.
- Jan/2025: a tag SM00 (stack Hyper‑V/StorVSP) identificada como principal causadora em muitas VMs.
- Pós‑CU jan/2025: consumo estabilizado por vários dias e fim de reinícios frequentes.
Diagnóstico, do zero ao driver culpado
Passo a passo com PoolMon
- Instale/abra o PoolMon com privilégios de administrador.
- Pressione P até filtrar para Paged; depois B para ordenar por Bytes.
- Anote as tags no topo (ex.: SM00, NDU!, Srv2, etc.).
- Se necessário, use
poolmon -i <TAG>para focar em uma única tag e observar sua evolução em tempo real.
Mapeando a tag ao driver
cd %SystemRoot%\System32\drivers
strings.exe -n 8 *.sys | findstr /i SM00
O nome do arquivo de driver (por exemplo, um componente de virtualização/armazenamento) surgirá próximo da tag. Alternativas:
findstr /m /s /i SM00 *.syspara localizar arquivos que contenham a cadeia.- Em RAMMap, guias Drivers e File Summary ajudam a cruzar uso de memória por driver/arquivo.
Captura com WPR/WPA
- Inicie uma sessão com o cenário Memory no WPR (interface gráfica) ou:
wpr -start Memory -filemode REM Reproduza o padrão de uso por alguns minutos wpr -stop C:\Temp\Leak.etl - Abra o WPA e inspecione os gráficos de Pool Allocations por tag, stack e módulo.
- Correlacione a evolução da tag com eventos de driver/serviço para fechar o laudo.
Corrigindo de forma definitiva
Depois de identificar a origem (por exemplo, a tag SM00 do subsistema de virtualização/armazenamento), aplique as seguintes ações:
- Atualizações do Windows: instale o Cumulative Update mais recente (mínimo: janeiro/2025) e o Servicing Stack Update correspondente.
- Drivers de Integração: em VMs Hyper‑V ou Azure, atualize as Integration Components (ICs). Versões antigas podem conter o bug relacionado à tag SM00.
- Drivers de Terceiros: se o mapeamento da tag indicar um miniport/NDIS/storage de fornecedor, reinstale/atualize o pacote e notifique o fabricante com evidências (capturas do PoolMon/WPA).
Como validar o sucesso do patch
- Reinicie o servidor após aplicar os updates.
- Monitore por horas/dias: o Paged Pool deve estabilizar abaixo de ~25% da RAM (média real relatada ~18%).
- No PoolMon, a tag problemática não deve mais crescer monotonicamente.
Mitigação temporária (use somente quando não há patch imediato)
Se o negócio não permite aguardar a correção e o leak é severo, admite‑se uma mitigação de curto prazo:
- SystemPtesLimit (Registro:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management): ajuste cuidadoso pode conter padrões de alocação que estouram o espaço de PTEs e pressionam pools. Não é solução definitiva e pode introduzir efeitos colaterais. - Evite definir manualmente
PagedPoolSize/PoolUsageMaximumem sistemas x64 — são abordagens legadas e arriscadas. - Planeje reinícios controlados fora de horário de pico para “resetar” o estado até a correção ser aplicada.
Workaround com Known Issue Rollback (KIR)
Quando uma atualização específica introduz instabilidade (ex.: vazamentos em LSASS observados em 2024), use o KIR para reverter de forma seletiva a parte problemática do update, sem desinstalá‑lo por completo.
- Verifique se a Microsoft publicou um KIR para o problema.
- Em domínios, importe o template de Diretiva de Grupo (GPO) do KIR e vincule à OU adequada.
- Confirme a aplicação em clientes/servidores e monitore a estabilização da memória.
O KIR é uma ponte até o próximo CU com a correção definitiva.
Monitorização pró‑ativa
Contadores essenciais e limiares práticos
| Objeto/Contador | Descrição | Limiar sugerido | Ação |
|---|---|---|---|
| Memory\Pool Paged Bytes | Total de bytes no Paged Pool | > 25% da RAM por > 30 min | Investigar tags com PoolMon |
| Memory\Pool Paged Resident Bytes | Parte residente do Paged Pool | Subida monotônica | Confirmar fuga persistente |
| Memory\Pool Nonpaged Bytes | Total no Non‑Paged Pool | > 20% da RAM | Checar drivers NDIS/Storage |
| Processo\Private Bytes (por processo) | Memória privada de processos suspeitos (ex.: vmms, vmmem, lsass) | Crescimento linear | Correlacionar com WPA |
| LogicalDisk\Avg. Disk sec/Read/Write | Pressão por paginação | > 20 ms sustentado | Impacto em I/O por thrashing |
Criação rápida de alertas
Você pode automatizar alertas com Data Collector Sets ou logman:
REM Cria um conjunto que coleta contadores a cada 15s
logman create counter LeakWatch -f csv -o C:\PerfLogs\Leak\leak.csv -si 00:00:15 ^
-c "\Memory\Pool Paged Bytes" "\Memory\Pool Paged Resident Bytes" "\Memory\Pool Nonpaged Bytes"
REM Inicia na inicialização
logman update LeakWatch -rf 7 -v mmddhhmm -cnf 01:00:00
schtasks /Create /SC ONSTART /TN LeakWatchStart /TR "logman start LeakWatch" /RU SYSTEM Para alertas, crie um Task Scheduler que lê o CSV periodicamente e dispara evento/email quando o valor exceder o limiar. Em ambientes com SIEM, envie os contadores via agente.
Recomendações complementares
- Atualize ICs de VMs Hyper‑V/Azure: versões antigas foram associadas ao leak da tag SM00.
- Rede/NDU: em suspeita de drivers de rede, isole usando PoolMon e desative o serviço NDU apenas para testes; preferir a atualização/correção do driver.
- Evite limitar o Paged Pool permanentemente em x64. Corrija o driver ou aplique o patch oficial.
- Documente o caso: registre a tag, versão do driver, versão do SO e linha do tempo; isso agiliza atendimento de fornecedores.
Dicas específicas por papel do servidor
| Papel | Tags/Áreas comuns | Ações sugeridas |
|---|---|---|
| Hyper‑V Host/VM | SM00, VMBus, StorVSP | Atualizar CU/SSU, ICs; revisar caminhos de storage e offloads |
| File Server | SRV2/SRVNET | Aplicar CU; validar drivers de HBA/NIC; ajustar SMB Direct se aplicável |
| Controlador de Domínio | LSASS | KIR quando disponível; aplicar hotfix/cu de correção; avaliar patches de segurança recentes |
| Servidor de Impressão | Spooler/splwow64 | Isolar drivers herdados; padronizar pacotes tipo 4; revisar assinaturas |
Playbook de triagem
- Aplicar o CU mais recente (mínimo: janeiro/2025) e o SSU correspondente; reiniciar.
- Observar no PerfMon se o Paged Pool permanece abaixo de 25% da RAM durante a carga típica.
- Persistindo o problema:
- Executar PoolMon → ordenar por Bytes → anotar a tag de topo.
- Mapear a tag para o driver com
findstr/strings.exe. - Atualizar, reinstalar ou desabilitar o driver identificado; se for de terceiro, abrir chamado anexando evidências.
- Automatizar a monitorização com Data Collector Sets e alertas para agir antes do esgotamento.
Checklist de pós‑correção
- Paged Pool estabilizado (< 25% da RAM; alvo típico ~18%).
- Nenhuma tag apresentando crescimento linear por horas.
- Sem quedas/bugchecks nos últimos ciclos de pico.
- Drivers e ICs no nível recomendado pelo fabricante/Windows Update.
- Alertas configurados e testados.
FAQ rápido
Qual a diferença entre Paged e Non‑Paged Pool?
O Paged pode ser paginado para disco; o Non‑Paged deve permanecer sempre na RAM. Ambos são críticos: vazamentos em qualquer um esgotam a memória do kernel.
O Hyper‑V “causa” o leak?
Não por si só. Em 2024/2025, casos apontaram a tag SM00 (stack de virtualização/armazenamento) como origem. A correção veio em CUs subsequentes e na atualização de ICs/drivers.
Devo alterar o tamanho do Paged Pool?
Não é recomendado em x64. Prefira corrigir o driver/patch e usar mitigação apenas como último recurso e por curto período.
Posso desativar o NDU para “resolver”?
Só para fins de teste/diagnóstico quando a tag indicar drivers de rede. A resolução definitiva é corrigir/atualizar o driver implicado.
Resumo final
Fugas no Paged Pool do Windows Server 2019 são resolvíveis com método: identificar a tag (PoolMon/WPA), aplicar o CU/SSU adequado — com destaque para o CU de janeiro/2025 no caso da SM00 —, atualizar ICs e drivers e operar com monitorização contínua. Assim, você elimina reinicializações frequentes e devolve estabilidade às cargas de produção.