Finden von Memory Leaks im Paged oder Nonpaged Pool
// August 17th, 2010 // IT, Tutorials
1 Allgemeine Informationen
1.1 Memory Leak
Speicherleck (englisch memory leak, gelegentlich auch Speicherloch oder kurz memleak) werden Fehler in einem Computerprogramm genannt, die es ermöglichen, dass ein laufender Prozess einen Speicherbereich belegt, diesen jedoch im Zuge der Ausführung weder freigeben noch nutzen kann[1]
Läuft nun z.B. der Nonpaged Pool voll, muss dies das System nicht zwangsläufig mit einem Bluescreen quittieren. Es kann jedoch von keiner anderen Anwendung Nonpaged Pool in Anspruch genommen werden, welches sich in verschiedenen Variationen äußern kann. Wie auf dem Screenshot zu sehen, belegt der Nonpaged Pool 130.956 KB bei einem Limit von 131.072 KB. Ein Versuch Paint zu öffnen resultierte in folgender Fehlermeldung:
1.2 Nonpaged Pool
Der Betriebssystemkernel und Gerätetreiber nutzen den nonpaged pool um Daten zu speichern, auf die auch dann noch zugegriffen kann, wenn das System Pagefaults nicht händeln kann. Wenn letzteres auftritt, ist meist ein fehlerhafter Treiber Schuld, welcher in diesem Zusammenhang auch gleich meist den IRQL_NOT_LESS_OR_EQUAL Bluescreen verursacht.
Der Nonpaged Pool ist daher ständig im physikalischen Speicher hinterlegt und wird im Gegensatz zum Paged Pool nicht ausgelagert.
1.3 Paged Pool
Im Gegensatz zum Nonpaged Pool kann der Paged Pool ausgelagert werden. Daher auch der Name pagefile.sys für die entsprechende Datei. Wenn ein Treiber oder ein Prozess Speicher des Paged Pool referenziert, dieser sich jedoch bereits im ausgelagerten Speicher (pagefile.sys) befindet, spricht man von einem Page Fault (dt. Seitenfehler). Tritt dies auf, wird der ausgelagerte (virtuelle) Speicher wieder in den physikalischen Speicher gelesen.
Treiber verwenden einen 4-byte großen ‚Tag‘, mit welchem sie eindeutig identifiziert werden können. Dieses Tag wird z.B. in Poolmon oder im Leaklogger zur Erkennung eines Memoryleak verursachenden Treibers verwendet.
1.4 Nonpaged Pool Limit
Auf einem 32-bit Windows ist der Systemadressspeicher auf 2GB limitiert. Dies schränkt somit auch das Limit des Nonpaged Pools auf diese Größe ein, wobei noch Speicher für andere Ressourcen wie den Kernel, Gerätetreiber, etc. benötigt werden. Bis Vista bestimmt das System bei jedem Boot, wie groß der Adressbereich für jede Ressource benötigt wird. Das Minimum für das Nonpaged Pool Limit auf einem System mit 512 MB RAM liegt bei 128 MB. Bei einem System mit 1 GB RAM oder mehr liegt das Limit bei 256 MB.
Ab Windows Vista wird die Größe der Adressbereiche dynamisch den Ressourcen zugeteilt. Das Maximum für den Nonpaged Pool ist hier entweder 75% oder 2 GB, je nachdem, was kleiner ist. Bei 64-bit Betriebssystemen (ab Vista) liegt das Limit bei ca. 400 KB pro MB Arbeitsspeicher oder 128 GB, je nachdem, was geringer ist.
1.5 Paged Pool Limit
Der Pagedpool wird für sämtliche Daten des Kernels oder der Gerätetreiber verwendet, welche nicht durch die Bedingungen für den Nonpaged Pool abgedeckt werden.
Auf einem 32-bit Windows XP wird das Limit des Paged Pools durch die Größe der Adressräume anderer Ressourcen bestimmt. Da bei 32-bit Betriebssystemen ab Vista der Kernel Adressraum dynamisch bestimmt wird, liegt das Limit hier bei 2 GB. Bei Windows XP oder Server 2003 auf 64-bit Basis, ist das Limit des Paged Pools vier Mal so groß, wie das Limit des Nonpaged Pools oder 128 GB, je nachdem, was geringer ist. Bei allen 64-bit Betriebssystemen ab Vista liegt das Limit des Paged Pools bei 128 GB.
2 Tools
2.1 Debugging Tools
Um auf die Informationen wie die Limits des Nonpaged und des Paged Pools zuzugreifen, werden die Microsoft Debugging Tools[2] benötigt, um auf die Debugging Symbols bereitzustellen. Diese stehen sowohl für x86[3] und x64[4] Betriebssysteme zur Verfügung.
2.2 Process Explorer
Process Explorer[5] ist ein alternativer Taskmanager welcher die Möglichkeit bietet, tiefergehende Informationen des laufenden Systems anzuzeigen. Hierzu gehören geladene und geöffnete DLLs und Handels, Threads, CPU-Usage, I/O, Nutzung des Arbeitsspeichers (Commit, Physical, Paging, …) und einiges mehr.
Um die für das Auffinden von Memory Leaks wichtigen Informationen anzeigen zu lassen, müssen sowohl der Pfad zu der Dbghelp.dll aus den Debugging Tools als auch zu den Symbols[6] angegeben werden.
In dem Feld für den Pfad zu der dbghelp.dll muss die Datei angegeben werden, welche sich im Installationsverzeichnis der Windows Debugging Tools befindet. Die dbghelp.dll im Systemverzeichnis (C:\Windows\System32) ist hierfür nicht ausreichend.
Im unteren Feld muss der Pfad zu den Symbols angegeben werden. Der Aufbau ist hier gemäß dem Schema „SRV*<lokalerCache>*<Symbolserver>“. Ein Beispiel wäre:
SRV*c:\temp\websymbols*http://msdl.microsoft.com/download/symbols
Bitte beachten Sie, dass eine aktive Internetverbindung für den Download der benötigten Symbols erforderlich ist. Alternativ können auch die Symbolpakete von der Seite http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx heruntergeladen werden.
Wenn die Konfiguration korrekt vorgenommen wurde, werden im Process Explorer unter System Information nun die Limits für den Paged und Nonpaged Pool angezeigt:
Sollte der Wert für den Paged oder Nonpaged Pool sich dem Limit stark annähern, ist dies meist ein eindeutiges Zeichen, dass es sich um ein Memory Leak in einer der laufenden Treiber bzw. Anwendungen handelt.
2.3 Poolmon
Poolmon ist Bestandteil der Support Tools für Windows Server 2003 Service Pack 2. Alternativ kann Poolmon in einem Paket mit allen drei Versionen (i386, AMD64, iA64) unter http://www.feldstudie.net/downloads/?dl_cat=9 heruntergeladen werden.
Bei XP, Server 2003 oder älteren Betriebssystemen kann es erforderlich, das Pooltagging zu aktivieren, damit Poolmon die benötigten Information sammeln und darstellen kann. Dazu kann das Tool Gflags.exe verwendet werden, welches wie Poolmon in den Support Tools zu finden ist oder unter http://www.feldstudie.net/?dl_id=89 heruntergeladen werden kann.
Poolmon zeigt die verwendete Menge des Poolspeichers (sowohl Paged als auch Nonpaged). Die Werte werden zusammen mit dem Pootag angezeigt, welches standardmäßig aus einem vierstelligen Zeichencode besteht. Dieses wird dazu benötigt, über die Kernel API Poolspeicher zu allokieren.
Nach dem Start von Poolmon kann mittels ‚p‘ nach Paged oder Nonpaged Pool sortiert werden. Mittels ‚b‘ wird nach den verwendeten Bytes auf- oder absteigend sortiert. Mit ‚d‘ kann nach der Differenz zwischen Pool Allocations und Pool Frees sortiert werden.
2.4 Strings
Mit dem Sysinternals Tool „Strings“[7] kann in ausführbaren und Objektdateien nach Unicode- oder ASCII-Strings mit einer minimalen Länge von drei Zeichen gesucht werden. Die Syntax lautet:
strings.exe [-a] [-b bytes] [-n length] [-o] [-q] [-s] [-u] <file or directory>
Strings takes wild-card expressions for file names, and additional command line parameters are defined as follows:
-s Recurse subdirectories.
-o Print offset in file string is located.
-a Scan for ASCII only.
-u Scan for UNICODE only.
-b bytes Bytes of file to scan.
-n X Strings must be a minimum of X characters in length.
To search one or more files for the presence of a particular string using strings use a command like this:
strings * | findstr /i TextToSearchFor
3 Vorgehensweise
Zu Beginn sollte über des System Information Fensters des Process Explorer überprüft werden, ob der Paged oder Nonpaged Pool vollgelaufen ist. Sehen die Werte wie folgt aus, scheint ein Leak im Nonpaged Pool aufgetreten zu sein:
Im nächsten Schritt muss nun mit Poolmon überprüft werden, welches Tag für die Speicherallokierung zuständig ist. Da es sich hier um den Nonpaged Pool handelt, sollte Poolmon mit ‚p‘ nach dem Pool sortiert werden. Anschließend sortiert man mit ‚b‘ nach Bytes absteigend.
Hier sieht man nun, dass der Treiber mit dem Tag „Leak“, mit knapp 84% Belegeung des gesamten Nonpaged Pools, für das Problem verantwortlich ist. Nun muss nur noch mit Strings der Treiber gefunden werden.
Da die meisten Treiber in C:\Windows\System32\drivers liegen, sollte die Suche hier begonnen werden:
Wie auf dem Screenshot zu sehen ist, wurde das Tag in der Datei myfault.sys gefunden.
Über die Dateieigenschaften (Version > Info > Beschreibung / Copyright), Google oder ggf. den Process Explorer (sofern der Treiber geladen ist), kann nun das Programm identifiziert werden, welches den Leak verursacht.
4 Weitere Informationen
- Troubleshooting Nonpaged and Paged Pool Errors in Windows auf Simple Talk
- Leaklogger – Halbautomatische Analyse von Memory Leaks inkl. grafischer Ausgabe
- Pushing the Limits of Windows: Paged and Nonpaged Pool – Mark Russinovich
- Pushing the Limits of Windows: Virtual Memory – Mark Russinovich
- Pushing the Limits of Windows: Physical Memory – Mark Russinovich
[1] Wikipedia – Speicherleck - http://de.wikipedia.org/wiki/Speicherleck
[2] Website: http://www.microsoft.com/whdc/devtools/debugging/default.mspx
[3] Download x86: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#b
[4] Download x64: http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx
[5] Informationen und Download: http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx
[6] Link: Beziehen von Debugsymboldateien über den Microsoft-Symbolserver
[7] Download: http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx
Ähnliche Beiträge:
- Bluescreen von NETw5s64.sys auf HP EliteBook 8540w mit Intel Centrino Ultimate-N 6300 AGN WLan Adapter
- Ausgeblendete Geräte im Windows Gerätemanager anzeigen
- Neue Version des NDIS Treibers für Kaspersky Anti-Virus für Windows Workstation MP4 – Teil 2
- Hacking MSI-Packages oder wie entferne ich einen OS Check
- Neue Version des NDIS-Filters für Kaspersky Anti-Virus für Windows Workstation MP4 unter Windows XP (6.5.0.7)




Sehr netter Artikel, danke für die Info. Werd es mal abarbeiten.