윈도우즈에서 넌페이지드풀과 페이지드 풀 에러 트러블슈팅

Troubleshooting Nonpaged and Paged Pool Errors in Windows

윈도우즈에서 넌페이지드풀과 페이지드 풀 에러 트러블슈팅

12 March 2010

by Ben Lye

Ben Lye uncovered a memory leak in the nonpaged pool which was crashing his servers with disquieting regularity. Luckily it was relatively easy to troubleshoot, and he's sharing the tools and techniques he used to get his servers back on track in double-quick time.

Ben Lye가 정기적으로 서버를 죽이는 넌페이지드 풀의 메모리릭을 찾아냈다. 다행히 트러블슈팅은 비교적 어렵지 않았다. Ben Lye가 문제를 해결할 수 있었던 툴과 방법을 공유하고자 한다.

I recently had an issue where, after a software change on our servers, we started to notice that some systems had become unstable and were regularly crashing.  The crashes sometimes resulted in a blue-screen, but other times resulted in a machine which responded to ping, but little else, and had a completely unresponsive console.  The only course of action was to power-cycle the crashed server; clearly, not a good thing to do when we’re dealing with production servers.

최근에 문제가 하나 있었다. 서버에서 소프트웨어 상 변경이 있었고, 몇몇 시스템이 불안정해져서 주기적으로 죽어버렸다. 크래시는 가끔은 블루스크린을 냈고, 또 가끔은 핑은 되지만 다른 것은 거의 아무것도 못하고 콘솔도 완전히 얼어버리는 현상도 나타냈다. 유일한 방법은 크래시난 서버의 파워를 다시 키는 방법이었으나. 이것은 분명 현업에서 사용하는 서버를 다루는 좋은 방법은 아니다.

Upon investigation, we found that immediately before the crash the servers would log event 2019 in the System log – “The server was unable to allocate from the system nonpaged pool because the pool was empty”.

문제를 조사하면서, 크래시 직전에 시스템 이벤트 로그에 2019 이벤트 로그가 남은 것을 발견했다. - “The server was unable to allocate from the system nonpaged pool because the pool was empty” (풀이 고갈되어 시스템 넌페이지드 풀을 할당할 수 없다)

Figure 1 - Event 2019

Thankfully, the error message in the event log gave us a clear indication as to why the systems were in trouble, and allowed us to troubleshoot and diagnose the problem.

고맙게도, 이벤트 로그의 에러 메시지는 시스템이 어떤 문제에 빠졌는지 확실히 알려줬고, 우리는 문제를 진단할 수 있었다.

About nonpaged pool

넌페이지드 풀에 대하여

The nonpaged pool is memory which always resides in physical memory – it is never paged out.  It is used by the kernel and also by device drivers installed on a system to store data which might be accessed in situations when page faults are not allowed.  The amount of memory allocated to the nonpaged pool varies, and is determined as a function of operating system, processor architecture, and physical memory size. For example, 32-bit operating systems, with their smaller address spaces, have lower limits:

넌페이지드 풀은 언제나 물리적 메모리 상에 위치하는 메모리다. 즉 페이지 아웃 되지 않는다. 넌페이지드 풀은 커널이나 시스템에 설치된 디바이스 드라이버가 페이지 폴트가 허용되지 않는 상황에서도 접근할 수 있는 용도로 사용된다. 넌페이지드 풀에 할당된 메모리 크기는 운영체제의 기능, 프로세서 아키텍쳐, 물리 메모리 사이즈에 따라 결정된다. 예를 들어, 32비트 운영체제는 비교적 작은 주소공간 때문에 낮은 한계값을 갖는다.

32-bit Windows Server 2003 with 2GB or more of RAM will have a nonpaged pool limit of 256MB

32-bit Windows Server 2008 will have a nonpaged pool limit of either 2GB or slightly more than 75% of physical memory, whichever is smaller

64-bit operating systems, which have a much larger address space, have higher limits:

32비트 윈도우 서버 2003에 2GB이상의 램이 있으면 넌페이지드 풀 한계값은 256MB다.

32비트 윈도우 서버 2008은 2GB와 물리메모리의 75% 중 작은 값을 한계치를 갖는다.

64비트 운영체제는 더 큰 한계값을 갖는다.

64-bit Windows Server 2003 will have a nonpaged pool of either 128GB or 40% of physical memory, whichever is smaller

64-bit Windows Server 2008 (or 2008 R2) will have a nonpaged pool limit of either 128GB or slightly more than 75% of physical memory, whichever is smaller

...

Pool size data is from Mark Russinovich and David Solomon’s book “Windows Internals, 5th Edition”, and Mark Russinovich’s blog posting “Push the Limit’s of Windows: Paged and Nonpaged Pool”.

...

One way to see the nonpaged pool limit on a specific system is to install the Debugging Tools for Windows, and then use Sysinternals’ Process Explorer to display the pool size.  (The debugging tools are required to provide access to debugging symbols.)

특정 시스템의 넌페이지드 풀 최대값을 보는 방법은 Debugging Tools for Windows를 설치하고, 시스인터널즈의 프로세스 익스플로러로 풀 사이즈를 보는 것이다.

Once the tools are downloaded and installed, launch Process Explorer and click Options -> Symbol Configuration, point it to the dbghelp.dll file installed with the Debugging Tools, and configure Microsoft’s symbol server as the symbol file path.

Figure 2 - Process Explorer Symbol Configuration

The nonpaged pool size can then be found on the System Information dialog (click View -> System Information or press Ctrl+I):

Figure 3 - Nonpaged pool allocation and limit on 32-bit Windows Server 2003 with 1GB RAM

Back to the problem

문제로 돌아가서

We were monitoring memory usage on one of the constantly crashing systems, including the performance counter for nonpaged pool allocation - Memory\Pool nonpaged bytes.  The orange line in Figure 4 is nonpaged pool usage, and the plot shows usage growing steadily over time, and then reducing sharply whenever the system is rebooted.

계속 죽어나가는 한 시스템의 메모리 사용량을 모니터링했다. 성능모니터의 넌페이지드 풀 할당 카운터 - Memory\Pool nonpaged bytes. 그림 4의 오렌지색 라인이 넌페이지드 풀 사용량이고, 그래프를 보면 시간에 따라 사용량이 점진적으로 증가하고, 시스템이 재부팅될 때마다 급격히 떨어지는 것을 알 수 있다.

Figure 4 - Memory use over time

We quickly realised that what we were seeing was most likely a memory leak in a driver or kernel component.  Armed with this knowledge and data, the next step was clearly to find out exactly which driver or component is consuming the pool. 

우리는 바로 드라이버나 커널 컴포넌트의 메모리 누수 가능성이 가장 높다는 걸 알아차렸다. 이러한 지식과 데이터를 가지고, 다음 단계는 정확히 어떤 드라이버 또는 컴포넌트가 풀을 잡아먹는지를 알아내는 것이었다.

The tool for this job is the Memory Pool Monitor, poolmon.exe, which is included in the Windows Support Tools on the Windows Server 2003 CD, or alternatively can be downloaded from the Microsoft Download Centre as part of the Windows Server 2003 Support Tools package.  Poolmon displays the amount of pool storage (both paged and nonpaged) in use, all of which is categorized by a pool tag, which is usually a four-character string used when calling the kernel APIs for allocating pool storage.

이 일을 위한 툴은 Windows Server 2003 CD의 Windows Support Tools 에 있는 메모리 풀 모니터, poolmon.exe 다. 풀모니터는 풀 사용량을 보여주고, 사용량은 보통 4자리 영문 스트링인 풀 태그에 따라 나눠져 보여진다. 풀 태그는 풀 저장소를 할당할 때 커널 API를 호출하면서 사용하는 값이다.

After launching poolmon, press the ‘p’ key to filter for paged or nonpaged pool, the ‘b’ key to sort the output by bytes, or the ‘d’ key to sort by the difference between pool allocations and pool frees. With the output set to nonpaged and sorted by bytes, the display could look similar to this:

풀 모니터를 시작하고, p 키를 눌러 페이지드, 넌페이지드 풀을 필터링할 수 있고, b 키를 눌러 출력을 바이트 순으로 정렬할 수 있고, d 키를 눌러 풀 할당과 풀 해제의 차이 순서로 정렬할 수 있다. 출력이 넌페이지드이고 할당 바이트 순으로 정렬되면 결과는 다음과 비슷할 것이다.

Figure 5 - Poolmon.exe

The top line of the output is showing that the tag “SbAp” has made 2,187,628 allocations of 56 bytes and no frees, resulting in 122,507,168 bytes of nonpaged pool use – by far the biggest consumer on the system, and responsible for over 60% of the pool use.  This looks like the likely cause of the memory leak.

출력의 첫번째 줄은 "SbAp"라는 태그가 56바이트를 2,187,658번 할당하여 122,507,168 바이트의 넌페이지드 풀을 사용하고 있다는 걸 나타낸다. 풀 사용량의 60%에 달하는 단연 1등의 사용량이다. 이것이 메모리 누스의 원인일 것 같다.

Now that we know the tag we’re looking for, we need to find out which device driver is using it, and there are a couple of ways to do this.  If the tag is used by a kernel component or driver, and the Debugging Tools for Windows are installed, then the tag will be listed in the triage\pooltag.txt file located in the debugging tools folder. If the tag isn’t listed in pooltag.txt, then we need to find it using the Sysinternals’ Strings utility, strings.exe, to hunt it down.  Since the tag is stored inside the driver file, and most driver files are in %SystemRoot%\System32\drivers, we can easily use strings.exe to quickly search all the files for the tag. So, the search for the “SbAp” tag returned one driver file: klif.sys.

이제 우리가 찾던 태그를 찾았으니까, 어떤 디바이스 드라이버가 이것을 사용하는지 찾아야 한다. 이걸 하는 방법은 몇가지가 있다. 태그가 커널 컴포넌트나 드라이버에 의해 사용되고, Debugging Tools for Windows 가 설치되어 있다면, 태그는 디버깅 툴즈 폴더 밑 triage\pooltag.txt 에 리스트되어 있을 것이다. 태그가 pooltag.txt 에 없다면, 시스인터널즈 strings 도구, strings.exe 로 범인을 색출해야 한다. 태그는 드라이버 파일에 들어 있고, 대부분의 드라이버 파일은 %SystemRoot%\System32\drivers 에 있으므로, strings.exe 로 그 아래 모든 파일에 태그가 있는지 검색할 수 있다. 그래서, "SbAp" 태그를 찾아보면 드라이버 파일은 klif.sys 였다.

Figure 6 – Using strings.exe to find the driver

Once we had identified the device driver, we could identify the manufacturer and get help from their technical support department.  Thankfully, In this case we were able to contact the software vendor and get the problem solved very quickly, preventing any further crashes and loss of productivity.

디바이스 드라이버를 찾아냈으므로, 제조사를 알아내서 제조사에게 기술 지원을 받으면 된다. 고맙게도, 우린 소프트웨어 벤더와 접촉해서 문제를 빨리 해결할 수 있었다.

It’s worth bearing in mind that the same technique can also be used to troubleshoot paged pool problems as well, which will present as event ID 2020, with the text “The server was unable to allocate from the system paged pool because the pool was empty”. The only difference is to use poolmon to display the paged pool instead of nonpaged pool.

똑같은 방법으로 페이지드 풀 문제도 해결할 수 있다. 유일한 차이점은 풀 모니터를 사용할 때 넌페이지드 풀이 아닌 페이지드 풀을 표시하게 하는 것이다.

The basic process in both cases is:

이 두가지 경우에서 동일한 기본 트러블슈팅 절차는 다음과 같다.

• Use the event log message to find out if you’re facing a paged or nonpaged pool problem
• 이벤트 로그 메시지를 확인하여 페이지드 풀 또는 넌페이지드 풀 문제에 맞딱뜨렸는지 알아낸다.
• Use poolmon.exe to find the offending tag
• poolmon.exe 로 문제가 되는 태그를 찾아낸다.
• Use pooltag.txt or strings.exe to identify the component or driver
• pooltag.txt 또는 strings.exe 로 컨포넌트 또는 드라이버를 알아낸다.
• Enlist the vendor to fix the memory leak
• 벤더에게 메모리 릭에 대해 알려준다.

Whether you have a paged or nonpaged pool problem, once you have the right tools and know what to look for, these problems are really not especially difficult to troubleshoot.

페이지드 또는 넌페이지드 풀 문제에 맞딱뜨렸을 때, 툴만 제대로 알고, 무엇을 찾아야 할지만 알고 있다면, 이 문제는 특별히 해결하기 어려운 문제가 아니다.