Identificando causa de evento 2020 e 2019

Por: Marcelo Fontes

1. Introdução

É bastante comum estarmos diante da situação em que o servidor congela e eventos precedentes ao tal congelamento são os eventos do System: 2020 ou 2019. Veja o que é necessário para que se possa indicar a real causa de um destes eventos e posterior travamento do servidor.

2. Cenário

Servidor deixa de responder. Não responde nem a ping, não conseguimos logar na console. Depois de reiniciar o servidor no botão, abrimos o event viewer e deparamos com este evento:

Descrição do Evento:

Identificação do evento 2019

Tipo: Erro

Fonte: Srv

Categoria: Nenhuma

Identificação do evento: 2019

Data: Data

Hora: Hora

Usuário: N/A

Computador: Computador

Descrição:

O servidor não pôde alocar a memória não paginável do sistema porque estava vazia.

No caso para evento 2020 basicamente temos o mesmo cenário porém para a memória “paginável”. Usaremos como ilustração área de memória “não paginável” para este artigo ou chamada em inglês de “nonpaged pool”

3. Conceito referente à área de “memória não paginável”

Esta área de memória do kernel é onde É Carregado código vital para o funcionamento do sistema operacional. Ela é tão vital que deve sempre estar residente em memória física, portanto nunca será paginada. Drivers tanto do sistema operacional, de hardware, assim como de softwares se utilizam destes recursos, e é aí que mora o perigo. O eventual mau funcionamento de algum driver poderá alocar memória e não liberar a mesma após código executado, de forma que a “área de memória não paginável” disponível chega a próximo de zero causando o travamento do servidor.

4. Troubleshooting

1- Confirmar se existe um vazamento de memória: Um log de performance monitor com o objeto Memória é o suficiente para identificar se existe vazamento ou não. Este log deve ser iniciado ao reiniciar o servidor até o momento em que o problema ocorreu.

2- Confirmar qual a origem do vazamento. A única forma de se identificar qual o driver que vaza memória é através de duas formas. Log gerado pela ferramenta poolmon, e ou análise de um dump de memória. Nenhuma das duas garante que se possa identificar o causador do problema, pois tudo que conseguimos monitorar é o consumo de “nonpaged pool” alocado pela Tag (marca de pool) que é definido no momento da compilação do driver. Exemplo:

Pool Non-Paged

Tag Type Allocs Frees Diff Bytes

         

TdLL Nonp 225939 153572 72367 41681600

575

tdLL Nonp 198823 134902 63921 36816704

575

tdLL Nonp 108768 74148 34620 19938880

 575

File Nonp 12415424 12384203 31221 5023328

160

Ntfr Nonp 63868 5327 58541 3747616

A coluna Tag mostra a Tag que é definida pelo driver. Exemplo TdLL é identificada como sendo do redirecionador da Symantec. O valor em bytes é o quanto que esta Tag possue alocado no momento.

Para maior aprofundamento da análise necessitamos do dump de memória gerado via teclado, conforme documento abaixo:

244139 Windows feature lets you generate a memory dump file by using the keyboard

https://support.microsoft.com/default.aspx?scid=kb;EN-US;244139

A necessidade do dump se dá devido ao fato de muitas vezes, apesar de haver o vazamento causado por certa tag, como por exemplo NtFC que é gerada por NTFS.sys do windows, existe um causador indireto que faz com que NTFS aloque indefinidamente o montante de memória, como exemplo um “filter driver” que atua nos meandros entre NTFS e o disco.

Uma consideração deve ser feita, caso o sistema operacional seja anterior ao Windows Server 2003, nestes sistemas operacionais para que haja dados no log do poolmon, é necessário habilitar-se o pooltag. Veja documento abaixo:

177415 How to Use Memory Pool Monitor (Poolmon.exe) to Troubleshoot Kernel Mode Memory Leaks

https://support.microsoft.com/default.aspx?scid=kb;EN-US;177415

5. Conclusão

Novamente estamos recomendando o preparo do servidor para geração de um dump de memória para caso de troubleshooting de travamento de servidores, neste artigo introduzimos a ferramenta poolmon.exe como importante recurso para auxilio de problemas de esgotamento de recursos de kernel, paged pool e nonpaged pool.