Windows ConfidentialQuando arriva il Dr. Watson

Raymond Chen

Qualcuno avrà notato che se si chiede al Dr. Watson (drwtsn32.exe) di estrarre un'immagine della memoria del processo Winlogon, Windows® viene chiuso non appena termina l'operazione. Alcuni si domandano: perché la connessione di un debugger a Winlogon provoca l'arresto del sistema?

Ma questo accade solo in apparenza. L'esecuzione di Dr. Watson su un processo non equivale a connettere un debugger a un processo. La connessione di un debugger prevede l'impiego di uno strumento simile a ntsd, procedimento che consente di ottenere i risultati desiderati, sempre che si disponga dei privilegi necessari. Questo è il modo in cui il team Windows esegue il debug con Winlogon. Quindi la risposta letterale alla domanda è che la connessione di un debugger a Winlogon non provoca l'arresto del sistema.

Ma il Dr. Watson è solo un analista, non un medico, e si limita a estrarre un'immagine della memoria di un processo che presenta dei problemi per poi interrompere il processo. Poiché Dr. Watson non tenta di risolvere effettivamente il problema, se si lasciasse continuare l'esecuzione del processo, si verificherebbe di nuovo il medesimo arresto anomalo. Sarebbe quindi necessario far intervenire di nuovo il dottore e così via, in un ciclo infinito. In un certo senso Dr. Watson è un debugger che non esegue un reale debug. Il bravo dottore si limita ad apparire sulla scena, prendere nota dell'accaduto ed eliminare il processo. È proprio questa operazione, ovvero l'eliminazione di Winlogon dopo l'estrazione dell'immagine della memoria, che provoca l'arresto anomalo del sistema.

Se si elimina Winlogon, il sistema si riavvia  (Fare clic sull'immagine per ingrandirla)

Winlogon viene definito "processo di sistema critico" e l'interruzione di un processo critico forza il riavvio del sistema. Perché il sistema considera Winlogon fondamentale per il proprio funzionamento? Per iniziare, Winlogon gestisce la SAS (Secure Attention Sequence), vale a dire Ctrl+Alt+Canc. Se si elimina Winlogon, la SAS smette di funzionare, che è già una conseguenza molto negativa. Ciò che è peggio è che senza il custode ufficiale della SAS, un altro programma potrebbe restare in attesa dell'utilizzo da parte dell'utente della sequenza Ctrl+Alt+Canc per presentare una finestra di dialogo fasulla con una richiesta di immettere la password. La possibilità che l'output della sequenza possa essere falsificato mette a rischio l'intero sistema. La chiusura di Windows prima che un evento del genere possa verificarsi costituisce una misura protettiva.

Se si esegue Gestione attività, si evidenzia un processo di sistema critico come Winlogon, si fa clic su Termina processo e si conferma, si ottiene come risultato l'eliminazione di Winlogon e il riavvio del sistema (sempre che si stia eseguendo il sistema operativo con privilegi di amministratore sufficienti per eliminare il processo).

Nelle versioni di Windows precedenti Gestione attività tentava di dissuadere l'utente dall'eliminare i processi di sistema critici, ma l'algoritmo utilizzato per decidere quali processi fossero critici non era dei più brillanti. Con la giusta dose di perfidia, era possibile ingannare Gestione attività e creare un programma che veniva considerato critico e non eliminabile. Questo non è significativo per il caso preso in esame. Era comunque possibile eliminare il programma utilizzando un programma diverso da Gestione attività (ad esempio, con taskkill).

Per evitare inganni, Gestione attività ha semplicemente smesso di tentare di impedire l'eliminazione di processi di sistema critici. Dopotutto, se non si fa nulla non si rischia di sbagliare. Ne consegue che Gestione attività non tenta di indagare le ragioni che spingono un utente a eliminare un processo, né interviene in alcun modo per convincere l'utente a lasciare in pace un processo che è meglio non interrompere. Se si decide di eliminare un processo di sistema critico, si deve imparare a sopportarne le conseguenze.

Raymond Chen, The Old New Thing, così come nel suo libro che porta lo stesso titolo (Addison-Wesley, 2007), vengono illustrate la storia di Windows e la programmazione in Win32. Raymond lascia ad altri il compito di rendere operativi i meccanismi.

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