Debug dei crash di Windows

Salve a tutti,

sarà capitato anche a voi di trovarvi davanti ad un bluescreen di windows. Escludendo il caso in cui si trattava di un semplice screensaver, avete comunque dovuto cercare la ragione del crash.
A meno che non si tratti di un problema hardware di basso livello per cui si ha un improvviso reboot dell’host o voi non abbiate riavviato il server prima del completamento dell’operazione di creazione del dump, si può quasi sicuramente capire la causa del malfunzionamento di Windows.

Windows al termine del riavvio ci segnala che c’è stato un errore grave e ci chiede se vogliamo inviare la segnalazione (il file dmp), ma se vogliamo capire cos’è successo rimbocchiamoci le maniche e procediamo più o meno così:

Innanzitutto aprendo l’event viewer di windows troviamo un evento commentato come “savedump” e nella descrizione troviamo un bel codice esadecimale più o meno lungo: ne facciamo un search su http://support.microsoft.com con il primo codice esadecimale che c’è scritto.

Possiamo quindi procedere in maniera autonoma se questa ricerca non ha successo o i suoi risultati sono troppo criptici scaricandoci Windbg, parte del pacchetto Debugging Tools for Windows. E’ opportuno scaricare i Symbols del sistema operativo, che servono ad avere un’analisi più accurata del problema. Sono abbastanza corpulenti e differiscono per il tipo di architettura del processore e per sistema operativo: li potete trovare su http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx.

Fatto questo, lanciamo WinDbg dandogli il path dei Symbols e poi apriamo il crash dump; é bene sempre dare il comando “!analyze -v” per avere un dettaglio maggiore sul problema. In questa maniera, anche se l’anomalia non è generata dal sistema operativo, possiamo certamente risalire alla sua causa perchè non serve sapere quale sia il nome della particolare funzione che ha causato il crash (cosa cer la quale sarebbero necessari i Symbols del singolo pacchetto applicativo), ma il nome del file contenente la funzione che è andata in crash…e da lì il passo verso la soluzione è breve.

Saluti,

Lorenzo Di Palma

Terminal Service Licensing Server unico per diversi domini e workgroup

Per ottimizzare l’utilizzo delle licenze terminal in ambienti multidominio che non appartengono ad una stessa foresta o enterprise o per server che appartengono a distinti workgroup si può utilizzare questo piccolo trucchetto.

Il license server terminal deve essere una macchina non attestata ad alcun dominio;

Per i server terminal bisogna settare in maniera statica il license server da contattare dato che la funzionalità di autodiscovery del license server (opzione peraltro deprecabile) non è supportata in questo contesto:

279561 – How to Override the License Server Discovery Process in Windows Server 2003 Terminal Services;

Fin qui niente di strano, ma ora viene il bello: bisogna dare l’accesso anonimo al license server, ovvero che l’access token per le connessioni anonime includa il grupo Everyone. Per farlo basta abilitare questa policy locale:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options“Network access: Let Everyone permissions apply to anonymous users”  

 

Per windows 2003 questo è più che sufficiente dato che nella modalità “Per User” le licenze non sono gestite; diverso è il discorso per 2008 che necessita di una trust relationship tra il dominio contente il license server e quello contenente gli account utenti.

Lorenzo Di Palma

Sysprep per windows 2003 e XP

Sysprep è un utility gratuita microsoft utilizzata per “preparare” macchina windows alla clonazione. Clonare una macchina vuol dire riprodurre il sistema operativo di origine su un’altra macchina virtuale o fisica che sia, questo è utile in ambienti di test o produzione dove spesso vengono aggiunti server o in fase di deploy tramite servizi di installazione remota dove molte macchine vengono create in maniera semiautomatica. Lo strumento in questione permette l’automazione del processo di installazione e l’eliminazione dei parametri identificativi di ogni singola installazione. Di fatto una macchina windows è caratterizzata in primo luogo da quel valore di registro chiamato SID (Security IDentifier), questo valore è unico e generato randomicamente da un apposito algoritmo all’atto dell’installazione di windows. Sysprep elimina il sid originale della macchina da clonare e da la possibilità di automatizzare il processo di installazione creando un file contenente tutti i parametri da fornire all’installer di windows.Il tool lo si può trovare nel cd di installazione del prodotto microsoft sotto la directory /support/tools/deploy.cab ed il suo utilizzo è abbastanza semplice:

Procedura per Windows server 2003

1) Copiare il contenuto del file deploy.cab all’interno di una directroy (di solito io creo c:\sysprep).
2) Lanciare l’eseguibile sysprep.exe.
3) Cliccare su fabrica per automatizzare il processo di installazione.
4) Lasciare aperta la schermata del sysprep lanciare l’eseguibile stupmgr.exe, selezionare installazione con sysprep, il sistema operativo in uso, di rendere l’installazione completamente automatica e inserire i dati desiderati.
5) Cliccare su controllo nella schermata di sysprep.
6) Una volta riavviata la macchina cliccare su sigilla.
7) Clonare il disco con un software per la clonazione di dischi rigidi (ad esempio acronis true immage server)

Procedura per windows XP

La procedura per windows XP è fondamentalmente uguale a quella per windows server 2003, unico neo è un piccolo problema sull’inserimento del codice seriale, di fatto utilizzando la procedura sopra descritta all’atto dell’accensione della macchina, durante il setup iniziale, viene comunque chiesto il codice seriale. Il workaround è utilizzare l’opzione utilizza mini setup spuntando l’apposita casella nell’utility sysprep. Personalmente non ho otato particolari differenze anche se documentandomi in rete ho letto che con questo sistema eventuali personalizzazioni effettuate nel profilo dell’account administrator vengo replicate su tutti gli altri account della macchina.