Supporto Tecnico Enterprise : Mattia Tocco

Windows Update - Tipologie di aggiornamenti: QFE/LDR e GDR

itentblg — Mon, 14 Sep 2009 02:00:00 GMT

Spesso quando, prima dell'installazione di un pacchetto di aggiornamento, ci si sofferma a leggere l'elenco dei file che verranno aggiornati per la propria versione di sistema operativo, ci si trova davanti ad un elenco di questo tipo:

Come è possibile notare dalla figura, per ciascun file che è sostituito esiste sia una versione GDR, che una versione QFE identificabili dalla colonna “Service branch”.

Questo è dovuto al fatto che esistono due differenti tipologie di aggiornamenti, tipicamente definite come branch dagli sviluppatori Microsoft, che sono le General Distribution (GDR) e le Quick Fix Engineering (QFE).

GDR (General Distribution) - Un binario identificato come GDR, contiene solo gli aggiornamenti di sicurezza che sono stati eseguiti sul file, includendo i cambiamenti necessari per l'update in rilascio e quelli relativi alla precedenti security hotfix che aggiornavano lo stesso file. Questo tipo di aggiornamenti vengono rilasciati attraverso Windows Update.

QFE (Quick Fix Engineering) - Un binario identificato come QFE contiene sia gli aggiornamenti di sicurezza e sia gli aggiornamenti funzionali, includendo tutti i cambiamenti per l'update in rilascio e tutti quelli relativi alle precedenti security hotfix e bug hotfix. Con Windows Vista e Windows Server 2008, le QFE sono state rinominate in LDR (Limited Distribution Release).

Per chiarire ulteriormente la differenza, possiamo fare riferimento al seguente schema:

Se, dunque, per un ipotetico binario pippo.sys abbiamo installato la versione GDR – Security Hotfix #3, le correzioni introdotte con l’Hotfix #2 non saranno presenti.

Alla luce di quanto appena detto, la seguente domanda sarebbe più che lecita:

“ho trovato l’articolo KB XYZ (QFE – Hotfix #2) che rispecchia esattamente il problema che io sto riscontrando, ma il numero di build indicato per I file che l’update andrà ad installare è più vecchio di quello attualmente installato sulla mia macchina attraverso l’hotfix relativa all’articolo KB ABC (GDR – Security Hotfix #3). Come mai il mio problema risulta ancora presente anche dopo l’installazione della KB ABC?”

Il problema è ancora presente perché il security update (GDR) introdotto attraverso l’articolo KB ABC, sebbene più recente in termini di build, non include la correzione rilasciata con l’articolo KB XYZ che appartiene alla branch delle QFE.

Come identificare la versione di un binario installato

Windows XP o Windows Server 2003

Supponiamo di voler identificare a quale branch appartiene il nostro solito file pippo.sys, possiamo seguire la seguente procedura:

Fare clic sul pulsante Start, scegliere Search.
Nella casella Nome del file o parte del nome digitare il nome del file (pippo.sys nel nostro esempio), quindi scegliere Search.
Nel riquadro dei risultati della ricerca, fare clic con il pulsante destro del mouse sul file, quindi scegliere Properties.
Nella scheda Version, fare clic su File Version nell'area Other version information

Otterremo una finestra di questo tipo:

Dalle seguenti due tabelle possiamo identificare a quale branch appartiene il binario e quale sarà la versione installata in automatico da Windows Update

Windows Server 2003

Version	Description
srv03_rtm.mmmmmm-nnnn	Questo formato indica che il file proviene dalla versione originale del prodotto e che non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_gdr.mmmmmm-nnnn	Questo formato indica che il file proviene da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver o un feature pack e che non è stato aggiornato da un hotfix. Si tratta della build basata su SPx. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_rtm.mmmmmm-nnnn	Questo formato indica che il file proviene da SPx e non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
srv03_spx_qfe.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Si tratta della build basata su SPx. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.

Windows XP

Version	Description
xpclient.mmmmmm-nnnn	Questo formato indica che il file proviene dalla versione originale del prodotto e che non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpsp_spx_gdr.mmmmmm-nnnn	Questo formato indica che il file proviene da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver o un feature pack e che non è stato aggiornato da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpspx.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.
xpspxrtm.mmmmmm-nnnn	Questo formato indica che il file proviene da SPx e non è stato aggiornato da un aggiornamento della protezione, un aggiornamento critico, un aggiornamento, un aggiornamento cumulativo, un driver, un feature pack o un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione GDR.
xpclnt_qfe.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.
xpsp.mmmmmm-nnnn	Questo formato indica che il file proviene da un hotfix pre-SP3. Per poter installare questo file è necessario disporre del Service Pack 2. Gli aggiornamenti della protezione, gli aggiornamenti critici, gli aggiornamenti, gli aggiornamenti cumulativi, i driver e i feature pack sostituiranno il file con una versione hotfix che include anche la correzione GDR.

Nell’esempio riportato sopra, la versione è: srv01_sp2_rtm-070216-1710 ovvero il file è stato installato con il service pack 2. Un eventuale aggiornamento sostituirà il binario con la relativa versione GDR.

Windows Vista o Windows Server 2008

Analogamente a quanto visto in precedenza, supponiamo di voler determinare la versione del driver Win32k.sys:

Fare clic sul pulsante Start e dal Search immettere il nome del file (Win32k.sys nel nostro caso)
Nel riquadro dei risultati della ricerca, fare clic con il pulsante destro del mouse sul file, quindi scegliere Properties.
Identificare la voce File Version, nella scheda Details

Otterremo un risultato di questo tipo:

Per identificare la versione, possiamo fare riferimento alla seguente tabella:

Version	Product	Level	Service Branch
6.0.600 0 . 16 xxx	Windows Vista	RTM	GDR
6.0.600 0 . 20 xxx	Windows Vista	RTM	LDR
6.0.600 1 . 18 xxx	Windows Vista and Windows Server 2008	SP1	GDR
6.0.600 1 . 22 xxx	Windows Vista and Windows Server 2008	SP1	LDR
6.0.600 2 . 18 xxx	Windows Vista and Windows Server 2008	SP2	GDR
6.0.600 2 . 22 xxx	Windows Vista and Windows Server 2008	SP2	LDR

Nel nostro esempio la versione è 6.0.6000.22416. Questo è dunque un file di Windows Vista ed appartiene alla branch GDR.

Come forzare l'installazione di una versione QFE/LDR

Windows XP o Windows Server 2003

Attraverso lo switch /B possiamo specificare la branch da cui l’update verrà installato, che sostituisce la scelta predefinita che sarebbe stata effettuata dall’update.exe
Questo significa che se di default il programma di update installerebbe il binario dal branch GDR, noi possiamo forzare l’installazione della relativa QFE.
Esempio, per una hotfix relativa al service pack 2 possiamo digitare:

WindowsServer2003.WindowsXP-KB999999-x64-ENU.exe /b:SP2QFE

Questo farà in modo che venga installata la versione QFE dell’hotfix specificata.
Lo switch /B non può essere utilizzato per installare la versione GDR di un binario che appartiene già al ramo QFE.
L’unico modo per tornare alla branch GDR, partendo da una QFE, è quello di rimuovere tutti gli update QFE o installare l’ultimo service pack disponibile.

Windows Vista o Windows Server 2008

Possiamo seguire I seguenti passi per forzare l’installazione di una LDR in Windows Vista e Windows Server 2008:

C:\> Expand -f:* <path del file .msu relativo all’update> <folder che conterrà l’espansione del file msu>
C:\> Expand -f:* <path del file KB#.cab contenuto nella cartella di espansione del file msu> <folder che conterrà l’espansione del cab>
C:\> pkgmgr /ip /m:<folder che conterrà l’espansione del cab> \update-bf.mum

Riferimenti utili

Branching out
http://blogs.technet.com/mrsnrub/archive/2009/05/18/branching-out.aspx
What is the difference between general distribution and limited distribution releases?
http://blogs.msdn.com/windowsvistanow/archive/2008/03/11/what-is-the-difference-between-general-distribution-and-limited-distribution-releases.aspx
Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages
http://support.microsoft.com/kb/824994

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

DPM 2007 – Script per impostare una tape come free

itentblg — Mon, 13 Jul 2009 02:00:00 GMT

L'obiettivo di questo articolo è quello di fornire uno script, per marcare una tape come free, prima che la relativa data di retention sia trascorsa.

DPM non consente, infatti, di effettuare questa operazione da interfaccia grafica. Tuttavia, potrebbe essere necessario in particolari scenari, esempio durante una fase di test, recuperare un tape marcandolo come free.

A tal fine, prendiamo in considerazione il seguente script che andrà salvato con estensione .ps1:

----------------------------- Start of Script --------------------------------

param ([string] $DPMServerName, [string] $LibraryName, [string[]] $TapeLocationList)

if(("-?","-help") -contains $args[0])
{
    Write-Host "Usage: ForceFree-Tape.ps1 [[-DPMServerName] <Name of the DPM server>] [-LibraryName] <Name of the library> [-TapeLocationList] <Array of tape locations>"
    Write-Host "Example: Force-FreeTape.ps1 -LibraryName "My library" -TapeLocationList Slot-1, Slot-7"
    exit 0
}

if (!$DPMServerName)
{
    $DPMServerName = Read-Host "DPM server name: "

    if (!$DPMServerName)
    {
        Write-Error "Dpm server name not specified."
        exit 1
    }
}

if (!$LibraryName)
{
    $LibraryName = Read-Host "Library name: "

    if (!$LibraryName)
    {
        Write-Error "Library name not specified."
        exit 1
    }
}

if (!$TapeLocationList)
{
    $TapeLocationList = Read-Host "Tape location: "

    if (!$TapeLocationList)
    {
        Write-Error "Tape location not specified."
        exit 1
    }
}

if (!(Connect-DPMServer $DPMServerName))
{
    Write-Error "Failed to connect To DPM server $DPMServerName"
    exit 1
}

$library = Get-DPMLibrary $DPMServerName | where {$_.UserFriendlyName -eq $LibraryName}

if (!$library)
{
    Write-Error "Failed to find library with user friendly name $LibraryName"
    exit 1
}

foreach ($media in @(Get-Tape -DPMLibrary $library))
{
    if ($TapeLocationList -contains $media.Location)
    {
        if ($media -is [Microsoft.Internal.EnterpriseStorage.Dls.UI.ObjectModel.LibraryManagement.ArchiveMedia])
        {
            foreach ($rp in @(Get-RecoveryPoint -Tape $media))
            {
                Get-RecoveryPoint -Datasource $rp.Datasource | Out-Null

                Write-Verbose "Removing recovery point created at $($rp.RepresentedPointInTime) for tape in $($media.Location)."
                Remove-RecoveryPoint -RecoveryPoint $rp -ForceDeletion -Confirm:$false
            }

            Write-Verbose "Setting tape in $($media.Location) as free."
            Set-Tape -Tape $media -Free
        }
        else
        {
            Write-Error "The tape in $($media.Location) is a cleaner tape."
        }
    }
}

----------------------------- End of Script --------------------------------

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

DPM 2007 - Drive visualizzati come Standalone drive

itentblg — Mon, 06 Jul 2009 02:00:00 GMT

Lo scopo di questo post è quello di fornire le informazioni per risolvere una potenziale problematica relativa ai drive di una library esposti da Data Protection Manager 2007.

Potrebbe capitare che, in seguito all'installazione di una library sul nostro server DPM 2007, i relativi drive siano visualizzati come Standalone Drives:

La prima cosa che dobbiamo verificare è il modo in cui sono visualizzati i drive e la library in Device manager:

Questo è un tipico caso in cui i driver della library non sono installati correttamente e dunque la library è visualizzata come "Unknown Medium Changer" e potenzialmente anche i drive non sono riconosciuti correttamente.

Occorrerà dunque richiedere al vendor i driver corretti, portandosi in una situazione coerente come quella riportata nella seguente figura:

Se anche dopo aver installato l'hardware in maniera corretta ed aver effettuato un rescan dalla console DPM, o se questo fosse stato già installato correttamente in precedenza, si continuano a visualizzare i drive come standalone, verificare se la library che si sta utilizzando è tra quelle certificate per DPM.
A tal fine sarà possibile utilizzare il seguente link:

System Center Data Protection Manager 2007 Tested Hardware
http://technet.microsoft.com/it-it/dpm/cc678583(en-us).aspx

Se il problema ancora persiste, una volta accertato che la nostra library è tra quelle testate per Data Protection Manager 2007, possiamo effettuare un remapping dei drive.

Per eseguire questa procedura, accertarsi che:

Il servizio DPMLA dovrà essere arrestato
Occorrerà rimuovere tutte le tape dai vari drive

Eseguire i seguenti task:

Effettuare un backup del file <DPM Installation path>\Config\DPMLA.xml ed eliminarlo
Rigenerarlo attraverso il tool: <DPM Installation path>\Bin\DriveMappingTool.exe
Aprire la console DPM ed eseguire un rescan

L'esecuzione del tool fallirà se eseguito per un drive standalone, restituendo il seguente errore:

La procedura sopra esposta è documentata al seguente link:

Remapping Tape Drives
http://technet.microsoft.com/en-us/library/bb795782.aspx

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

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

Analizzare l’evento “Application Popup 333”

itentblg — Mon, 17 Nov 2008 03:00:00 GMT

In questo mio primo post vorrei parlarvi di un evento, che sotto determinate condizioni, è possibile riscontrare nel Registro Eventi del proprio server: l’Application Popup 333.

Come prima cosa cerchiamo di capire a cosa si riferisce questo evento.

Partiamo con l’indicare che il relativo source è l’Application Popup, che ci notifica negli eventi di sistema che un’operazione di I/O iniziata dal registro è fallita. In particolare questo componente non è stato capace di leggere, scrivere o fare il flush su disco di determinate informazioni, che andranno dunque perse. Negli eventi di sistema vedremo una serie di segnalazioni come queste:

Sottolineo una serie perché in seguito al presentarsi del primo di questi eventi, circa ogni 5 secondi il sistema memorizzerà una nuova notifica, fino a quando non verrà effettuato un reboot della macchina.

In generale non possiamo determinare gli effetti della mancata scrittura o lettura del registro, ma questi saranno sicuramente circoscritti al componente che ha richiesto l’operazione. I sintomi che accompagnano questo evento, se presenti, sono differenti a seconda della causa che lo genera.

Tipici scenari possono riguardare hangs del sistema, risorse insufficienti per il completamento di un servizio richiesto, database SQL che si stoppano o che eseguono le query lentamente, o più in generale eventi legati alle performance del sistema operativo.

Questo evento è stato introdotto con Windows Server 2003 Service Pack 1 ed è possibile trovarlo sia su sistemi x86 che x64.

Terminata questa breve introduzione, passiamo all’analisi di quelle che possono essere le cause che portano a questo evento.

Il disco che sta ospitando il sistema operativo ha un carico di lavoro molto elevato, o ha dei problemi hardware, evidenziando una lunga coda di operazioni che attendono per essere eseguite. Possiamo avere questa circostanza sia su sistemi x86 che x64.
Esaurimento delle risorse lato Kernel: Non Paged Pool Memory (Evento SRV 2020 nel registro di sistema), Paged Pool Memory (Evento SRV 2019 nel registro di sistema) o Page Table Entries (PTE). Questa problematica riguarda, salvo eventi particolari, sistemi x86, a causa delle limitazioni dettate dall’architettura a 32 bit.
Un filter driver sta impedendo flush su disco del registri. Questo può accadere sia in sistemi x86, che x64.
E’ stato concesso il privilegio “Lock system pages in memory” ad un account user. Questo può succedere sia in sistemi x86, che x64.

Abbiamo elencato le ipotetiche cause del nostro evento 333, ma come facciamo a rimuoverlo?!

Dipende dal particolare scenario alla base del problema, analizziamo singolarmente le varie casistiche:

Problemi legati al disco

Per identificare questo tipo di problematica possiamo configurare i performance monitor forniti dal sistema operativo per l’analisi del nostro disco fisico. La prima grandezza che ci fornisce un’idea di come il nostro disco sta rispondendo alle operazioni richieste è la Current Disk Queue Length. Questo valore dovrebbe essere tipicamente non superiore a 1 per un disco, o più in generale non superiore a n per sistemi di memorizzazione costituiti da n dischi, come le varie tipologie di RAID. Occorre sollevare un’eccezione per le SAN, dove questo valore può essere falsato dalla metodologia di archiviazione utilizzata dall’hardware a disposizione e dunque eventuali anomalie riscontrate vanno sempre discusse con l’OEM.

FIG. 1 – Disco con valori della Current Queue Length anomali

FIG. 2 – Disco con valori della Current Queue Length normali

La figura 2 ci mostra un esempio un disco che sta eseguendo senza problemi le richieste di I/O derivanti dall’attività del sistema operativo. Dalla figura 2, invece, è possibile osservare un disco che sta accodando le richieste di I/O, introducendo dunque delle potenziali problematiche. E’ possibile suddividere le cause che possono portare ad una situazione come quella illustrata nella figura 1, in due sottogruppi:

Problemi strettamente legati all’hardware (Controller o unità disco)
Sovraccarico delle operazioni su disco

Consideriamo la prima casistica, il disco sta accodando delle richieste a causa di problemi hardware. L’accodamento è dunque causato da una lentezza da parte del sistema si storage nell’eseguire le richieste. Un altro counter, che affiancato alla Current Disk Queue Length, ci può evidenziare questa tipologia di problema è il Disk Response Time. Il tempo di risposta può variare a seconda delle specifiche del disco, ma in generale un tempo superiore ai 30ms dovrebbe essere investigato. Se i contatori esposti sembrano evidenziare un problema legato al sistema di storage, occorrerà aggiornare firmware e driver del controller ed eventualmente controllare i dischi attraverso i tool di hardware monitoring.

La seconda casistica riguarda un’eccessiva attività su disco. Un altro counter, che associato al Disk Queue Length, ci può evidenziare questo tipo di situazione è il I/O Data bytes/sec dell’oggetto Process. Occorrerà per prima cosa evidenziare eventuali processi che stanno eseguendo un’elevata attività di I/O e verificare se questo risulta in linea con i ruoli e le attività quotidiane del server. Se non si riscontrassero anomalie legate al binomio ruoli/attività disco, occorrerà effettuare un bilanciamento del carico su più dischi o server, ed eventualmente spostare il file di paging su un disco differente da quello di sistema.

Esaurimento delle risorse kernel

Tratteremo nel dettaglio la gestione di questa problematica nei prossimi post, partiamo comunque col dire che le tre grandezze che entrano in gioco in questo tipo e sono la Non Paged Pool Memory, la Paged Pool Memory e le Free Page Table Entries. Possiamo verificare questi valori attraverso i relativi contatori dell’oggetto memory. In particolare le soglie che dobbiamo tenere come riferimento, per sistemi Windows Server 2000 e 2003, sono le seguenti:

Non Paged Pool Memory (NPP)	< 256 MB ( 128 MB in sistemi con lo switch /3GB abilitato )
Paged Pool Memory (PP)	< 650 MB (491.875 per Windows 2000 e Windows XP)
Free Page Table Entries (PTE)	> 5.000 (Sotto questo valore il comportamento del sistema è imprevedibile)

L’esaurimento della Non Paged Pool Memory e Non Paged Pool Memory, è solitamente accompagnato dagli eventi d’errore 2019 e 2020 nei system events.

Se riscontriamo che la PP,o la NPP, si stanno avvicinando alle soglie indicate, occorrerà effettuare una specifica analisi per capire quale driver sta causando l’esaurimento della risorsa. Come anticipato tratteremo questo tipo di analisi in un articolo separato. In generale possiamo comunque investigare su problemi conosciuti di esaurimento della memoria, riguardanti i driver di terze parti attualmente installati sul nostro server. E’ buona norma mantenere sempre i driver dei vari prodotti, aggiornati all’ultima versione disponibile.

Per quanto riguarda le PTEs, occorrerà effettuare la seguente distinzione:

Switch /3GB abilitato nel boot.ini
In questo caso la memoria virtuale dedicata al sistema operativo si riduce da 2 a 1 GBytes, riducendo così anche lo spazio libero per le PTE. In questo particolare caso possiamo intervenire con lo switch /USERVA, come indicato nel seguente articolo:
KB 316739
How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
http://support.microsoft.com/default.aspx?scid=kb;EN-US;316739

In questo modo possiamo modificare la soglia tra i 3Gbyte della memoria virtuale user e il Gbyte della memoria virtuale dedicata al kernel.
Switch /3GB disabilitato nel boot.ini
In questo caso potremmo avere un leak di PTE, che possiamo analizzare attraverso l’impostazione del Track PTE ed un tool di debugging. Anche questa specifica problematica, verra trattata nell’articolo dedicato alle risorse kernel.

Filter driver

E’ doveroso premettere che rimuovendo o disabilitando un filter driver senza capire l’impatto sul sistema, potremmo riscontrare comportamenti inaspettati, come hang o blue screen. Esempi di applicativi che possono utilizzare dei filter driver includono: Anti-virus software, Backup Software, software di gestione volumi, software di criptazione/decriptazione dati etc.

Il metodo più semplice per determinare i filter driver, di terze parti, installati sulla nostra macchina è utilizzare la nostra utility MPS Report, che consente di raccogliere queste informazioni. Possiamo seguire dunque i seguenti passi:

Download del tool MPSRPT_SETUPPerf.exe dal link Microsoft Product Support Reporting Tools page.
Eseguire il file MPSRPT_SETUPPerf.EXE scaricato.
Terminata l’esecuzione, la durata media è di circa 15min, è possibile analizzare il file PStat.txt, estraendolo dal file .CAB creato dal tool. Tramite questo file possiamo verificare tutti i filter / kernel drivers con le relative date. Verificare eventuali versioni non aggiornata, o eventuali versioni che hanno già problemi riconosciuti dal vendor.

E’ importante che, prima di effettuare qualsiasi operazione di disabilitazione o rimozione, venga effettuato il controllo sulla disponibilità da parte del vendor di eventuali versioni aggiornate.

Lock system pages in memory

In sistemi a 64bit, come descritto precedentemente, la probabilità di avere valori preoccupanti per le PTEs è assai inferiore rispetto a sistemi x86. Tuttavia, abbiamo visto nella nostra attività quotidiana, eventi 333 capitare ugualmente anche in sistemi x64, dovuti a questo motivo.

Un workaround per questo comportamento in sistemi x64 con 4GB, o meno, di memoria RAM è costituito dai seguenti passi:

Cliccare su Start --> Run
Digitare Secpol.msc e premere OK
Espandere "Local Policies" e cliccare su "User Rights Assignment"
Doppio click su "Lock pages in memory"
Evidenziare eventuali user accounts elencati e cliccare su "Remove"
Premere su OK, una volta rimossi tutti gli user account
Riavviare il sistema

Di default il sistema operative non fornisce questo diritto a nessun account. Il privilegio “Lock pages in memory” è fornito all’account utilizzato per i servizi SQL in SQL 2005 RTM/SP1 Enterprise Edition installato su sistemi a 32bit. Se state utilizzando SQL Enterprise in un servers x86, con più di 4GB di RAM, questo privilegio è necessario. Per cercare di ridurre l’occorrenza degli eventi 333 nel sistema, occorrerà verificare che l’account che si sta utilizzando per I servizi SQL, sia utilizzato solo per SQL. Per sistemi x64 possiamo rimuovere tutti gli utenti elencati.

Bene questo è tutto per questo post. Come potete vedere le cause per l’evento 333 sono svariate e spesso correlate a problemi con alcuni driver o configurazioni: vi consiglio dunque di visitare regolarmente la nostra Microsoft Knowledge base per verificare le nuove pubblicazioni e gli ultimi aggiornamenti disponibili.

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platforms Support