Supporto Tecnico Enterprise : NT Kernel Architecture

Memoria Paged e NonPaged Pool – Come risolvere un memory leak

itentblg — Mon, 18 May 2009 02:00:00 GMT

In questo post vedremo come risolvere un leak di memoria e identificare il driver responsabile.
Vi consiglio di leggere il post Memoria Paged e NonPaged Pool – Come identificare un memory leak per verificare che effettivamente siamo in presenza di un leak di memoria.

Utilizzare il PoolMon

L’allocazione di una quantità di byte in una delle memorie Pool utilizza un sistema di tagging. Un TAG è un identificativo di quattro byte associato ad ogni porzione di memoria Pool allocata.

Il TAG viene specificato da un driver, durante l’allocazione della memoria, attraverso la routine ExAllocatePoolWithTag. I seguenti tre parametri, devono essere specificati durante la chiamata a questa routine:

PoolType: Il tipo di memoria Pool da allocare (Paged o NonPaged)
NumberofBytes: Il numero di byte da allocare con la richiesta
TAG: il Pool TAG, rappresentato attraverso quattro caratteri ASCII

L’obiettivo dei Pool TAG è quello di fornire un meccanismo, che attraverso degli identificatore potenzialmente univoci, consenta di stabilire quali driver stanno allocando la memoria. Inoltre, durante la fase di sviluppo di un driver, i TAG sono utili per poter differenziare le diverse tipologie di allocazione, rendendo più selettiva un’eventuale investigazione attraverso il tool Driver Verifier.

Identificare il TAG e byte allocati

Per poter verificare quanti byte sono allocati da un determinato TAG occorrerà utilizzare il tool poolmon.exe, che è possibile recuperare dalla cartella \Support\Tools del CD d’installazione del Sistema Operativo.

Questo tool consente di ottenere un report di tutti i TAG della Paged e Non Paged Pool con i relativi byte allocati.
In Windows Server 2003 il Pool tagging è già abilitato, mentre in Windows Server 2000 e Windows XP è necessario abilitarlo attraverso il tool Gflags.exe presente sempre nella cartella \Support\Tools del supporto di installazione, o modificando le opportune chiavi di registro.

Per maggiori informazioni sull'utilizzo di questo tool potete consultare l’articolo How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks

La seguente immagine illustra un esempio di output relativo al poolmon:

FIG 1 - Output del tool Poolmon.exe

I campi fondamentali per la nostra analisi sono evidenziati in rosso:

Tag: Rappresenta il TAG che identifica l'allocazione.
Type: Specifica se la memoria è stata allocata in Paged (Paged) o Nonpaged (Nonp) pool.
Bytes: Quantità di memoria allocata, in bytes, per il corrispondente TAG

Possiamo, dunque, utilizzare i seguenti passi per raccogliere l'output del poolmon in una finestra temporale di nostro interesse:

Copiare il file "PoolMon.exe" in "C:\PoolMon", inserendo nella stessa cartella il tool sleep.exe
Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostare il prompt in C:\PoolMon
Per avere una lettura dei dati ogni 15 minuti (per 2 giorni circa), digitare il seguente comando:
for /l %i in (1,1,200) do ( poolmon -n log-%i.txt && sleep 900000 )
Nella cartella "C:\PoolMon" verranno creati i vari file di log.

Il tool sleep.exe utilizzato è fornito in allegato al presente post.

Determinare la frequenza di campionamento

Sleep.exe richiede un parametro che indica il periodo d'attesa in millisecondi tra due esecuzioni del ciclo for.
Nell’esempio di script riportato sopra, abbiamo il parametro 900’000 che è ottenuto moltiplicando: 15 minuti * 60 secondi * 1000 millisecondi per ottenere una pausa tra una lettura e l’altra di 15 minuti.

Considerando i 200 cicli impostati ogni 15 minuti, abbiamo un campionamento di circa 2 giorni calcolato da: 15 minuti/campione * 200 campioni = 3000 minuti totali / 60 = 50 ore totali / 24 = 2,08 giorni.

Possiamo modificare il numero di cicli e la frequenza di campionamento in base alla rapidità del leak che abbiamo identificato.

Al termine del periodo di monitoring, avremo dunque 200 file di testo, che iniziano con log1.txt fino a log200.txt nel nostro esempio.

Copiando questi dati in un foglio Excel ed ordinandoli in base al tipo (Nonp o Paged) e in ordine decrescente rispetto ai byte allocati, saremo in grado di determinare la variazione di allocazione dei TAG in funzione del tempo, identificando quali, in particolare, stanno occupando di più.

FIG 2 - Schermata di Excel per l'ordinamento dei TAG.

Analizzare i log

Avremo risultati di questo tipo:

NonPaged Pool

NonPaged - Log 1	NonPaged - Log 10	NonPaged - Log 20

Paged Pool

Paged - Log 1	Paged - Log 10	Paged - Log 20

Come possiamo notare è evidente un notevole incremento del TAG Pipo per la Nonpaged pool.
Analizzando anche i restanti log abbiamo infatti il seguente andamento:

FIG 3 - Andamento della Nonpaged pool allocata dal TAG Pipo.

Come è possibile notare è presente un leak sul TAG Pipo. Ora che abbiamo identificato il TAG che sta alla base del memory leak, come possiamo identificarne il driver corrispondente?

Identificare il driver

L’elenco di tutti i TAG utilizzati per le allocazioni nella memoria Pool sono disponibili nel file Pooltag.txt
Questo file contiene l’identificativo di tutti i componenti Kernel-mode e driver rilasciati con i Sistemi Operativi Windows.

E’ disponibile per il download e l’installazione all’interno dei Debugging Tools for Windows:

Un esempio del contenuto del file Pooltag.txt è riportato di seguito:

8042 - i8042prt.sys - PS/2 kb and mouse
AdSv - vmsrvc.sys   - Virtual Machines Additions Service
ARPC - atmarpc.sys - ATM ARP Client
ATMU - atmuni.sys   - ATM UNI Call Manager
ACPI - acpi.sys     - ACPI
Afd? - afd.sys      - AFD objects
AfdA - afd.sys      - Afd EA buffer

Se il TAG che causa il leak di memoria non è contenuti nell’elenco, vi consiglio di effettuare una ricerca nella nostra Knowledge Base, in modo da verificare la presenza di eventuali problemi conosciuti e installare la relativa hotfix.

Se invece, come nel caso del nostro esempio, il TAG non è Microsoft non sarà presente nell'elenco.
In questo caso possiamo utilizzare il comando findstr, valido per ciascuna versione di Windows, che potrà essere eseguito come indicato di seguito:

Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostarsi nella cartella %systemroot%\system32\drivers
Digitare il comando
findstr /m /l <tag> *.sys
Verificare l'output restituito dal comando

In questo screenshot è evidenziata la ricerca per il TAG Pipo:

Come possiamo notare è restituito il driver corrispondente al TAG specificato “Pipo”.

In questo caso occorrerà verificare un'eventuale versione aggiornata del driver Pippo.sys, o eventualmente contattare il fornitore del software segnalando la problematica.

Conclusione

Alla luce di quanto visto fino ad ora, se stiamo evidenziando un leak di memoria sul nostro sistema potremo identificarne la potenziale causa attraverso i seguenti passi:

Monitorare i byte allocati da ciascun TAG durante una finestra temporale adeguata al nostro leak, attraverso il tool poolmon.exe
Evidenziare eventuali allocazioni che variano proporzionalmente al tempo in costante crescita
Stabilire su che tipo di pool è presente il leak (Paged o Nonpaged)
Stabilire il driver associato al TAG che sta causando il leak
Ricercare eventuali problemi noti, o analizzare la problematica con il fornitore del driver

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Memoria Paged e NonPaged Pool – Come identificare un memory leak

itentblg — Mon, 11 May 2009 02:00:00 GMT

In questo post vedremo come identificare le problematiche legate ad un esaurimento di due specifiche risorse Kernel: Paged Pool e NonPaged Pool.
Vi consiglio di leggere il post di Fabio Lavatelli per una visione esaustiva della memoria: Kernel Memory Overview.

Memoria Paged e NonPaged Pool

All’avvio del computer, il Memory Manager crea dinamicamente due memorie pool di dimensione fissa per tutto il periodo in cui il Sistema Operativo rimane attivo: queste due pool sono conosciute come Paged Pool e NonPaged Pool.

Le dimensioni di queste pool, determinate all'avvio, dipendono da una serie di fattori: alcuni di questi possono essere modificati attraverso specifiche chiavi di registry, mentre altri dipendono dall’hardware specifico del computer, come la quantità di memoria fisica.

Entrambe le pool possono raggiungere un valore massimo teorico dipendente dall’architettura del sistema operativo:

Tipo Pool	Sistemi a 32-Bit (x86)	Sistemi a 64-Bit (x64)
NonPaged	256 MB (Windows 2000, XP e 2003) 128 MB (Con opzione /3GB abilitata al boot)	128 GB
Paged	491,875 MB (Windows 2000 e Windows XP) 650,000 MB (Windows Server 2003)	128GB

Nel caso sia abilitata l’opzione /3GB nel file boot.ini la dimensione massima teorica della NonPaged Pool è dimezzata. Questo è dovuto alla gestione nel Sistema Operativo della memoria virtuale: sono dedicati 3 Gigabyte alla parte applicativa e solo 1 Gigabyte alla parte kernel.

I Sistemi Operativi a 64 bit (x64) presentano limiti di memoria virtuale superiori di diversi ordini di grandezza rispetto a sistemi a 32 bit (x86), perciò un'eventuale saturazione della memoria disponibile avverrebbe in tempi più elevati.

La sostanziale differenza tra le due tipologie di pool, come evidenzia il nome, è che la Paged Pool può essere paginata su disco, mentre la NonPaged Pool è sempre residente in memoria.

I driver utilizzano la NonPaged Pool per tutte quelle operazioni eseguite ad un Interrupt Request Level (IRQL) troppo elevato per ammettere paginazione.
L'IRQL definisce la priorità a cui il processore sta operando, maggiori informazioni sono disponibili nel seguente articolo: Scheduling, Thread Context, and IRQL

Eventi SRV 2019 e 2020

Nel caso in cui un driver abbia un funzionamento anomalo, potrebbe allocare memoria Pool senza mai rilasciarla arrivando alla saturazione di tutto lo spazio a disposizione: questo fenomeno è chiamato memory leak.

In questo tipo di scenario, generalmente troviamo nel Log degli Eventi di Sistema i seguenti 2 eventi specifici.
L'evento 2019 si riferisce all'esaurimento della NonPaged pool:

Type: Error
Date: <date>
Time: <time>
Event ID: 2019
Source: Srv
User: N/A
Computer: <ComputerName>
Details: The server was unable to allocate from the system NonPaged pool because the pool was empty.

Mentre l'evento 2020 riguarda l'esaurimento della Paged Pool:

Type: Error
Date: <date>
Time: <time>
Event ID: 2020
Source: Srv
User: N/A
Computer: <ComputerName>
Details: The server was unable to allocate from the system Paged pool because the pool was empty

In alcuni scenari specifici di memory leak, gli eventi 2019 e 2020 non sono presenti nel Registro Eventi, ma sono loggati molti errori 333 - Application Popup:

Type: Error
Date: <date>
Time: <time>
Event ID: 333
Source: Application Popup
User: N/A
Computer: <ComputerName>
Details: An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry

Maggiori informazioni riguardo questo scenario sono spiegati nel post Analizzare l’evento “Application Popup 333”

Analizzare un Memory Leak

Il comportamento del Sistema Operativo in presenza di un memory leak è imprevedibile: si possono registrare hang, crash di applicazioni o BlueScreen (bugcheck 0x0000041 MUST_SUCCEED_POOL_EMPTY).

Il performance monitor permette di verificare lo stato della Memoria Pool con i seguenti counter:

Counter	Description
Memory\Paged Pool Bytes	Indica il numero di byte allocati nella Paged Pool di sistema
Memory\Non Paged Pool Bytes	Indica il numero di byte allocati nella NonPaged Pool di sistema

Il grafico seguente illustra un andamento tipo di un memory leak relativo alla NonPaged Pool:

FIG 1 - Andamento tipico di un memory leak relativo alla NonPaged Pool.

La NonPaged Pool allocata, indicata in MegaByte, è al di sotto del valore massimo teorico di 256 MB, ma presenta un andamento crescente che indica un tipico caso in cui un driver non stia rilasciando la memoria allocata.

La crescita può essere variabile in funzione del tempo, e per questo la finestra temporale di monitoring dovrà essere modulata proporzionalmente alla rapidità del leak.

Il grafico seguente illustra un altro andamento tipo di saturazione di memoria relativo alla NonPaged Pool:

FIG 2 - Andamento variabile relativo alla NonPaged Pool.

L’andamento non risulta crescente, ma può indicare ugualmente la presenza di problemi dovuti al raggiungimento del limite massimo di memoria Pool disponibile. In questa situazione non abbiamo un vero e proprio memory leak, ma una saturazione della NonPaged Pool che richiede un tuning manuale di specifiche chiavi di registry.

I due andamenti riportati valgono per entrambe le tipologie di memoria Pool anche se i limiti più stringenti e che presentano più problemi sono relativi alla memoria NonPaged Pool.

Nei successivi post vedremo nel dettaglio come approfondire e risolvere:

Problemi di memory leak
Problemi di saturazione della memoria

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Kernel Memory Overview

itentblg — Mon, 15 Dec 2008 03:00:00 GMT

Introduzione

Alcuni problemi riportati da applicazioni server, come anche da applicativi tradizionali, possono essere ricondotti all'esaurimento di memoria. Una domanda che spesso ci si pone è se si possa risolvere il problema aumentando la disponibilità di memoria RAM (Random Access Memory), ovvero la memoria fisica installata sul server o sulla workstation. In taluni casi la risposta è affermativa ma sfortunatamente in molte altre situazioni un upgrade hardware non risolve il problema.

Un errore riportato come un esaurimento di memoria o di risorse può essere riferito ad un particolare tipo di memoria, con certi limiti, i quali non sono correlati alla quantità di memoria totale installata sulla macchina ma primariamente legati all'architettura del processore e a come è stato progettato il sistema operativo.

In questo post vengono analizzate e classificate le principali risorse di memoria gestite dal sistema operativo, sono poi considerati gli scenari generici di esaurimento per i vari casi trattati. In un seguente post si vedranno i principali parametri da verificare ed un cenno alle metodologie di troubleshooting. Poiché la piattaforma a 32 bit è più soggetta a problemi di esaurimento di risorse, per le evidenti limitazioni rispetto a quella a 64 bit, essa sarà l'oggetto primario del post. Le informazioni architetturali trattate sono comunque valide per ogni sistema Windows e salvo casi particolari applicabili anche alla seconda. Ove si quantifichino dei valori numerici sono invece da considerarsi specifici alla piattaforma a 32 bit.

I contenuti dei primi post su questa tematica saranno primariamente teorici ed architetturali, introduttivi a quelli che seguiranno da parte mia e dei miei colleghi, indirizzati alla risoluzione di problemi più specifici.

Classificazione delle risorse di memoria nel sistema operativo Microsoft Windows

Memoria fisica: con questo termine si intende la memoria RAM installata e presente sul server, si tratta quindi di hardware effettivamente nella macchina. Nelle modalità di esecuzione dei processori nei moderni sistemi operativi (paging abilitato) la memoria fisica non è direttamente accessibile: è sempre necessario un meccanismo di mapping che permetta di indirizzare la memoria virtuale o logica (definita sotto) su quella fisica. I recenti processori Intel a 32 bit supportano un massimo di 64GB di memoria, limitata a questi valori dall'architettura. Quelli a 64 bit ne supportano quantità maggiori e crescenti in futuro.
Memoria virtuale o spazio di indirizzi logico: tramite il mapping citato sopra vengono presentati 4GB di memoria virtuale al codice che gira sul processore. Tale memoria virtuale può mapparsi sulla memoria fisica, su pagine di memoria riversate sul disco (paging file) o su nessuna destinazione per intervalli di indirizzi virtuali non in uso.
Relativamente a questo argomento i termini logico e virtuale sono intercambiabili, più precisamente il primo è parte della terminologia definita da Intel per i propri processori, il secondo è più legato all'ambito dei sistemi operativi, come per esempio Windows, che è stato progettato per essere portabile su differenti architetture, quindi non legato alle terminologie specifiche di particolari tipi di hardware.
Risorse kernel: il kernel del sistema operativo alloca memoria, per le proprie funzioni e per i driver installati da tre importanti risorse, inaccessibili agli applicativi: due pool (nonpaged e paged) e le System PTE. Il fatto che ci siano tre risorse diverse è per soddisfare certi differenti requisiti, che rendono alcune risorse più preziose di altre, in dettaglio:

Non-paged pool: la caratteristica di quest'area di memoria per le allocazioni del kernel è di essere sempre disponibile e permanentemente mappata su memoria fisica, in altre parole non può essere paginata sul disco di paging, da cui il nome. Date queste sue caratteristiche è più preziosa delle altre due, richiedendo costantemente una quantità di memoria fisica pari alla sua dimensione.
Paged pool: è un'altra forma di memoria allocabile dai componenti kernel, è meno pregiata, quindi generalmente più abbondante, in quanto all'occorrenza può essere oggetto di paging (swap) per liberare memoria fisica ad altre esigenze.

System PTE: sono degli elementi di allocazione con granularità di una pagina di memoria (4096 byte) ed hanno particolari caratteristiche che le rendono più versatili delle precedenti. Possono essere usate solo per specifici scopi da parte di pochi componenti del kernel, data la complessità di gestione, che è il prezzo della loro versatilità. A titolo di esempio gli stack kernel, i memory mapped device, alcuni tipi di video buffer e i buffer di memoria per trasferimenti di tipo DMA (Direct Memory Access) utilizzano questa risorsa.

Per ciascuna delle risorse citate un consumo eccessivo ed incontrollato può sempre portare all'esaurimento, più frequentemente uno o più componenti possono allocare memoria dei vari tipi e non rilasciarla, tipicamente per un bug, anche in questo caso se non interviene un reboot si arriva più o meno velocemente all'esaurimento. Questo tipo di esaurimento è definito come memory leak.

Aspetti specifici per ciascuna categoria e tipologie di esaurimento

Memoria fisica: sebbene la prima ipotesi a cui si vorrebbe attribuire un esaurimento di memoria sia quasi sempre la memoria fisica, nella realtà gli esaurimenti di questa risorsa sono rari. Il sistema operativo gestisce molto bene la memoria fisica. Potendosi poggiare sul paging file per liberare memoria, è difficile che si arrivi realmente al punto di non averne a sufficienza per le funzioni minime di un server. In realtà la penuria di questa risorsa viene percepita molto presto come un peggioramento progressivo della performance del server che, trovandosi a dover continuamente spostare dati tra memoria fisica ed il file di paging, allo scopo appena citato, diventa molto lento.
In ogni caso, quando si arrivi alla conclusione che un server necessita di 4GB o più, si rende necessario abilitare un kernel alternativo del sistema operativo che sfrutta su una funzionalità del processore denominata PAE (Physical Addressing Extension). Tramite questo meccanismo i 32 bit di indirizzi logici vengono mappati su 36 bit permettendo di indirizzare, e quindi installare, fino a 64GB di memoria fisica. L'abilitazione di questo meccanismo avviene tramite lo switch /PAE nel boot.ini. Questo switch non ha nessuna relazione con il /3GB, descritto sotto e che agisce sugli spazi di indirizzamento logici.
E' da notare che anche con soli 4GB il PAE è necessario per vedere tutta la memoria presente, a causa di un intervallo di indirizzi fisici aggiuntivi occupati da certi dispositivi hardware (es. PCI devices).
Memoria virtuale o spazio di indirizzi logico: Questo spazio, di 4GB per le architetture a 32 bit, è diviso in due parti che vanno rispettivamente al kernel e agli applicativi, La seconda porzione, per gli applicativi, è strutturata in modo che ognuno ne abbia una sua visione privata, che è alla base della garanzia del loro isolamento. La divisione di default, sin dal design iniziale del sistema operativo Windows NT 3.1, è di 2GB per il kernel e 2GB per lo spazio lasciato agli applicativi.
Il sistema deve ripartire lo spazio kernel, di 2GB, tra le tre risorse del kernel descritte sopra. Questa divisione avviene in modo più o meno statico, a seconda della versione del sistema, e non si arriva mai ad esaurire lo spazio di indirizzi in quanto tale, tuttavia, data la ripartizione appena citata, quello che può succedere è che si esauriscano le singole risorse, i tre casi vengono quindi analizzati oltre.
A livello applicativo, specie per applicazioni server (es. Microsoft SQL Server, Microsoft Exchange Server) il massimo di 2GB può essere effettivamente limitante. Per aumentare questa risorsa agli applicativi già da Windows NT4.0 venne introdotto lo switch del boot.ini /3GB. Questa impostazione alternativa permette di offrire 3GB di spazi di indirizzi virtuali agli applicativi, tuttavia questo avviene a scalpito degli spazi kernel che devono limitarsi a 1GB e questa riduzione impatta significativamente le tre risorse kernel, che risultano notevolmente limitate, a grandi linee dimezzate.
Sia nella configurazione tradizionale che /3GB un eventuale esaurimento dello spazio a disposizione degli applicativi potrebbe essere percepito con errori tipo "Out of memory", "Not enough resources" o similari. In questo caso solo l'intervento di supporto di chi ha venduto o sviluppato il software può identificare con precisione se effettivamente si è arrivati a questo esaurimento.
Tecniche che gli sviluppatori hanno a disposizione per poter gestire dati di grandi dimensioni su piattaforme a 32 bit sono AWE (Address Windowing Extension) e l'attivazione di un particolare bit nell'immagine del proprio eseguibile, IMAGE_FILE_LARGE_ADDRESS_AWARE, per essere effettivamente abilitati all'accesso di tutti i 3GB nella configurazione /3GB. I dettagli su queste due tecniche esulano dallo scopo di questo post. Su piattaforma a 64 bit gli applicativi a 64 bit hanno a disposizione un vastissimo spazio di indirizzo che non viene correntemente considerato limitante in alcun modo. Un applicativo a 32 bit, con il bit IMAGE_FILE_LARGE_ADDRESS_AWARE attivo, accede a 4GB su una piattaforma a 64 bit, traendo quindi un certo vantaggio.
E' importante ribadire che tutto quanto descritto in questo paragrafo avviene in termini di spazi di indirizzi virtuali, quindi in modo pressoché indipendente dal numero di GB di memoria fisica disponibile sul server.
Non-paged e paged pool: l'esaurimento di una delle pool o entrambe causa seri problemi di stabilità. Tutti i componenti kernel del sistema ed i driver non riescono ad allocare memoria anche per semplici operazioni di base. In teoria al permanere di questa penuria il server diventa incapace di svolgere numerose funzioni, il che impedisce di erogare i servizi per il quale è preposto. Nella pratica in numerosi casi si arriva al blue screen o al blocco irreversibile del server, infatti la continuata incapacità di svolgere i propri compiti colpirà prima o poi una funzione vitale del server che può manifestarsi nei modi citati, altresì certi driver non sono perfettamente testati nel gestire queste situazioni limite e quindi espongono dei bug, che normalmente non si vedrebbero, e che possono portare al blue screen.
Nella maggioranza dei casi l'esaurimento delle pool è dovuto a memory leak nei driver o in certi componenti del sistema operativo. In altri casi le applicazioni, sebbene non abbiano accesso diretto per allocare da questa risorsa, posso ugualmente indurre il loro esaurimento. Ciò avviene se richiedono funzioni che nella loro implementazione, nel kernel, alloca dalle pool. Ad esempio un applicativo che aprisse numerosi file o connessioni di rete senza mai chiuderli causerebbe un memory leak, in questo esempio primariamente nella paged pool.
Un server con una configurazione particolarmente complessa, che include molti componenti kernel diversi, quando sotto carico potrebbe arrivare ad esaurire una delle pool, pur non avendo alcun memory leak.
Un dimensionamento non appropriato delle pool, nei valori del Memory Manager (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management) nel registry, può portare al loro esaurimento in quanto semplicemente insufficienti.
System PTE: l'esaurimento delle System PTE porta a fenomeni simili a quelli descritti sopra, in questo caso i componenti che allocano questa risorsa sono più interni al sistema e quindi si hanno effetti, dal punto di vista interno al sistema, differenti ma con sintomi paragonabili a quelli appena descritti. Spesso la penuria di System PTE (meno di 3000-5000 PTE libere) porta ad un errore di inizializzazione degli applicativi con codice 0xC0000142 (STATUS_DLL_INIT_FAILED).
Anche in questo caso la maggioranza degli esaurimenti viene identificata in leak su questo tipo di risorsa per mancati rilasci in driver o componenti kernel, l'esempio più classico è il mancato rilascio di buffer di I/O allocati per trasferimenti DMA.
Bug negli applicativi non sono solitamente correlabili a System PTE leak.
Un dimensionamento non appropriato delle System PTE, nei valori del Memory Manager nel registry (valore "SystemPages"), può portare al loro esaurimento in quanto semplicemente insufficienti.

Conclusione

Questo post ha voluto trattare una classificazione delle risorse comunemente denominate come "risorse di memoria" e gli scenari che possono dar luogo a dei problemi. Costituisce una base teorica per dei post più pratici e rivolti alla risoluzione di problemi reali che verranno trattati in futuro su questo blog.

Fabio Lavatelli
Escalation Engineer
Microsoft Enterprise Platform Support