Condividi tramite

  • Articolo

[Archivio newsletter ^] [< Volume 3, Numero 2] [Volume 4, Numero 2 >]

Newsletter Systems Internals Volume 4, Numero 1

http://www.sysinternals.com
Copyright (C) 2002 Mark Russinovich

7 gennaio 2002 - In questo numero:

  1. EDITORIALE

  2. NOVITÀ DI SYSINTERNALS

    • Sync v2.1
    • DiskExt v1.0
    • NTFSDOS v3.02
    • PsSuspend v1.2
    • PsLogList v2.2
    • PsInfo v1.2
    • PsExec v1.3
    • BgInfo v2.0
    • Process Explorer v5.2
    • Filemon v4.34 per Win64/Itanium
    • Filemon v1.1 per Linux
    • Sysinternals in Microsoft

  3. INFORMAZIONI SU INTERNALS

    • Inside Windows 2000, il DVD interattivo
    • Inside Windows 2000/XP: il seminario
    • File manifesto di Windows XP
    • Che cosa c'è in una X-Box?
    • Statistiche casuali di Windows XP
    • Nuovo windbg migliorato

  4. SVILUPPI FUTURI

    • Uso di BootVis per profilare il processo di avvio di Windows XP

SPONSOR: WINTERNALS SOFTWARE

La newsletter Sysinternals è sponsorizzata da Winternals Software, disponibile sul Web all'indirizzo http://www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K/XP. I loro prodotti includono il pluripremiato Administrator's Pak, ERD Commander 2000 e NTFSDOS Professional Edition.

Winternals è orgogliosa di annunciare Defrag Commander versione 1.32, l'utilità di deframmentazione aziendale più veloce e completa disponibile. È ora possibile gestire le pianificazioni della deframmentazione nell'intera azienda Windows da un semplice snap-in MMC, senza dover installare alcun software client nei sistemi NT o Windows 2000. Una licenza per 10 sistemi è disponibile per l'acquisto online a soli $ 169 e sono disponibili sconti per grandi quantità. Visitare http://www.winternals.com/39 per altre informazioni o per il download e l'uso gratuito per 30 giorni.

Ciao a tutti.

Newsletter di Sysinternals. La newsletter conta attualmente 34,000 abbonati. Inoltrate la newsletter ai vostri amici che pensate potrebbero essere interessati a questi contenuti.

Windows XP, il sistema operativo di punta di Microsoft, è diventato "gold" alla fine di agosto. Windows XP è l'ultima versione della linea Windows NT, iniziata con Windows NT 3.1 nel 1993, e si basa sulle evoluzioni e sulle innovazioni tecnologiche degli ultimi otto anni. Il sistema operativo rappresenta sicuramente l'avanguardia in termini di funzionalità e caratteristiche, molte delle quali sono state studiate e descritte da David Solomon e da me nell'articolo di dicembre di MSDN Magazine "Windows XP: I miglioramenti del kernel creano un sistema operativo più solido, efficiente e scalabile" (http://www.msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/XPKernel.asp).

Con milioni di sistemi Windows NT e Windows 2000 installati e centinaia di migliaia o milioni di beta tester, ci si aspetta che Microsoft abbia perfezionato, messo a punto e corretto Windows XP per farlo funzionare in modo praticamente impeccabile. Dopotutto, i loro annunci pubblicizzano XP come "virtualmente a prova di crash". Certamente non mi aspettavo di avere problemi, ma mi sbagliavo.

Ho tenuto Windows 2000 Professional come sistema operativo nel mio sistema primario per tutto il ciclo beta e Release Candidate di XP. Avevo imparato dal ciclo di sviluppo di Windows 2000 che anche le Release Candidate lasciano residui di debug dopo l'aggiornamento ai bit finali. Quando ho ricevuto la build 2600, la versione finale, dal programma beta, ho deciso che era giunto il momento di cambiare. La procedura guidata di compatibilità con XP ha riscontrato solo problemi minori sul mio sistema Windows 2000 (ad esempio, la versione di Partition Magic che avevo installato non comprendeva XP NTFS), quindi ho proceduto con l'aggiornamento.

Dopo l'esecuzione in modalità testo e l'installazione dei file di configurazione nel disco rigido, il programma di installazione di XP si è riavviato nella mia installazione di Windows XP parzialmente aggiornata per completare l'aggiornamento in modalità grafica. In questa modalità si specificano le impostazioni locali e del fuso orario, il programma di installazione esegue il rilevamento dei dispositivi e si configura la rete. È andato tutto bene fino alla fase "Installazione dei dispositivi". Quando l'indicatore di stato ha raggiunto circa i 2/3 e il programma di installazione ha segnalato che il tempo rimanente era di 34 minuti, il programma di installazione ha smesso di essere produttivo. I banner "XP è la cosa migliore che ti sia mai capitata" continuavano ad alternarsi e i piccoli pulsanti lampeggianti in basso a destra continuavano a ruotare, ma anche dopo due ore mi mancavano ancora 34 minuti.

Allora ho cominciato a preoccuparmi. Diverse ore di tentativi frenetici per superare il problema, inclusi il riavvio per consentire al programma di installazione di riprovare, l'aggiornamento del BIOS, il controllo della Knowledge Base di MS (niente), non hanno prodotto alcun risultato. Alla fine mi sono arreso, ho eliminato l'installazione di metà Windows 2000 e metà Windows XP e ho eseguito una nuova installazione di XP, passando la maggior parte della giornata a reinstallare le due decine di applicazioni che uso.

Le cose con la mia nuova installazione XP andavano bene. Non voglio dire che non sia stato deluso da inspiegabili arresti anomali del sistema, malfunzionamenti dell'interfaccia utente grafica e altri strani comportamenti del sistema, ma almeno ho potuto essere produttivo. Sapevo che il CD del programma beta era un CD di prova e che avrei dovuto effettuare l'aggiornamento alla versione completa quando l'avrei ricevuto tramite MSDN, ma mi aspettavo che non ci fossero problemi.

Esattamente 120 giorni dopo il mio aggiornamento interrotto (il timeout, non a caso, di una versione di prova) ho provato un incredibile senso di déjà vu. L'aggiornamento dalla versione di prova a quella completa si comporta effettivamente come un aggiornamento completo e (avete indovinato) a 34 minuti dalla fine e a 2/3 del percorso in "Installazione dei dispositivi" il programma di installazione ha smesso di avanzare. Ancora una volta, il mio sistema si trovava nel bel mezzo del limbo dell'installazione, totalmente inutilizzabile. Dopo aver fatto tutti i medesimi tentativi di 120 giorni prima, mi sono rassegnato a eseguire un'altra reinstallazione completa.

Poi ho riscontrato un altro problema: il CD di XP di MSDN non è di avvio, perché ha entrambe le sottodirectory Home e Professional. Poiché ho un'unica installazione del sistema operativo (quella danneggiata dal programma di installazione), non ho potuto eseguire la versione Win32 del programma di installazione dal CD di MSDN e, poiché il mio sistema è solo NTFS, non ho potuto eseguire il programma di installazione in DOS. Il CD non consente nemmeno di creare dei floppy di avvio del programma di installazione. Mi sono ricordato che tra i download per gli abbonati MSDN c'è un'immagine ISO di Windows XP Professional, quindi sono andato a scaricarla (usando un altro sistema) per masterizzare un CD di avvio, ma questa linea di attacco è stata vanificata da un messaggio di errore simile a "Errore nell'avvio di File Transfer Manager. Riprovare più tardi." dal sito di MSDN.

Come ho fatto a tirarmi fuori da questo pasticcio? Ho sostituito gli hive del Registro di sistema dell'aggiornamento interrotto con quelli di un backup che avevo fatto qualche settimana fa. Sebbene non sia stato possibile accedere al sistema dopo un riavvio perché l'Attivazione di un prodotto di Windows diceva che non poteva verificare la mia licenza, ho potuto avviare in modalità provvisoria ed eseguire il programma di installazione del CD di MSDN da lì. Ho appena finito di reinstallare le mie applicazioni e sono nuovamente produttivo.

Quello che trovo assolutamente sorprendente di quanto mi è successo (due volte) è che il programma di installazione di Windows XP non ha i meccanismi di sicurezza di base che erano presenti nei programmi di installazione di Windows 9x fin da Windows 95. Quando il programma di installazione di Windows 95, 98 o Me viene eseguito, registra su disco i punti di avanzamento. Se il programma di installazione viene interrotto inaspettatamente, viene riavviato dal punto in cui si era fermato e, se si trovava nella fase "Installazione dei dispositivi", salta l'ultimo driver che aveva eseguito prima di essere interrotto. In questo modo, se il programma di installazione si blocca, è possibile riavviare il sistema e il programma di installazione procederà oltre il punto di blocco.

Windows 2000 e XP hanno preso in prestito una serie di funzionalità interessanti dalla linea Windows 9x, ad esempio la modalità provvisoria e il ripristino di sistema. Vorrei che avessero preso in prestito alcune cose dal programma di installazione di Windows 9x.

A proposito di aggiornamento a XP, il giornalista umoristico Dave Barry sta pensando di fare il salto: http://www.miami.com/herald/special/features/barry/2002/docs/jan06.htm.

Grazie.

- Mark

NOVITÀ DI SYSINTERNALS

SYNC V2.1

"Sync", un'applet che scarica su disco i dati memorizzati nella cache, è un'utilità fondamentale dei sistemi Unix e sono stato io a scrivere Sync per Windows NT/2000/XP diversi anni fa. Assicurarsi che le modifiche vengano rispecchiate nei supporti rimovibili di lettura/scrittura prima di espellere il supporto è una delle cose che Sync consente di fare. È anche utile per ridurre al minimo il danneggiamento del disco quando lo si esegue prima di esercitare un driver in fase di sviluppo che potrebbe arrestare il sistema in modo anomalo. Recentemente qualcuno ha suggerito che sarebbe bello se Sync avesse un'opzione per espellere i supporti dopo lo scaricamento, quindi questa opzione è stata introdotta nella versione 2.1.

Sync v2.1 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/source/misc.shtml

DISKEXT V1.0

Un altro strumento relativo ai dischi di cui si parla in questa newsletter è DiskExt, un'applet da riga di comando che indica, data la lettera di unità di un volume, le posizioni delle partizioni che costituiscono il volume. I volumi con più partizioni includono i volumi con spanning, mirroring e striping. DiskExt segnala anche la posizione, in termini di settori occupati, delle partizioni elencate.

DiskExt v1.0 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/source/misc.shtml#diskext

NTFSDOS V3.02

NTFSDOS, l'utilità che ha lanciato Sysinternals (all'epoca del rilascio di NTFSDOS, "Ntinternals") sui computer di centinaia di migliaia di utenti, consente al DOS di leggere le unità NTFS. Una piccola modifica alla struttura NTFS del disco di Windows XP ha richiesto una variazione di NTFSDOS per la compatibilità con XP.

NTFSDOS v3.02 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/NTFSDOS.shtml

PSSUSPEND V1.2

Vi è mai capitato di voler sospendere temporaneamente un download di rete, una ricerca su disco o un'altra applicazione a elevato utilizzo di risorse per poter eseguire qualcos'altro? La sospensione è una funzionalità di gestione dei processi, di cui si sentiva molto la mancanza negli strumenti di amministrazione in Windows NT/2000/XP. L'aggiunta più recente al set di strumenti PsTools è PsSuspend, un'utilità che sospende e riprende i processi. Come tutti gli altri strumenti della suite PsTools, PsSuspend è uno strumento da riga di comando che è possibile indirizzare al sistema locale o a uno remoto.

Poiché in Windows NT/2000/XP non esiste una funzionalità di sospensione dei processi (in XP sì, ma non è esposta tramite l'API Win32), PsSuspend sospende e riprende i thread in esecuzione in un processo di destinazione con le API Win32 SuspendThread e ResumeThread.

PsSuspend v1.2 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/pssuspend.shtml
L'intero pacchetto PsTools è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSLOGLIST V2.2

Gli strumenti che compongono il pacchetto PsTools si evolvono continuamente in base al feedback degli utenti e PsLoglist ha generato più richieste di funzionalità di qualsiasi altra utilità. Quest'ultima versione introduce una serie di miglioramenti, tra cui la possibilità di eseguire il dump dei record nei file di log degli eventi salvati, di cambiare il delimitatore del formato a riga singola da una virgola a qualcos'altro (per le situazioni in cui il testo del log degli eventi contiene virgole), di eseguire il dump dei record da intervalli di date specificati e di filtrare in base al tipo di evento (errore, avviso o informazione). Come prima, PsLoglist può eseguire il dump dei log eventi di sistema locali o remoti e include molte altre opzioni per il controllare il proprio funzionamento.

PsLoglist v2.2 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/psloglist.shtml
L'intero pacchetto PsTools è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSINFO V1.2

Un'utilità di PsTools che è stata ritirata è PsUptime, un'applet che indicava per quanto tempo il sistema locale o remoto era stato attivo. Non che queste informazioni non siano utili, anzi lo sono, ma sono più adatte a essere visualizzate dal nuovo arrivato in PsTools, PsInfo. Pertanto, PsInfo v1.2 riporta ora il tempo di attività del sistema, insieme a una serie di altre informazioni, come la versione del sistema operativo, la velocità del processore, la dimensione della memoria, le installazioni di hotfix, se un sistema operativo è in versione di prova e quando scadrà e, in Windows XP, lo stato di attivazione del prodotto Windows.

PsInfo v1.2 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/psinfo.shtml
L'intero pacchetto PsTools è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSEXEC V1.3

PsExec è un'utilità da riga di comando che consente di eseguire programmi su un sistema remoto senza installare alcun software in tale sistema. Se il programma che eseguite ha un'interfaccia da riga di comando, PsExec lo sostituisce per voi, consentendovi di eseguirlo in modo interattivo come se stesse eseguendo il programma localmente. Queste funzionalità fanno di PsExec un'utilità remota comoda e leggera di tipo shell e facilitano l'abilitazione remota di strumenti da riga di comando come ipconfig.

La versione 1.3 di PsExec consente di avviare applicazioni Windows (a differenza di quelle da riga di comando) su un sistema remoto in modo che vengano visualizzate sul desktop interattivo. Non so dove possa essere utile, ma ho ricevuto diverse richieste per questa funzionalità.

PsExec v1.3 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/psexec.shtml
L'intero pacchetto PsTools è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

BGINFO V2.0

Se gestite più di qualche sistema, conoscete la "confusione dei sistemi", quello stato d'animo in cui vi avvicinate a un computer (o passate a esso con KVM) e dimenticate il nome del computer, la versione del sistema operativo, il Service Pack installato o l'indirizzo IP. Sebbene tutte queste informazioni siano accessibili attraverso varie interfacce amministrative, ottenerle può richiedere molto tempo. È qui che entra in gioco BgInfo di Bryce Cogswell: visualizza le informazioni di sistema più importanti sullo sfondo del desktop, in modo da avere immediatamente a disposizione tutte le informazioni necessarie.

Quest'ultimo aggiornamento di BgInfo lo rende più configurabile che mai. È possibile definire un testo personalizzato in una chiave del Registro di sistema, specificare il colore o la bitmap per lo sfondo del desktop, individuare il testo sullo sfondo e altro ancora. La cosa più utile per le grandi organizzazioni, tuttavia, è la capacità di BgInfo di salvare e caricare le impostazioni e persino di esportarle in un database. Usando una di queste funzionalità è possibile definire le impostazioni una volta sola e poi usarle in tutti i sistemi gestiti.

BgInfo v2.0 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/bginfo.shtml

PROCESS EXPLORER V5.2

Process Explorer è un visualizzatore di processi e un'utilità di controllo che riprende da dove Gestione attività si interrompe. Tra le sue numerose funzionalità, Process Explorer mostra l'albero di creazione dei processi, visualizza gli handle che i processi hanno aperto, elenca le DLL che i processi hanno caricato e consente di cercare il processo o i processi che hanno un determinato file aperto.

Le versioni precedenti di Process Explorer hanno funzionato sia in sistemi Windows 9x che NT/2K/XP, ma solo con la versione 5.2 Process Explorer mostra le informazioni sull'utilizzo della CPU dei processi per i sistemi Windows 9x. Un altro miglioramento per la versione 5.2 consente di rilevare le perdite nei sistemi Windows XP e 2000 segnalando il numero di handle GDI e USER (handle alle risorse dell'interfaccia utente win32) che un processo ha aperto nella finestra di dialogo delle proprietà del processo. Contrariamente a quanto si crede, anche in Windows 2000 e XP il numero di tali risorse è limitato: c'è un limite a livello di sistema di 65.536 handle USER e un limite per processo di 16.384 handle GDI.

Process Explorer v5.2 è disponibile per il download all'indirizzo
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

FILEMON V4.34 PER WIN64/ITANIUM

Microsoft mi ha gentilmente prestato un primo dispositivo Itanium di Intel per consentirmi di iniziare la conversione delle applicazioni Sysinternals più popolari a Win64/Itanium. Il dispositivo è impressionante: ha 2 processori da 733 MHz e 8 GB di memoria. Ho deciso per Filemon come prima applicazione da convertire. Filemon è costituito da un'interfaccia utente grafica Win32 (ora Win32/64) e da un driver di dispositivo, per cui sono stati necessarie due diverse operazioni di conversione. Ciò che non ci si aspetterebbe è che è possibile creare sia applicazioni Win64 che driver a 64 bit in un sistema a 32 bit che esegue Windows NT, 2000 o XP usando un compilatore incrociato.

Le ultime versioni dell'SDK della piattaforma (scaricabile gratuitamente da Microsoft: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/) includono sottodirectory contenenti il compilatore e il linker Itanium a 64 bit, file di intestazione Win64 e librerie Win64. Ho creato questo semplice file batch per impostare il mio ambiente per la creazione di eseguibili Win64:

@echo off
set PATH=D:\Mssdk\Bin\win64;%PATH%
set INCLUDE=D:\Mssdk\include\win64;D:\Mssdk\include\win64\crt
set LIB=D:\Mssdk\lib\ia64
echo 64-bit environment set.

Si noti che non è possibile creare applicazioni Win64 da Visual Studio, ma è necessario farlo dalla riga di comando.

Alcuni problemi di cast minori sono stati gli unici che ho incontrato durante la compilazione. Poi, ho creato il driver. Le ultime versioni del DDK (non più disponibili come download gratuito) includono scelte rapide da tastiera per i prompt dei comandi con l'ambiente di compilazione del driver IA64 configurato. È sufficiente compilare il driver nell'ambiente di destinazione a 64 bit come si farebbe con un driver a 32 bit.

Il compilatore mi ha informato che dovevo essere più esplicito su alcuni cast. Ad esempio, i numeri di sequenza che Filemon assegna alle operazioni sono ULONG, che il compilatore non mi ha permesso di trasmettere a un PVOID da passare come parametro di contesto alla funzione IoSetCompletionRoutine di I/O Manager. Al contrario, ho dovuto trasmetterlo prima a ULONG_PTR e quindi a PVOID. In ogni caso, in pochi minuti il driver è stato compilato senza errori.

Poi ho copiato l'applicazione e il driver a 64 bit nel sistema Itanium e l'ho eseguito. L'interfaccia utente grafica di Filemon è stata visualizzata e poi è scomparsa. Questo significa che ho dovuto usare il debugger Win64 per capire che cosa non andasse. Anche il debugger Win64 è incluso nell'SDK della piattaforma e può essere eseguito da un computer a 32 o 64 bit. Assomiglia a un debugger ridotto di Visual Studio e funziona solo in modalità remota, in cui si installa un client di debug nel computer di destinazione in cui si esegue l'applicazione.

Dopo aver analizzato il codice di Filemon per circa mezz'ora, ho finalmente capito che le mie procedure di Windows dovevano dichiarare i loro parametri lparam come LPARAM: erano stati LONG a causa di un codice copiato dall'SDK quando abbiamo scritto la prima versione di Filemon nel 1996. È interessante notare che il compilatore non si era mai lamentato di questo, ma ciò significava che qualsiasi puntatore passato come lparam veniva troncato. Il problema si è presentato nel gestore WM_MEASUREITEM di Filemon, che interpreta il parametro lparam come un puntatore a una struttura. Filemon ha registrato un errore in quel codice. Incredibilmente, dopo aver risolto quel problema, Filemon veniva eseguito senza intoppi su Itanium. Tempo totale per la conversione: 1 ora.

Ora sto lavorando alla conversione di Regmon, poi passerò a quella di DebugView. Dovrebbero essere entrambe impegnative, soprattutto quella di DebugView, che ha un driver davvero poco ortodosso.

Filemon con il codice sorgente completo è disponibile per il download all'indirizzo http://www.sysinternals.com/ntw2k/source/filemon.shtml

FILEMON V1.1 PER LINUX

Se avete visitato Sysinternals negli ultimi due mesi, probabilmente sarete rimasti scioccati nel vedere una nuova voce nella barra dei menu: Linux Utilities. Proprio così, ho deciso che sarebbe stato bello avere Filemon in esecuzione in Linux. Avevo già usato l'ambiente RAD (Rapid Application Development) Delphi di Borland in Windows, quindi quando è stato rilasciato Kylix (in pratica, Delphi per Linux), ho capito che l'interfaccia utente grafica sarebbe stata piuttosto semplice.

La domanda ancora aperta era come intercettare l'attività del file system. La maggior parte delle versioni di Unix, incluso Linux, implementa una chiamata di sistema denominata ptrace() che consente a un processo di intercettare tutte le chiamate di sistema effettuate da un processo di destinazione. Ho preso in considerazione l'uso di ptrace() per monitorare l'attività del file system e potrei modificare Filemon in futuro per usarlo per ragioni che diventeranno chiare, ma ho deciso di non farlo.

Lo svantaggio di usare ptrace() è che Filemon dovrebbe enumerare tutti i processi in esecuzione ed eseguire ptrace() su ognuno di essi. Inoltre, dovrebbe collegarsi anche ai processi appena creati e la funzionalità ptrace() non consente di garantire che le prime chiamate di sistema eseguite dal nuovo processo non vengano perse. Quando un processo che viene tracciato esegue una chiamata di sistema, il sistema operativo lo blocca, invia un segnale al processo di traccia e attende che quest'ultimo lasci continuare il processo. Ciò può causare un grave calo delle prestazioni se si vogliono visualizzare tutte le attività del file system. Infine, lo svantaggio maggiore è che ptrace() modifica il comportamento dei processi tracciati. Mentre vengono tracciati, l'utilità di traccia è il processo padre, il che significa che il vero padre di un processo tracciato non vedrà le notifiche che normalmente vedrebbe quando i processi figlio le causano.

Sarebbe stato bello se avessi potuto scrivere un driver di filtro per il file system (un driver raggruppabile, secondo la terminologia di Linux) come quello supportato da I/O Manager in Windows NT/2000/XP, ma l'attuale architettura del file system di Linux non supporta driver raggruppabili per il file system. Esiste una patch chiamata FiST che si può applicare per supportarla (http://www.cs.columbia.edu/~ezk/research/fist/) ed esiste anche un toolkit di tracciamento (http://www.opersys.com/LTT/index.html) per Linux, ma entrambi richiedono che gli utenti finali ricompilino i kernel, cosa che volevo evitare. Ho quindi deciso di implementare il monitoraggio usando un driver di hook delle chiamate di sistema, proprio come Regmon in Windows.

Ci sono due aspetti che hanno reso il progetto più difficile rispetto alla realizzazione della stessa cosa in Windows. Il primo è che Linus Torvalds, il padre di Linux e direttore dello sviluppo del kernel Linux, non crede nell'uso dei debugger del kernel. I motivi sono piuttosto ridicoli (vedere http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.htm per leggere la spiegazione di Linus stesso) ed è uno dei tanti motivi per cui il kernel Linux avrà difficoltà a tenere il passo con Windows. Esistono un paio di debugger del kernel non ufficiali, ma richiedono una patch del kernel e un certo sforzo per essere usati. Il secondo aspetto è che Linus non crede nel garantire la compatibilità con le versioni precedenti dei driver di dispositivo quando vengono rilasciati nuovi kernel. La conseguenza è che qualsiasi API esportata dal kernel può cambiare improvvisamente, interrompendo i driver esistenti che usano l'API e obbligando a ricompilarli per i nuovi kernel.

La mancanza di un debugger predefinito del kernel mi ha portato a eseguire il debug tramite istruzioni print di debug (ho pensato che avrei passato tanto tempo a eseguire il debug tramite printk, stampe in modalità kernel, quanto a installare e studiare un debugger del kernel) e le mutevoli API e strutture di dati del kernel significano che Filemon per Linux dipende dal kernel. Funziona in Red Hat 7.1 e 7.2 e SuSE Linux 7.1 e 7.2 con shrink-wrap e forse anche in altre distribuzioni commerciali, ma non ho ancora trovato un modo per isolare il driver da modifiche arbitrarie del kernel (una di queste, che ha danneggiato una prima versione del driver, è stata la modifica della convenzione di chiamata di una funzione del kernel da standard a rapida).

Filemon per Linux ha la stessa identica interfaccia della sua controparte per Windows e ha un aspetto molto simile (vedere lo screenshot nella pagina di Filemon per Linux). Le mie conclusioni sulla facilità di sviluppare un filtro generale per file system non dipendente dal kernel per Linux dovrebbero essere chiare: è difficile, se non impossibile. Al contrario, i driver raggruppabili (filtro) in ogni dominio di driver (rete, file system, archiviazione, input e così via) sono stati supportati dall'architettura I/O di Windows NT fin dall'inizio.

Filemon per Linux è disponibile per il download all'indirizzo http://www.sysinternals.com/linux/utilities/filemon.shtml

SYSINTERNALS AT WWW.MICROSOFT.COM

Ecco ancora una volta la versione più recente dei riferimenti di Sysinternals negli articoli della Microsoft Knowledge Base (KB) rilasciati dopo l'ultima newsletter. Si noti quello che ha Filemon nel titolo. Questo porta a 31 il numero totale di riferimenti della KB a Sysinternals. Un elenco completo è disponibile all'indirizzo http://www.sysinternals.com/ntw2k/info/mssysinternals.shtml

  • Messaggio di errore Eccezione irreversibile durante l'installazione http://support.microsoft.com/support/kb/articles/Q273/9/18.ASP

  • FP2000: I file di elenco dei tipi per i driver di database sono vuoti http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q308935

  • HOWTO: Risolvere l'errore 1928 "Errore durante la registrazione dell'applicazione COM+" http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q308940

  • PRB: Conflitto con EOF quando si usa #import con ADO http://support.microsoft.com/support/kb/articles/Q166/1/12.ASP

  • PRB: DLL non caricate dopo la chiamata a CoFreeUnusedLibraries http://support.microsoft.com/support/kb/articles/Q301/3/57.ASP

  • PRB: Errore 80004005 "Impossibile aprire il file '(sconosciuto)'" http://support.microsoft.com/support/kb/articles/Q306/2/69.ASP

  • PRB: FileMon mostra che DAO360.dll non riesce a caricare MSJet49.dll, MSJet48.dll e altri file MSJetxx.dll http://support.microsoft.com/support/kb/articles/Q306/3/86.ASP

  • SMS: L'agente di inventario software genera un messaggio Errore di pagina non valida http://support.microsoft.com/support/kb/articles/Q302/6/51.ASP

INFORMAZIONI SU INTERNALS

INSIDE WINDOWS 2000, IL DVD INTERATTIVO

Se vi siete persi la versione non definitiva a speciale prezzo di INSIDE Windows 2000, l'esercitazione interattiva in DVD sui meccanismi interni di Windows 2000, abbiamo buone notizie. È ancora disponibile un PREZZO DI LANCIO di 950 dollari, con uno sconto di oltre il 25% sul prezzo normale per singolo utente. Per ORDINARE SUBITO o per altre informazioni su questo nuovo ed entusiasmante prodotto di David Solomon e Mark Russinovich, visitate http://www.solsem.com/dvd.html. Disponibile anche in un formato di distribuzione in rete per lo streaming Intranet.

SEGNA LE DATE: RUSSINOVICH & SOLOMON INSEGNARE INSIEME DI NUOVO A SEATTLE E BOSTON

Il nostro corso di 3 giorni sui meccanismi interni di Windows 2000/XP tenutosi ad Austin il mese scorso ha registrato il tutto esaurito, per cui abbiamo programmato altre due offerte: 17-19 aprile a Seattle e 12-14 giugno a Boston. Le iscrizioni saranno aperte a breve. La classe si basa su "Inside Windows 2000, 3rd Edition" e copre i sottosistemi di ambiente, l'invio delle chiamate di sistema, i thread di sistema, l'avvio e l'arresto, i processi e la pianificazione dei thread, la gestione della memoria, la sicurezza, il sistema di I/O, archiviazione, NTFS e il gestore della cache. Comprendendo i lavori interni di Windows XP & 2000 è possibile sfruttare la piattaforma in modo più efficace e più efficace di debug e risoluzione dei problemi. Per informazioni dettagliate, vedere http://www.sysinternals.com/seminar.shtml

FILE MANIFESTO DI WINDOWS XP

Uno dei cambiamenti più evidenti di Windows XP è il nuovo aspetto del desktop Luna. Luna è in realtà un "tema" e, se si esegue un'applicazione che non è consapevole del tema (qualsiasi applicazione non scritta specificamente per sfruttare i temi di Windows XP), l'applicazione ha il vecchio aspetto di Windows 2000. Tuttavia, anche le applicazioni più vecchie possono avere il nuovo aspetto in modo molto semplice, anche se non si ha il codice sorgente. È sufficiente creare un file manifesto XML per l'applicazione, che indichi al caricatore di Windows XP che l'applicazione vuole usare la DLL Common Control versione 6 (comctl32.dll in %SystemRoot%\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1 df_6.0.0.0_x-ww_1382d70a) invece della versione non consapevole del tema in %SystemRoot%\System32. Ecco il file manifesto che rende Process Explorer v5.2 consapevole del tema:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly
xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Process Explorer"
processorArchitecture="x86"
version="5.1.0.0"
type="win32"/>
<description>Process handle and DLL viewer</description> <dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

Modificare il nome dell'applicazione, la versione e la descrizione dell'applicazione che si vuole rendere consapevole del tema e quindi salvare il file in modo che abbia lo stesso nome dell'eseguibile dell'applicazione, ma con l'aggiunta di ".manifest", ad esempio procexp.exe.manifest. Se siete gli sviluppatori dell'applicazione, potete incorporare il file manifesto nelle risorse dell'applicazione, come ho fatto io con Process Explorer. Per un esempio di come eseguire questa operazione, vedere il codice sorgente in Filemon.

CHE COSA C'È IN UNA X-BOX?

Se avete seguito il mondo dei giochi per console negli ultimi tempi, saprete quasi certamente che la nuova console X-Box di Microsoft esegue una versione modificata di Windows 2000. Mentre eravamo in Microsoft per un recente viaggio di ricerca su Windows XP per la quarta edizione del nostro libro, Dave Solomon e io abbiamo appreso dal team di sviluppo di Windows 2000/XP che il gruppo X-Box aveva scelto Windows 2000 per il supporto dei driver. Dopo la decisione, gli sviluppatori di X-Box hanno ricevuto una copia dell'albero del codice sorgente di Windows 2000 e se ne sono andati, senza farsi più sentire dal team di Windows 2000/XP.

La X-Box ha una versione altamente modificata e ridotta di Windows 2000 che occupa appena 512 KB di memoria. Sono stati rimossi tutti i sottosistemi non rilevanti (in origine avevano eliminato il sottosistema Plug and Play, per poi aggiungerlo dopo aver capito che il caricamento dei driver dipendeva da esso), viene eseguito un solo processo e non è presente un sottosistema Win32 (solo l'API X-Box). La X-Box ha solo 64 MB di memoria fisica e non supporta la memoria virtuale, quindi i gestori della memoria e della cache di Windows 2000 sono due sottosistemi che sono stati rimossi. Con modifiche così drastiche, bisogna considerarlo un nuovo sistema operativo, non Windows 2000.

Per altre informazioni sugli elementi interni di X-Box, GameCube e PS2, vedere http://www.e-insite.net/ednmag/index.asp?layout=article& articleid=CA185947&pubdate=12-20-01

STATISTICHE CASUALI DI WINDOWS XP

Le statistiche seguenti sono state pubblicate da Microsoft sul sito Web di OEM System Builder (all'indirizzo http://oem.microsoft.com dove è possibile registrarsi gratuitamente) e ho pensato che alcune di esse sarebbero state interessanti e/o divertenti.

Per inciso, non è un caso che il numero di build della versione finale di Windows XP sia 2600, ma è stato leggermente falsato. Il numero di build viene incrementato ogni volta che il sistema operativo viene compilato nel lab di compilazione, in genere una volta ogni giorno lavorativo. Fonti interne affermano che il numero è stato destinato alla community 2600, un gruppo di hacker non molto strutturato (http://www.2600.com/), per comunicare la fiducia del team XP nella sicurezza di XP.

  • Numero di giorni impiegato per sviluppare Windows XP: 600 (20/12/99 - 24/8/01)
  • Numero di membri del team dedicati: 5.736
  • Numero di tester per sviluppatore: 1,4
  • Numero di bambini nati durante il progetto: 452
  • Numero di stagisti impiegati: 504
  • Quantità di maccheroni consumati durante 40 "riunioni informative su Windows": circa 3.000 kg
  • Numero di frappuccini® serviti: 86.400
  • Dollari raccolti per la Casa Ronald McDonald di Seattle (ente di beneficenza locale): 2 milioni
  • Numero di test case per la funzionalità di ripristino del sistema: 1,6 milioni
  • Numero di test case per la grafica Direct3D eseguiti a partire da Windows XP RC1: 43.114.143
  • Numero di applicazioni testate per la compatibilità: 5.500
  • Numero di dispositivi predefiniti supportati: 12.000
  • Percentuale delle applicazioni PC più diffuse distribuite negli ultimi tre anni, che saranno compatibili con Windows XP: 90%
  • Numero di tracce nel più grande test case del Catalogo multimediale digitale: 31.000
  • Lunghezza in ore del singolo file più lungo acquisito da Windows Movie Maker: 114
  • Numero di lingue a cui si sta localizzato: 24 completamente & 9 parzialmente
  • Numero di paesi partecipanti al lancio il 25/10: oltre 50
  • Numero di persone partecipanti agli eventi di lancio in tutto il mondo: oltre 580.000 posti... più il pubblico online composto da 5.120 sistemisti in tutto il mondo

NUOVO WINDBG MIGLIORATO

Windbg è un front-end grafico per il supporto al debug del kernel integrato nel kernel di Windows NT/2000/XP. Fino agli ultimi due anni Windbg si è giustamente guadagnato la reputazione di programma macchinoso e complicato, ma la situazione è cambiata da quando Microsoft si è concentrata sul suo miglioramento. L'ultima versione di Windbg, scaricabile gratuitamente da http://www.microsoft.com/ddk/Debugging/, è enormemente migliorata rispetto alle vecchie versioni e più facile da usare. Ci sono alcune nuove funzionalità che anche gli utenti esperti di Windbg potrebbero non conoscere e due comandi utili agli amministratori di sistema che cercano di diagnosticare gli arresti anomali del sistema.

Una funzionalità che rende l'ultimo Windbg molto facile da usare è il suo supporto per il server dei simboli Microsoft. Uno dei problemi dell'analisi dei dump di arresto anomalo o del debug delle applicazioni con Windbg era la necessità di avere installati i file di simboli di debug corretti per la propria installazione. Con i Service Pack, gli hotfix e forse gli arresti anomali di sistemi operativi diversi (ad esempio, Windows NT o Windows XP), questo può essere oneroso. Con il supporto del server dei simboli, è sufficiente immettere l'URL del server dei simboli Microsoft nella finestra di dialogo del percorso dei simboli di Windbg e Windbg scaricherà i simboli dal server su richiesta e li archivierà nella directory specificata. Il server dei simboli ha simboli per Windows .NET Server Beta 3, Windows XP e XP Release Candidate, Windows 2000 e i suoi Service Pack e hotfix, Windows NT 4, MDAC 2.1-2.7, IIS e ISA.

I due comandi utili per il debug dei dump di arresto anomalo sono !analyze e .dump. Eseguire !analyze (specificando l'opzione -v) per ottenere un'analisi automatica, basata sull'euristica, di un arresto anomalo del sistema. Questo comando è già abbastanza potente e, man mano che Microsoft incorporerà altri dati cronologici provenienti da arresti anomali del sistema reali, diventerà ancora più preciso.

Il comando .dump è utile sia per il debug in modalità utente che per l'analisi dei dump di arresto anomalo in modalità kernel. In alcuni ambienti server, in particolare nei server Web, si potrebbe identificare una perdita di memoria o un altro problema, ma non essere disposti ad arrestare e riavviare il server fino a quando la causa non viene isolata. In Windows XP e .NET Server è possibile collegarsi al processo del server usando Windbg, eseguire il comando .dump per generare un file di dump di arresto anomalo della memoria utente e quindi scollegarsi (con il comando .detach), mettendo in pausa il server solo per breve tempo. Uno sviluppatore può quindi portare offline il file di dump generato e analizzarlo.

Per impostazione predefinita, i sistemi server Windows generano un dump di memoria completa, le cui dimensioni sono pari alla quantità di memoria fisica presente sul sistema e può quindi essere molto grande. Tuttavia, è possibile caricare il dump in Windbg e usare il comando .dump per generare una memoria kernel più piccola o un minidump dal dump completo. I file più piccoli sono più facili da scambiare e spesso sono sufficienti per isolare la causa di un arresto anomalo del sistema.

Scaricare l'ultima versione di Windbg da http://www.microsoft.com/ddk/Debugging/ e cercare le istruzioni per configurare Windbg in modo da ottenere i simboli dal server dei simboli Microsoft all'indirizzo http://www.microsoft.com/ddk/debugging/symbols.asp.

SVILUPPI FUTURI

USO DI BOOTVIS PER PROFILARE IL PROCESSO DI AVVIO DI WINDOWS XP

Per riuscire mettere a punto il processo di avvio di Windows XP, il team che si occupa delle prestazioni di Windows XP ha instrumentato i punti chiave del sistema operativo e ha sviluppato uno strumento chiamato BootVis per visualizzare le tracce di avvio. Con una mossa sorprendente, lo strumento è stato reso disponibile gratuitamente. È molto facile da usare e visualizza una quantità incredibile di dettagli, tra cui informazioni sull'inizializzazione dei driver, su quando e dove si verifica l'I/O del disco e sull'avvio di servizi e applicazioni. La prossima volta vi mostrerò dove è possibile ottenerlo e come usarlo.

Grazie per aver letto la newsletter di Sysinternals.

Data di pubblicazione: giovedì 7 gennaio 2002 19:01 da ottoh

[Archivio newsletter ^] [< Volume 3, Numero 2] [Volume 4, Numero 2 >]