Amministrazione di Windows

Il kernel di Windows Vista: parte 2

Mark Russinovich

 

Panoramica:

  • Gestione della memoria
  • Avvio e arresto del sistema
  • Risparmio di energia

Il mese scorso, nella prima parte di questa serie di tre articoli, sono stati illustrati i miglioramenti del kernel di Windows Vista nelle aree dei processi e dell'I/O.

In questo numero vengono presentati i miglioramenti nel modo in cui Windows Vista gestisce la memoria, oltre alle importanti novità relative all'avvio e arresto del sistema e al risparmio di energia (parte 1).

In ogni nuova versione di Windows ® vengono migliorate scalabilità e prestazioni e Windows Vista™ non fa eccezione. Sono stati apportati molti miglioramenti al Memory Manager di Windows Vista, come un utilizzo più estensivo delle tecniche di sincronizzazione senza blocchi, delle procedure di blocco più versatili e controllabili, delle strutture di dati più compatte, I/O con paging di maggiori dimensioni, supporto per le architetture di memoria delle GPU più recenti e un impiego più efficiente del buffer TLB (Translation Lookaside Buffer) hardware. Inoltre, la gestione della memoria di Windows Vista ora consente l'allocazione dinamica dello spazio degli indirizzo per i requisiti di carichi di lavoro diversi.

Quattro funzionalità tutte nuove per il miglioramento delle prestazioni che utilizzano tecnologie inedite debuttano in un sistema operativo proprio con Windows Vista: SuperFetch, ReadyBoost, ReadyBoot e ReadyDrive. Verranno descritte dettagliatamente più avanti in questo articolo.

Spazio degli indirizzi dinamico del kernel

Windows e le applicazioni che vengono eseguite in ambiente Windows hanno sempre dovuto fare i conti con i limiti dello spazio degli indirizzi dei processori a 32 bit. Il kernel di Windows viene limitato per impostazione predefinita a 2 GB oppure alla metà dello spazio degli indirizzi virtuale a 32 bit totale, con l'altra metà riservata al processo con il thread in esecuzione sulla CPU. Nella propria metà il kernel deve eseguire il mapping di se stesso, dei driver di dispositivo, della cache del file system, degli stack del kernel, delle strutture dei dati dei codici in base alla sessione e di entrambi i buffer non di paging (memoria fisica bloccata) e di paging allocati dai driver di dispositivo. Prima di Windows Vista, Memory Manager determinava al momento dell'avvio la quantità di spazio degli indirizzi da assegnare a questi scopi, ma la mancanza di flessibilità a volte generava situazioni in cui una delle aree si riempiva mentre l'altra restava quasi vuota. Quando un'area si riempie, possono verificarsi problemi con le applicazioni e con i driver di dispositivo che non riescono a completare le operazioni di I/O.

In Windows Vista a 32 bit Memory Manager gestisce lo spazio degli indirizzi del kernel in modo dinamico, allocando e rilasciando spazio per i vari usi in base al carico di lavoro. La quantità di memoria virtuale utilizzata per la memorizzazione dei buffer di paging può aumentare quando i driver di dispositivo ne richiedono di più e diminuire quando i driver ne rilasciano. Windows Vista sarà quindi in grado di gestire una varietà più ampia di carichi di lavoro e, allo stesso modo della versione a 32 bit del prossimo Windows Server® con nome in codice "Longhorn," di scalare per più utenti contemporanei di Terminal Server.

Naturalmente nei sistemi Windows Vista a 64 bit le limitazioni dello spazio degli indirizzi non rappresentano al momento un problema pratico e non richiedono quindi alcun trattamento particolare poiché sono già configurati sui rispettivi massimi.

Priorità della memoria

Come definisce le priorità di I/O (vedere il numero precedente), Windows Vista implementa allo stesso modo le priorità della memoria. Per comprendere il modo in cui Windows utilizza le priorità della memoria è necessario avere chiara l'implementazione della cache di Memory Manager, definita elenco di standby. In tutte le versioni di Windows che hanno preceduto Windows Vista, quando una pagina fisica (che in genere è di 4 KB) di proprietà di un processo veniva richiesta dal sistema, Memory Manager collocava la pagina alla fine dell'elenco di standby. Quando il processo doveva accedere di nuovo alla pagina, Memory Manager recuperava la pagina dall'elenco di standby e la riassegnava al processo. Quando invece un processo doveva utilizzare una nuova pagina di memoria fisica e non era disponibile memoria libera, Memory Manager passava la pagina all'inizio dell'elenco di standby. In questo schema tutte le pagine dell'elenco di standby venivano trattate in modo paritetico, utilizzando solo il tempo per cui erano collocate nell'elenco per eseguirne l'ordinamento.

In Windows Vista a ciascuna pagina di memoria viene assegnata una priorità compresa tra 0 e 7, dunque Memory Manager suddivide l'elenco di standby in otto elenchi che contengono ciascuno le pagine con una determinata priorità. Quando Memory Manager deve prelevare una pagina dall'elenco di standby, sceglie prima le pagine dagli elenchi con priorità più bassa. La priorità di una pagina in genere riflette la priorità del thread che ne ha richiesto per primo l'allocazione. Se la pagina è condivisa, riflette la priorità della memoria più alta dei thread di condivisione. Un thread eredita il valore di priorità della pagina dal processo a cui appartiene. Memory Manager utilizza le priorità più basse per le pagine che legge dal disco in modo speculativo quando anticipa gli accessi alla memoria del processo.

Per impostazione predefinita, ai processi viene assegnata una priorità di pagina pari a 5, ma alcune funzioni consentono ad applicazioni e sistema di modificare la priorità di pagina e il processo. I vantaggi della priorità della memoria si realizzano al massimo quando le priorità relative delle pagine vengono comprese a livello di macro, che è la funzione di SuperFetch.

SuperFetch

Una novità significativa di Memory Manager consiste nella modalità di gestione della memoria fisica. La gestione dell'elenco di standby utilizzata dalle versioni precedenti di Windows era afflitta da due limitazioni. Primo limite: la definizione della priorità delle pagine era basata solo sul comportamento recente dei processi e non prevedeva le esigenze future in termini di memoria. Secondo limite: i dati utilizzati per la definizione della priorità si limitavano all'elenco delle pagine di proprietà di un processo in un determinato momento. Queste limitazioni possono generare scenari come "la sindrome del dopo pranzo", in cui si lascia il computer per un breve periodo e si avvia un'applicazione che utilizza la memoria in modo intensivo (ad esempio, una deframmentazione del disco o una scansione dell'antivirus). Tale applicazione forza la sovrascrittura da parte delle attività a consumo intensivo di memoria del codice e dei dati che le applicazioni attive avevano inserito nella cache in memoria. Quando si torna dalla pausa, le prestazioni sono molto peggiori perché le applicazioni devono richiedere la lettura di dati e codice dal disco.

Con Windows XP è stato introdotto il supporto della prelettura, che ha migliorato le prestazioni di avvio del sistema e delle applicazioni eseguendo operazioni di I/O da disco per precaricare in memoria i dati del file system e il codice necessari, in base agli avvii precedenti di sistema e applicazioni. Con Windows Vista si fa un importante passo avanti con SuperFetch, uno schema di gestione della memoria che migliora l'approccio dell'accesso meno recente utilizzando le informazioni della cronologia e la gestione proattiva della memoria.

SuperFetch è implementato in %SystemRoot%\System32\Sysmain.dll come servizio Windows eseguito in un processo Host servizio (%SystemRoot%\System32\Svchost.exe). Lo schema si fonda sul supporto da parte di Memory Manager, in modo da recuperare la cronologia di utilizzo delle pagine oltre a dirigere Memory Manager nel precaricamento di dati e codice dai file sul disco oppure da un file di paging nell'elenco di standby per assegnare le priorità alle pagine. Il servizio SuperFetch estende il tracciamento anche alle pagine di dati e codice che erano presenti in precedenza in memoria, ma che Memory Manager ha riutilizzato per fare spazio per nuovi dati e nuovo codice. Queste informazioni vengono memorizzate in file di scenario con estensione .db nella directory %SystemRoot%\Prefetch, insieme ai file di prelettura standard utilizzati per ottimizzare l'avvio delle applicazioni. Sfruttando questa profonda conoscenza dell'utilizzo della memoria, SuperFetch è in grado di precaricare dati e codice quando diventa disponibile la memoria fisica.

Quando la memoria si libera, ad esempio quando un'applicazione viene chiusa o rilascia memoria, SuperFetch chiede a Memory Manager di recuperare i dati e il codice rimossi di recente. Questa operazione viene eseguita alla velocità di poche pagine al secondo con una priorità di I/O Molto bassa, in modo che il precaricamento non abbia un impatto sulle applicazioni attive dell'utente o di altra natura. Ne consegue che se si lascia il computer per andare a pranzo e un'attività in background che utilizza una grande quantità di memoria provoca la rimozione del codice e dei dati delle applicazioni attive dalla memoria, SuperFetch sarà spesso in grado di recuperare tutti o la maggior parte degli elementi rimossi in memoria prima del ritorno dell'utente. SuperFetch comprende inoltre il supporto dello scenario specifico per ibernazione, standby, Cambio rapido utente e avvio delle applicazioni. Quando il sistema entra in ibernazione, ad esempio, SuperFetch memorizza i dati e il codice nel file di ibernazione che (in base alle ibernazioni precedenti) prevede verrà utilizzato al ripristino successivo. Quando invece viene ripristinato Windows XP, i dati che vengono richiesti e che erano memorizzati in precedenza nella cache devono essere letti di nuovo dal disco.

Per una descrizione dell'impatto di SuperFetch sulla memoria disponibile, vedere il riquadro "Funzionamento di SuperFetch".

Funzionamento di SuperFetch

Dopo aver utilizzato per un po' di tempo un sistema Windows Vista, si noterà un valore basso nel contatore della memoria fisica disponibile nella pagina Prestazioni di Gestione attività. Questo accade perché SuperFetch e la cache standard di Windows utilizzano tutta la memoria fisica disponibile per memorizzare i dati del disco. Se si esegue Gestione attività subito dopo aver avviato il sistema, ad esempio, si noterà che il valore della memoria disponibile diminuisce con l'aumentare del valore della cache. In alternativa, se si esegue e poi si chiude un programma che utilizza una grande quantità di memoria (ad esempio, una qualunque applicazione freeware di "ottimizzazione della RAM" che alloca grandi quantità di memoria per poi rilasciarla) oppure si copia un file di grandi dimensioni, il valore della memoria disponibile aumenterà e il grafico Cronologia utilizzo memoria fisica segnerà un brusco calo perché il sistema reclama la memoria rilasciata. Con il passare del tempo, tuttavia, SuperFetch riempirà di nuovo la cache con i dati rimossi in modo forzato dalla memoria e il valore della cache tornerà a salire, con la conseguente riduzione del valore della memoria disponibile.

Memoria sotto osservazione

Memoria sotto osservazione(Fare clic sull'immagine per ingrandirla)

ReadyBoost

Le velocità di CPU e memoria stanno superando di gran lunga le velocità dei dischi rigidi, che rappresentano ormai un tipico collo di bottiglia per le prestazioni del sistema. L'I/O casuale dei dischi è molto dispendioso perché i tempi di ricerca delle testine dei dischi sono nell'ordine di 10 millisecondi, un'eternità per i processori a 3 GHz odierni. La RAM è una cache ideale per i dati del disco, ma è piuttosto costosa. La memoria flash, tuttavia, è in genere più economica e consente di eseguire letture casuali con una velocità fino a 10 volte maggiore rispetto a un disco rigido standard. In Windows Vista è disponibile la funzionalità ReadyBoost, che sfrutta i vantaggi dei dispositivi di archiviazione con memoria flash creando uno livello di cache intermedio che risiede logicamente tra memoria e dischi.

ReadyBoost consiste in un servizio implementato in %SystemRoot%\System32\Emdmgmt.dll che viene eseguito in un processo Host servizio e in un driver del filtro del volume, %SystemRoot%\System32\Drivers\Ecache.sys. Emd è l'acronimo di External Memory Device (dispositivo di memoria esterno), il nome attribuito a ReadyBoost nella fase di sviluppo. Quando si inserisce un dispositivo flash come una chiave USB in un sistema, il servizio ReadyBoost esamina il dispositivo per determinarne le prestazioni e memorizza i risultati del test in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, come in Figura 1.

Figura 1 Risultati del test del dispositivo di ReadyBoost nel Registro di sistema

Figura 1** Risultati del test del dispositivo di ReadyBoost nel Registro di sistema **(Fare clic sull'immagine per ingrandirla)

Se non si utilizza già un dispositivo per la cache e il nuovo dispositivo contiene tra 256 MB e 32 GB di dati, ha una velocità di trasferimento di 2,5 MB/s o maggiore per letture casuali di 4 KB e ha una velocità di trasferimento dei dati di 1,75 MB/s o maggiore per scritture casuali di 512 KB, ReadyBoost richiederà se si desidera dedicare fino a 4 GB alla cache del disco. ReadyBoost può utilizzare NTFS, ma limita le dimensioni massime della cache a 4 GB per compatibilità con le limitazioni del file system FAT32. Se si accetta, il servizio creerà un file di cache denominato Readyboost.sfcache nella directory radice del dispositivo e chiederà a SuperFetch di popolare preliminarmente la cache in background.

Dopo che il servizio ReadyBoost ha inizializzato la cache, il driver del dispositivo Ecache.sys intercetta tutte le letture e scritture dei dischi rigidi locali (C:\, ad esempio) e copia i dati in scrittura nel file di cache creato dal servizio. Ecache.sys comprime i dati raggiungendo in genere un rapporto di compressione di 2:1, in modo che il file di cache di 4 GB contenga fino a 8 GB di dati. Il driver crittografa ciascun blocco che scrive utilizzando lo standard AES (Advanced Encryption Standard) con una chiave di sessione generata casualmente a ogni avvio, per garantire la privacy dei dati memorizzati nella cache quando il dispositivo viene rimosso dal sistema.

Quando ReadyBoost rileva letture casuali che possono essere soddisfatte dalla cache, utilizza quest'ultima per l'operazione ma, poiché i dischi rigidi garantiscono prestazioni migliori rispetto alle memorie flash nelle letture sequenziali, consente alle letture che fanno parte di modelli sequenziali di accedere direttamente ai dischi, anche se i dati sono presenti nella cache.

ReadyBoot

Nel caso di un sistema con meno di 512 MB di memoria Windows Vista utilizza la stessa prelettura di avvio di Windows XP, ma se il sistema dispone di 700 MB o più di RAM, utilizza una cache sulla RAM per ottimizzare il processo di avvio. Le dimensioni della cache dipendono dalla RAM totale disponibile, ma sono sufficienti a creare una cache ragionevole e consentire al sistema di accedere alla memoria necessaria per un avvio rapido e senza problemi.

Dopo ogni avvio, il servizio ReadyBoost (lo stesso servizio che implementa la funzionalità ReadyBoost appena descritta) sfrutta il tempo di CPU inutilizzato per calcolare uno schema di memorizzazione nella cache per il prossimo avvio. Il servizio inoltre analizza le informazioni di tracciamento file dei cinque avvii precedenti e individua i file a cui è stato eseguito l'accesso e le rispettive posizioni su disco. Le tracce elaborate vengono memorizzate in %SystemRoot%\Prefetch\Readyboot come file .fx e lo schema di memorizzazione nella cache viene salvato sotto HKLM\System\CurrentControlSet\Services\Ecache\Parameters in valori REG_BINARY denominati in base ai volumi interni di riferimento.

La cache viene implementata dallo stesso driver di dispositivo che implementa la cache di ReadyBoost (Ecache.sys), ma il popolamento della cache è condotta dal servizio ReadyBoost all'avvio del sistema. Se la cache di avvio è compressa come la cache ReadyBoost, un'altra differenza tra ReadyBoost e la gestione della cache di ReadyBoot consiste nel fatto che in modalità ReadyBoot, diversa dagli aggiornamenti del servizio ReadyBoost, la cache non cambia in modo da riflettere i dati letti o scritti durante l'avvio. Il servizio ReadyBoost elimina la cache 90 secondi dopo l'inizio dell'avvio, oppure se altre richieste di memoria lo garantiscono, e registra le statistiche della cache in HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, come illustrato nella Figura 2. I test delle prestazioni di Microsoft hanno dimostrato che ReadyBoot consente di migliorare le prestazioni di circa il 20% rispetto alla funzione di prelettura di Windows XP.

Figura 2 Statistiche delle prestazioni di ReadyBoot

Figura 2** Statistiche delle prestazioni di ReadyBoot **(Fare clic sull'immagine per ingrandirla)

ReadyDrive

ReadyDrive è una funzionalità di Windows Vista che sfrutta i nuovi dischi rigidi ibridi denominati H-HDD. Un H-HDD è un disco con memoria flash incorporata non volatile (anche definita NVRAM). In genere in un H-HDD è integrata una cache da 50 MB a 512 MB, ma il limite della cache in Windows Vista è di 2 TB.

In Windows Vista vengono utilizzati i comandi ATA-8 per definire i dati del disco da archiviare nella memoria flash. I dati di avvio, ad esempio, vengono salvati nella cache all'arresto del sistema, consentendo un riavvio più rapido. Vengono inoltre memorizzati nella cache parti dei dati del file di ibernazione quando il sistema entra in ibernazione, in modo che il ripristino successivo sia più veloce. Poiché la cache resta attiva anche quando i piattelli del disco non ruotano, Windows può utilizzare la memoria flash come cache in scrittura sul disco, evitando di avviare la rotazione dei piattelli del disco quando il sistema è alimentato a batteria. Quando si lascia la rotazione del disco disattivata, si risparmia molta dell'energia consumata dall'unità disco in condizioni di uso normale.

Database della configurazione di avvio

Con Windows Vista sono stati migliorati alcuni aspetti dell'avvio e dell'arresto del sistema. Per l'avvio sono stati introdotti il database di configurazione di avvio (BCD) per la memorizzazione della configurazione di avvio di sistema e sistema operativo, nuovi flusso e organizzazione dei processi di avvio del sistema, una nuova architettura di accesso e il supporto per i servizi di avvio automatico ritardato. Le modifiche apportate alla procedura di arresto del sistema di Windows Vista includono la notifica di pre-arresto del sistema per i servizi Windows, l'ordinamento dell'arresto dei servizi Windows e una modifica significativa della modalità di gestione da parte del sistema operativo delle transizioni dello stato di alimentazione.

Una delle modifiche più evidenti del processo di avvio è l'assenza del file Boot.ini dalla radice del volume di sistema. Il file non è più necessario perché la configurazione dell'avvio, che nelle versioni precedenti di Windows era memorizzata nel file di testo Boot.ini, ora è memorizzata nel BCD. In Windows Vista si utilizza il BCD anche perché questo unifica le due architetture di avvio attualmente supportate da Windows: MBR (Master Boot Record) ed EFI (Extensible Firmware Interface). MBR viene in genere utilizzato da sistemi desktop x86 e x64, mentre EFI viene utilizzato da sistemi basati su Itanium (in un prossimo futuro anche i computer desktop potranno essere forniti con il supporto EFI). Il BCD estrae il firmware e ha altri vantaggi rispetto a Boot.ini, come il supporto per stringhe Unicode ed eseguibili di pre-avvio alternativi.

Il BCD viene memorizzato su disco in un hive del Registro di sistema che viene caricato nel Registro di sistema di Windows per l'accesso tramite API del Registro di sistema. Nei computer, Windows lo memorizza in \Boot\Bcd sul volume di sistema. Nei sistemi EFI, si trova sulla partizione di sistema EFI. Quando viene caricato, l'hive è riportato sotto HKLM\Bcd00000000, ma il formato interno non è documentato, quindi per la modifica è necessario uno strumento come %SystemRoot%\System32\Bcdedit.exe. Le interfacce per la manipolazione del BCD sono disponibili anche per script ed editor personalizzati tramite Strumentazione gestione Windows (WMI) ed è possibile utilizzare l'utilità di configurazione di sistema di Windows (%SystemRoot%\System32\Msconfig.exe) per modificare o aggiungere i parametri fondamentali, come le opzioni di debug del kernel.

Il BCD separa le impostazioni di avvio della piattaforma, come la selezione del sistema operativo predefinito e il timeout del menu di avvio, dalle impostazioni specifiche per il sistema operativo, come le opzioni di avvio e il percorso del caricatore di avvio del sistema operativo. Nella Figura 3, ad esempio, è illustrata l'esecuzione di Bcdedit senza opzioni della riga di comando, con le impostazioni di piattaforma nella sezione Windows Boot Manager all'inizio dell'output e le impostazioni specifiche del sistema operativo nella sezione successiva del caricatore di avvio di Windows.

Figura 3 Impostazioni visualizzate in BCDEdit

Figura 3** Impostazioni visualizzate in BCDEdit **(Fare clic sull'immagine per ingrandirla)

Quando si avvia un'installazione di Windows Vista, questo nuovo schema separa le attività che nelle versioni precedenti di Windows erano gestite dal caricatore del sistema operativo (Ntldr) in due eseguibili diversi: \BootMgr e %SystemRoot%\System32\Winload.exe. Bootmgr legge il BCD e mostra il menu di avvio del sistema operativo, mentre Winload.exe gestisce il caricamento del sistema operativo. Durante un avvio pulito, Winload.exe carica i driver di dispositivo di avvio del sistema e i file principali del sistema operativo, compreso Ntoskrnl.exe, e trasferisce il controllo al sistema operativo; durante il ripristino dall'ibernazione, viene quindi avviato %SystemRoot%\System32\Winresume.exe per il caricamento dei dati di ibernazione in memoria e il ripristino del sistema operativo.

Bootmgr prevede inoltre il supporto per eseguibili di pre-avvio aggiuntivi. Windows Vista viene fornito con Strumento di diagnostica memoria Windows (\Boot\Memtest.exe) già configurato come opzione per il controllo dell'integrità della RAM, ma terze parti possono aggiungere eseguibili di pre-avvio proprietari come opzioni da visualizzare nel menu di avvio di Bootmgr.

Processi di avvio

Nelle versioni precedenti di Windows il rapporto tra i vari processi del sistema non era intuitivo. All'avvio del sistema, ad esempio, il gestore di accesso interattivo (%SystemRoot%\System32\Winlogon.exe) avvia Local Security Authority Subsystem Service (Lsass.exe) e Gestione controllo servizi (Services.exe). Inoltre, Windows utilizza un contenitore di spazio dei nomi denominato Sessione per isolare i processi in esecuzione delle diverse sessioni di accesso. Prima di Windows Vista, l'utente accedeva alla sessione 0 condivisa della console, la sessione utilizzata dai processi di sistema, generando potenziali problemi di protezione. Un problema di questo tipo si verificava, ad esempio, quando un servizio Windows scritto con scarsa perizia eseguito nella sessione 0 mostrava un'interfaccia utente sulla console interattiva, consentendo al malware di attaccare la finestra tramite alcune tecniche volte ad acquisire i privilegi di amministrazione.

Per risolvere questi problemi, alcuni processi di sistema sono stati riprogettati per Windows Vista. La gestione delle sessioni (Smss.exe) è il primo processo in modalità utente creato durante l'avvio come nelle versioni precedenti di Windows, ma in Windows Vista ne viene avviata una seconda istanza per la configurazione della sessione 0, dedicata esclusivamente ai processi di sistema. Il processo di gestione delle sessioni per la sessione 0 avvia l'applicazione di avvio di Windows (Wininit.exe), un processo del sottosistema Windows (Csrss.exe) per la sessione 0, e viene quindi chiuso. L'applicazione di avvio di Windows continua avviando Gestione controllo servizi, Local Security Authority Subsystem e un nuovo processo, Gestione sessioni locali (Lsm.exe), che gestisce le connessioni Terminal Server per il computer.

Quando un utente accede al sistema, Gestione sessioni locali crea una nuova di se stesso per configurare la nuova sessione. Il nuovo processo Smss.exe avvia un processo del sottosistema Windows e il processo Winlogon per la nuova sessione. Il vantaggio costituito da un gestore delle sessioni principale che utilizza altre copie di se stesso per inizializzare nuove sessioni non viene percepito su un sistema client, ma sui sistemi Windows Server "Longhorn" utilizzati come Terminal Server, le copie multiple possono essere eseguite simultaneamente per consentire accessi più rapidi a più utenti.

Con questa nuova architettura i processi del sistema, compresi i servizi Windows, restano isolati nella sessione 0. Se un servizio Windows eseguito nella sessione 0 mostra un'interfaccia utente, il servizio Rilevamento servizi interattivi (%SystemRoot%\System32\UI0Detect.exe) notifica l'evento all'amministratore connesso avviando un'istanza di se stesso nel contesto di protezione dell'utente e mostrando il messaggio visualizzato nella Figura 4. Se l'utente sceglie il pulsante "Mostra messaggio", il servizio passa dal desktop al desktop del servizio Windows, in cui l'utente può interagire con l'interfaccia utente del servizio e tornare quindi al proprio desktop. Per ulteriori informazioni su quanto avviene all'avvio, vedere il riquadro "Visualizzazione delle relazioni tra i processi di avvio".

Figura 4 Finestra mostrata dal servizio

Figura 4** Finestra mostrata dal servizio **(Fare clic sull'immagine per ingrandirla)

Visualizzazione delle relazioni tra i processi di avvio

È possibile utilizzare Process Explorer di Sysinternals (microsoft.com/technet/sysinternals) (in inglese) per visualizzare la struttura di avvio dei processi di Windows Vista.

Nella schermata riportata di seguito è riportata la colonna Session, che può essere aggiunta tramite la finestra di dialogo delle colonne di Process Explorer. Il processo evidenziato è l'Smss.exe iniziale. Di seguito sono elencati i processi Csrss.exe e Wininit.exe della sessione 0, allineati a sinistra perché il processo padre, ovvero l'istanza di Smss.exe che ha configurato la sessione 0, è stato chiuso. I tre processi figlio di Wininit sono Services.exe, Lsass.exe e Lsm.exe.

Process Explorer identifica una serie di processi come in esecuzione nella sessione 1, ovvero nella sessione a cui si è connesso l'utente tramite desktop remoto. In Process Explorer i processi in esecuzione nello stesso account vengono inoltre evidenziati in blu. Infine, la sessione 2 è stata inizializzata in modo da preparare l'accesso di un utente alla console e la creazione di una nuova sessione di accesso. È questa la sessione in cui è in esecuzione Winlogon che utilizza LogonUI per richiedere al nuovo utente della console "Per eseguire l'accesso, premere CTRL + ALT + CANC" e in cui Logonui.exe richiederà le credenziali all'utente.

Informazioni su processi e sessioni di avvio

Informazioni su processi e sessioni di avvio(Fare clic sull'immagine per ingrandirla)

Provider di credenziali

In Windows Vista è stata modificata anche l'architettura di accesso. Nelle versioni precedenti di Windows il processo Winlogon caricava la DLL per l'identificazione e l'autenticazione grafiche (GINA) specificata nel Registro di sistema, che consentiva di visualizzare un'interfaccia utente di accesso in cui venivano richieste le credenziali agli utenti. Il modello della DLL GINA era purtroppo caratterizzato da alcune limitazioni, tra cui la possibilità di configurare una sola GINA, l'eccessiva complessità di scrittura di una GINA per le terze parti e le GINA personalizzate con interfacce utente non standard che inficiavano l'usabilità di Windows.

In Windows Vista viene utilizzato, in luogo di una GINA, la nuova architettura del provider di credenziali. Winlogon avvia un nuovo processo (Logonui.exe), che carica i provider di credenziali configurati in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui può supportare simultaneamente più provider di credenziali; infatti, Windows Vista viene fornito con i provider interattivo (Authui.dll) e smartcard (Smart-cardcredentialprovider.dll). Per garantire prestazioni uniformi dal punto di vista dell'utente, LogonUI gestisce l'interfaccia utente visualizzata dagli utenti finali, ma consente ai provider di credenziali di specificare elementi personalizzati come testo, icone e controlli di modifica.

Servizi di avvio automatico ritardato

Se si è eseguito qualche volta l'accesso a un sistema Windows subito dopo l'avvio, si sono di certo notati dei ritardi prima che venga configurato il desktop e che sia possibile interagire con la shell e con qualsiasi applicazione avviata. Durante l'accesso, Gestione controllo servizi avvia i numerosi servizi Windows configurati come servizi ad avvio automatico e che si attivano quindi al momento dell'avvio. Molti servizi eseguono inizializzazioni che sfruttano a fondo le risorse di CPU e disco, in competizione con le attività di accesso. Per risolvere i conflitti, in Windows Vista è stato aggiunto un nuovo tipo di avvio dei servizi, definito avvio automatico ritardato, che i servizi possono utilizzare quando non devono attivarsi subito dopo l'avvio di Windows.

Gestione controllo servizi avvia i servizi configurati per l'avvio automatico ritardato al termine dell'avvio dei servizi ad avvio automatico e imposta la priorità dei rispettivi thread iniziali su THREAD_PRIORITY_LOWEST. Ne consegue che a tutte le operazioni di I/O da disco eseguite dal thread viene assegnata la priorità di I/O Molto Bassa. Al termine dell'inizializzazione, Gestione controllo servizi imposta la priorità normale del servizio. La combinazione di avvio ritardato, bassa priorità di CPU e memoria e priorità in background del disco riduce di molto l'interferenza con l'accesso dell'utente. Molti servizi Windows, compresi Servizio trasferimento intelligente in background, Client di Windows Update e Windows Media® Center, utilizzano il nuovo tipo di avvio per migliorare le prestazioni degli accessi dopo un avvio.

Arresto del sistema

Un problema che ha sempre afflitto gli scrittori di servizi Windows è il limite predefinito di venti secondi per eseguire la pulizia durante l'arresto del sistema. Le versioni di Windows prima di Vista non supportavano un arresto pulito del sistema che restasse in attesa della chiusura di tutti i servizi, perché un servizio con errori di programmazione poteva ritardare indefinitamente l'arresto del sistema. Alcuni servizi, come quelli che prevedono operazioni di arresto del sistema correlate alla rete o il salvataggio di grandi quantità di dati su disco, potrebbero richiedere più tempo. Windows Vista consente a questo genere di servizi di richiedere una notifica di pre-arresto del sistema.

Quando Windows Vista viene arrestato, Gestione controllo servizi notifica in anticipo la chiusura ai servizi che richiedono una notifica di pre-arresto del sistema, quindi resterà indefinitamente in attesa che questi servizi vengano chiusi. Se tuttavia i servizi non rispondono alle query a causa di qualche errore di programmazione, Gestione controllo servizi procede all'arresto del sistema dopo altri tre minuti. Una volta chiusi tutti i servizi oppure al termine del timeout, Gestione controllo servizi procede con la chiusura degli altri servizi secondo le procedure standard. Criteri di gruppo e i servizi Windows Update registrano la notifica di pre-arresto del sistema in una nuova installazione di Windows Vista e

utilizzano, inoltre, un'altra funzionalità per i servizi di Windows Vista: l'ordinamento dell'arresto dei servizi Windows. I servizi sono sempre stati in grado di specificare le dipendenze di avvio che Gestione controllo servizi rispetta per avviare i servizi in un ordine soddisfacente, ma prima di Windows Vista non erano in grado di specificare le dipendenze di arresto del sistema. Ora i servizi registrati per la notifica di pre-arresto del sistema possono anche inserirsi nell'elenco memorizzato in HKLM\System\CurrentControlSet\Control\PreshutdownOrder e Gestione controllo servizi li chiuderà secondo l'ordine specificato. Per ulteriori informazioni su questi servizi, vedere il riquadro "Identificazione di un servizio di avvio automatico ritardato e di pre-arresto del sistema".

Risparmio di energia

Sospensione e ibernazione sono altre forme di arresto del sistema e le funzioni di risparmio di energia di scarsa qualità di driver e applicazioni sono sempre stati un problema per gli utenti mobili, fin da quando con Windows 2000 fu introdotto il risparmio di energia nella gamma di sistemi operativi basati su Windows NT®. Gli utenti si aspettavano che il sistema portatile entrasse in sospensione o ibernazione dopo la chiusura del coperchio del computer prima della partenza, ma una volta giunti a scoprivano di avere una borsa rovente, una batteria scarica e dei dati persi. Questi problemi si verificavano perché Windows ha sempre chiesto ai driver dei dispositivi e alle applicazioni l'autorizzazione per la modifica dello stato di alimentazione e un singolo driver o applicazione non standard impediva la transizione.

In Windows Vista il gestore dell'alimentazione del kernel informa ancora driver e applicazioni delle modifiche dello stato di alimentazione, in modo da preparare la transizione, ma non chiede più l'autorizzazione. Inoltre, il gestore dell'alimentazione resta in attesa di una risposta alle notifiche di modifica per un massimo di 20 secondi, invece dei due minuti delle versioni precedenti di Windows. Di conseguenza gli utenti di Windows Vista possono contare su funzioni di sospensione e ibernazione più affidabili.

Nella prossima puntata

Come anticipato, questa è la seconda parte di una serie in tre parti. Nella prima parte sono stati illustrati i miglioramenti apportati al kernel di Windows Vista nelle aree di I/O e processi. In questo articolo sono stati esaminati i miglioramenti di Windows Vista nei settori della gestione della memoria, dell'avvio e dell'arresto del sistema. Nell'ultima parte della serie si descriveranno le modifiche apportate al kernel nelle aree di affidabilità e protezione.

Identificazione di un servizio di avvio automatico ritardato e di pre-arresto del sistema

Il comando SC integrato è stato aggiornato in Windows Vista in modo da mostrare i servizi configurati come servizi di avvio automatico ritardato:

Utilizzo di SC per la visualizzazione del tipo di avvio

Utilizzo di SC per la visualizzazione del tipo di avvio(Fare clic sull'immagine per ingrandirla)

Il comando SC, purtroppo, non fornisce informazioni sui servizi che hanno richiesto la notifica di pre-arresto del sistema, ma per verificare se un servizio ha accettato la notifica di pre-arresto del sistema è possibile impiegare l'utilità PsService di Sysinternals:

Visualizzazione dello stato di pre-arresto del sistema

Visualizzazione dello stato di pre-arresto del sistema(Fare clic sull'immagine per ingrandirla)

Mark Russinovich è un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) (in inglese) e spesso partecipa come oratore a conferenze su IT e sviluppo. Si è unito a Microsoft con la recente acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato le utilità Process Explorer, Filemon e Regmon.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.