Windows 7, ecco la prima temibile falla...

...beh non proprio.

Ho riportato il titolo della news di Tom's Hardware Italia per sottolineare che, come al solito, certe testate "giornalistiche" riportano le notizie senza un minimo di conoscenza di quello di cui parlano.

A leggere l'articolo originale e quello correlato, si capisce che si tratta di un kernel ASSERT che porta ad un freeze della macchina. Non certo una bella cosa, ma ricade nella categoria dei denial of service e non delle "temibili falle".

Considerato poi che riguarda il prodocollo SMB... beh il workaround e' piuttosto semplice, basta chiudere la porta 445 o disabilitare proprio SMB.

Windows update capriccioso.

Ieri mi e' apparso tra gli aggiornamenti disponibili questo:

Security Update for Microsoft XML Core Services 4.0 Service Pack 2 (KB936181)

Provando ad installarlo non appariva alcun errore ma dopo pochi istanti Windows Update lo riproponeva tra gli aggiornamenti disponibili.

La soluzione e' stata scaricare l'aggiornamento stand-alone dal sito Microsoft e avviarlo selezionando l'opzione di rimuovere XML Core Services 4.0 Service Pack 2.

Fatto questo ho rilanciato l'aggiornamento di Windows Update che questa folta si e' concluso senza piu' riproporsi dopo pochi istanti.

Troppe maniglie!

L'altro giorno mi sono accorto di un problemino... il processo audiodg.exe aveva quasi un milione e seicentomila handles attivi e il numero continuava ad aumentare di 20 al colpo.

Dopo un po' di tentativi di isolamento del problema (disattivanto un po' di funzionalita' di programmi e servizi che presumibilmente fanno uso della parte audio) ho scoperto quasi per caso che il colpevole e' Virtual PC.

Basta che Virtual PC sia attivo anche senza alcuna virtual machine in eseguzione affinche' il numero di handles di audiodg.exe inizi ad aumentare con incrementi di 20-25 handles ad ogni aggiornamento del Task Manager.

Chiudere Virtual PC ferma il fenomeno, ma il numero di handles aperti resta invariato.
Al momento non ho ancora trovato altre informazioni a riguardo, ma la cosa mi da' parecchio noia perche' Virtual PC e' il mio pane quotidiano ed ho sempre almeno una virtual machine attiva.

Non ho ancora visto cosa succede se il numero di handles aumenta ulteriormente, prima o poi immagino che qualcosa debba succedere ;-)

Fuori tema: XP che va lento come le Ducati a Jerez

Piu' di qualche volta mi e' capitato di sentire che qualcuno si ritrova con XP che andava lento come una lumaca, ci metteva una vita ad aprire file o a lanciare applicazioni oppure che la CPU andava a palla anche semplicemente per riprodurre qualche mp3.

La prima cosa a cui verrebbe da pensare e' che ci sia di mezzo un virus o un qualche altro maleware, oppure che la colpa sia del disco eccessivamente frammentato e con poco spazio residuo.

Di solito va a finire che dopo avere verificato che non c'e' alcun virus, che il disco e' deframmentato e con spazio a sufficienza, si rinuncia ad ulteriori indagini e si fa un bel format e si reinstalla tutto ex-novo.

Fatto sta che invece si tratta di un problema che puo' essere facilmente risolto senza ricorrere a rimedi estremi. Non essendomi mai capitato in prima persona non avevo idea di quale fosse la causa fino a quando non ho avuto occasione di metterci le mani sopra direttamente.

I sintomi nel mio caso sono stati una lentezza esasperante nella copia da disco a disco e CPU oltre il 50% durante tutta la fase di copia.
Per prima cosa ho controllato il Task Manager per vedere quale processo utilizzasse la CPU cosi' intensamente. Ma il Task Manager mentre nel grafico delle CPU mostrava l'inteso utilizzo, nella lista dei processi non mostrava alcun processo con uso anomalo della CPU.

Mi e' venuto in soccorso l'ottimo Process Explorer di Mark Russinovich che visualizza anche la percentuale di CPU utilizzata Hardware Interrupts.
Ed era proprio un qualche hardware interrupt la causa dell'esasperante lentezza.

Per farla breve il problema e' legato al driver del disco che per un motivo che mi e' del tutto ignoto smette di usare l'accesso DMA e passa in modalia' PIO.

A volte questo passaggio da DMA a PIO e' verificabile tramite il Device Manager andando a selezionare le proprieta' avanzate del driver, ma anche se dovesse apparire la seleziona DMA questo non significa molto.

La soluzione consiste semplicemente nel disinstallare i driver dei controller IDE. Quando si disintalla il driver del disco di sistema XP avvisera' che per la disinstallazione e' necessario riavviare il PC, date pure OK e al riavvio oltre alla disinstallazione avverra' in automatico anche la reinstallazione che sistemera' magicamente tutto.

Errare humanum est, perseverare...

Questa volta il team che si occupa di Windows Update l'ha fatta grossa.

L'aggiornamento relativo al KB937287 (che e' un prerequisito in vista dell'SP1) ha causato in alcuni casi dei problemi: il primo problema e' tutto sommato veniale, l'ho sperimentato in prima persona e si risolve facilmente, l'altro e' molto piu' grave e per quanto abbia una soluzione abbastanza semplice in realta' ha fatto parecchi danni non solo agli utenti che l'hanno subito ma anche all'immagine di Microsoft e soprattutto di Vista.

La cosa veramente grave e' che questo problema in realta' era gia' stato segnalato due mesi fa su un forum Microsoft e da allora c'erano state altre segnalazioni sempre sullo stesso forum.

Allora si trattava dei tre aggiornamenti installati prima della vera e propria installazione del Release Candidate dell'SP1, nei giorni scorsi si e' trattato degli stessi aggiornamenti rilasciati tramite Windows Update, ma tutto fa pensare che il problema sia esattamente lo stesso.

Quello che viene da chiedersi e' come sia possibile che un problema noto da due mesi possa arrivare indisturbato fino alla distribuzione attraverso Windows Update senza che nessuno dica nulla? Che in questo periodo molta gente in Microsoft sia andata in letargo?

Dopo aver preso (finalmente!) atto del problema, hanno rilasciato questo articolo per spiegare come uscirne vivi senza dover ricorrere a soluzioni drastiche e riformattare tutto.

Adesso pero' sarei curioso di sapere i dettagli tecnici del problema, ma soprattutto vorrei sapere come e' stato possibile che nessuno abbia mosso un dito in questi due mesi.

Repetita Iuvant.

Ieri l'update di Vista mi ha installato una dozzina di aggiornamenti, uno dei quali ha dato errore.
Dopo il riavvio della macchina ho provato ad installarlo nuovamente e la cosa e' andata a buon fine.

Dopo un po' mi sono accorto che l'icona di notifica di Windows Update mi avvisava di un nuovo aggiornamento disponibile e senza fare troppe verifiche ho semplicemente dato l'OK a procedere.

La cosa si e' ripetuta altre due volte... al che mi sono insospettito e sono andato a controllare: come da immagine potete vedere che Windows Update ha reinstallato sempre lo stesso aggiornamento ben 4 volte.

La cosa non e' isolata, ci sono altri che l'hanno riscontrata e la soluzione e' scaricare l'aggiornamento stand-alone e installarlo manualmente. Il problema pare sia limitato alla versione x64 di Vista.

Mixer megalomane

Si vede che l'aria Natalizia ha contagiato anche il mixer audio di Vista che ci regala un bachetto quasi comico.

Aprendo la sezione Mixer del volume control che si trova nella Notification bar, l'elenco delle applicazioni di cui si puo' regolare individualmente il volume ne visualizza piu' o meno un centinaio.

Oltre a quelle legittime ci sono innumerevoli applicazioni senza nome che potrebbero essere forse processi realmente in eseguzione, chissa'!

Nulla di trascendentale, sia chiaro, tant'e' che chiudendo e riaprendo il Mixer audio le cose tornano a posto, pero' sempre di baco si tratta.

BlueTooth e BlueScreen.

Giocare con gli auricolari BlueTooth stereo puo' avere effetti collaterali indesiderati ;-)

Il driver terze parti che ho installato per poter fare streaming audio stereo da Vista al Motorola S9 funziona bene ma si e' un filino confuso quando ho provato a collegare contemporanemente il PC e il BlackBerry.

Su Vista non ho abilitato la modalita' di invio di comandi dagli auricolari al PC e quando ho fatto un po' di prove per vedere cosa succedeva se arrivava una telefonata sul BlackBerry mentre ascoltavo della musica via Windows Media Player e' arrivato un BlueScreen del driver Widcomm.

Presumo che l'S9 abbia inviato a Vista il segnale di mettere in pausa il player e che il driver Widcomm si sia impallato forse anche a causa del fatto che avevo disabilitato la modalita' di controllo, sono comunque tutte ipotesi che non ho approfondito oltre.

Questo diventa il primo BlueScreen "inaspettato", il precedente l'avevo cercato col lumicino. ;-)

RSS... bye bye!

E dopo il problema coi favoriti di IE7 che continua a colpire di tanto in tanto si e' aggiunta la morte clinica del lettore RSS che ha deciso di non aggiornare piu' nessuno dei feed sottoscritti.

Riavviare Vista per ora non ha sortito alcun effetto.

Che fo'? Cancellare tutti i feed e riaggiungerli non e' proprio una cosa che aspiro a fare.

Si accettano consigli/suggerimenti/amuleti/...

[AGGIORNAMENTO: dopo un paio di riavvi di Windows e un po' di feed tolti e riaggiunti ha ripreso a funzionare anche per gli altri feed... mah, staremo a vedere se si ripete.]

Dead lock.

Forse il titolo del post precedente non e' stato di buon auspicio. Ieri per la prima volta mi sono trovato con il desktop di Vista completamente bloccato, dopo che e' apparso il messaggio di errore di Windows Explorer non c'e' piu' stato modo di lanciare nuove applicazioni o di accedere al Task Manager, neppure con control-alt-canc.

Avevo una command line aperta e tasklist mi mostrava una discreta lista di taskmgr.exe in esecuzione, ma nessuno visualizzabile.

Neppure taskkill /F e' servito molto, e ancora di meno shutdown che avviava il processo di spegnimento salvo poi interrompersi e mostrare un dialog con la scritta "Logon process failed to create the security option dialog" che poi riportava al desktop in dead lock.

Alla fine l'unica soluzione e' stata rimuove la batteria.

Preferiti non piu' preferiti.

Negli ultimi giorni mi e' successo gia' 3 volte: alcuni preferiti di IE7 non sono piu' preferiti.
Mi spiego, continuano ad apparire nella lista dei preferiti, ma selezionandoli non succede nulla.
Andando a guardare il file corrispondente si vede subito che e' successo qualcosa infatti un preferito non funzionante si presenta cosi':

[InternetShortcut]IconFile=http://www.istartedsomething.com/favicon.icoIconIndex=1

che e' ben diverso da come si presenta se lo si ricrea:

[DEFAULT]
BASEURL=http://www.istartedsomething.com/
[InternetShortcut]
URL=http://www.istartedsomething.com/
IDList=
IconFile=http://www.istartedsomething.com/favicon.ico
IconIndex=1
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,2

Non ho idea di cosa possa causare il problema, se e' successo anche a qualcun'altro mi farebbe piacerlo sapere.

E' arrivato.

Ma gli avevo lasciato volutamente la porta aperta.

Questo sembra definitivamente un baco.

[UPDATE: forse ho parlato troppo presto, se uso un DNS esterno, tipo OpenDNS invece di affidarmi al router che provvede ad inoltrare le richieste al DNS dell'ISP, il baco non si riproduce, quindi e' sicuramente specifico per la configurazione con il DNS gestito dal router e quindi sospetto che sia e' un baco del router]

Passi per riprodurre il baco:

• Aprire IE e navigare un sito.
• spegnere il router DSL (questo passo e' fondamentale che sia eseguito in questo modo, togliere il cavo di rete non e' equivalente e non permette di riprodurre il baco).
• fare refresh del sito appena navigato (IE deve mostrare a questo punto la pagina di errore).
• riaccendere il router e mentre si aspetta che venga ristabilita la linea fare refresh del sito navigato.

Nonostante la liena sia di nuovo attiva IE si rifiutera' di aprire nuovamente la pagina del sito, navigando altri siti non ci sono problemi, ma neppure chiudendo e riaprendo IE il sito di test verra' riaperto.

La stessa identica cosa si puo' fare usando XmlHttpRequest al posto di IE, in realta' il baco l'ho scoperto proprio con esso.

Se a questo punto si sconnette il cavo di rete e lo si riconnette tutto torna a posto.

Pensando ad un problema di caching ho provato ad aggiungere alla request fatta con XmlHttpRequest un parametro variabile proprio per forzare a non usare la cache oltre a settare l'header "Cache-Control" al valore "no-cache": stesso risultato.

Poi ho provato da C# usando HttpWebRequest, stesso identico problema, l'eccezione sollevata e' "The remote name could not be resolved: www.example.com" (chiaramente al posto di www.example.com c'e' il sito che sto testando), quindi il problema e' con la risoluzione del nome.

Anche ping fallisce miseramente.

Decisamente un problema con la cache del client DNS, infatti eseguendo:
c:\ipconfig.exe /flushdns
tutto torna a funzionare. Peccato che pero' la mia applicazione non possa eseguire il flush della cache del client DNS perche' questa operazione richiede i privilegi di amministratore.

Un po' di bachetti.

Uso Virtual PC per motivi di lavoro per cui l'ho installato anche su Vista, ho provato a lanciare le virtual machine che avevo allestito sotto XP e tutto sembrava a posto, comprese quelle con Linux. L'altro giorno lancio nuovamente VPC dopo un paio di settimane che non lo usavo e mi appare questo messaggio di errore.

Visto che le immagini delle virtual machine stanno su un disco esterno USB che uso anche con XP mi viene il sospetto che in effetti ci possa essere qualche problema di privilegi di accesso e che quindi effettivamente VPC non abbia la possibilita' di scrivere su quel disco. Verifico che i Security settings della cartella siano a posto e riprovo ma ricevo lo stesso errore. Non resta che provare a lanciare VPC as administrator ed in effetti l'errore non appare piu'.

Resto un po' confuso perche' non ricordo di aver lanciato VPC as administrator in passato e comunque non vedo perche' debba avere i diritti di administrator per poter accedere ad una cartella della quale ho ottenuto l'ownership. Mah!

Sempre a proposito di dischi USB c'e' da dire che finalmente non c'e' piu' quel noiosissimo dialog che appare in XP ogni qualvolta si collega un dispositivo USB e parte lo scanning della periferica alla ricerca dei tipi di file presenti.

In compenso resta il messaggio non molto esplicativo del perche' a volte il dispositivo e' in uso e non lo si puo' rimuovere, e in questo caso oltre al messaggio e' apparsa anche della spazzatura nel titolo del dialog, se non altro ora sappiamo che di default Vista supporta i caratteri asiatici ;-)

Un'altra cosa molto fastidiosa e' il fatto che Vista non vuole saperne di ricordarsi la password della connessione ai dischi remoti, per quanto uno selezioni il checkbox Remember my password, ogni qualvolta si riapre la connessione remota viene ripresentato il dialog di autenticazione con il textbox della password vuoto.

Sono quei bachi che fanno tanto Windows 95/98/Me, bachi che sicuramente sono presenti nel database dei bachi di Vista, ma che per qualche motivo sono stati considerati non sufficientemente gravi da essere sistemati prima del rilascio di Vista.

Purtroppo pero' per quando siano bachi che non impediscono di utilizzare una funzionalita' restano bachi che hanno un impatto nell'uso quotidiano di Vista e concorrono a renderne meno gradevole l'utilizzo.

In generale tutte i bachi che sono delle regression rispetto a XP secondo la mia personale opinione sarebbero dovuti essere risolti prima del rilascio.

Sempre relativamente alle connessioni remote c'e' un glitch non particolarmente grave ma che ricorda anche lui i difetti di UI di Windows 95/98/Me che con le icone una volta ci prendevano e tre no.

Anche con Vista il refresh delle icone non e' sempre impeccabile, in questo caso quando si rimuove una Network Location, l'icona invece di sparire viene sostituita con quella che vedete qui a destra, un F5 la fa sparire.

Slow Food?

Ecco il primo serio bug di Vista: ama lo slow food!

[UPDATE: mercoledi' 9 maggio - A volte Vista ama andare con XP a mangiarsi un Big Mac, per i dettagli guardare sotto]

[UPDATE: venerdi' 11 maggio - Pare che questa hotfix http://support.microsoft.com/kb/931770 sia effettivamente legata al problema descritto, non ci resta che attendere per vedere quando verra' rilasciata al pubblico]

La prima cosa che i nuovi utenti di Vista notano e' la lentezza nella copia dei file. Sia che si stia compiando da disco a disco sullo stesso computer sia che si copi da un computer ad un'altro.

Notano soprattutto che la copia impiega molto tempo ad iniziare, il dialog di copia mostra infatti la progress-bar ferma sotto la scritta "Calculating time remaining..."
Poi una volta iniziata la copia procede a singhiozzo e complessivamente sembra durare molto di piu' di quanto non si fosse abituati ad aspettare sotto XP.

Una prima cosa da sottolienare e' che evidentemente c'e' un baco nell'algoritmo di calcolo del tempo rimanente e nella gestione della progress-bar perche' infatti se si espande il dialog di copia si nota che in realta' il trasferimento del file e' gia' iniziato da un pezzo anche se la progress-bar e' ferma. Nel caso dell'immagine qui a lato dei 2,73 GB sono gia' stati copiati circa 1,4 GB pero' se l'utente non espande il dialog vede solo una finestra di copia che sembra li' ferma a non fare nulla.

Quindi si tratta solo di una sensazione di lentezza dovuta ad un dialog poco comunicativo?
La risposta e' no.
Vista e' quindi sempre piu' lento di XP nella copia dei files?
La risposta e' no.
Quindi?

Quindi le cose sono un po' piu' complesse. Intanto c'e' da dire che Vista di default ha abilitato lo UAC (di cui parlero' prossimamente) che interviene ogni qualvolta si facciano operazioni su disco e nel caso in cui non si sia owner dei file e delle directory coinvolte lo UAC inevitabilmente ci avverte dell'operazione causandone chiaramente un rallentamento.

Disabilitando lo UAC si nota immediatamente una velocizzazione nella copia dei file, pero' disabilitare lo UAC non e' cosa consigliabile (come appunto spieghero').

Una soluzione e' di prendere possesso delle directory su cui si sta lavorando, se ad esempio si usa un disco esterno per backup che era stato usato prima di Vista il suo file system sicuramente e' soggetto ai controlli dello UAC e quindi tutte le operazioni sono rallentate perche' per ogni file vengono controllati i permessi di lettura e scrittura.

Per ovviare a questo basta aggiungere il proprio utente alla lista di owners e le cose tornano ad avere la consueta velocita' a cui eravamo abituati sotto XP.

Cosi' abbiamo risolto il problema della lentezza nella copia da disco a disco sullo stesso computer, resta pero' il problema della copia dei file da un computer ad un altro computer.

Ho provato a copiare lo stesso file da XP a Vista e poi da Vista a XP per fare un confronto diretto del tempo impiegato.

Per un file da circa 800 MB passato da un router a 100 MBit, la copia da XP a Vista ha impiegato circa 1 minuto e 40 secondi e l'andamento del trasferimento e' stato sostanzialmente regolare come ci si poteva aspettare anche se non ha mai sfruttato appieno la larghezza della banda disponibile.

L'andamento del trasferimento da XP risulta sempre identico, lo sottolineo anche se puo' sembrare scontato, ma leggendo piu' avanti si capisce perche' non e' cosi' scontato.


La copia dello stesso file da Vista a XP ha impiegato circa 2 minuti e 40 secondi quindi ben 1 minuto in piu' (pari a circa il 60% in piu') e il Task Manager ha evidenziato uno strano andamento a singhiozzo, come ben si vede nell'immagine a lato, con picchi seguiti da intervalli nei quali non c'e' alcun trasferimento di dati.

Curiosamente pero' l'uso della banda e' piu' efficiente nel senso che i picchi di trasferimento raggiungono il massimo teorico.

Chiaramente l'andamento complessivo e' ben poco logico e lascia pensare che ci sia qualche baco nel codice che gestisce la copia dei files.

Colto dal dubbio ho provato a copiare lo stesso file da Vista (virtual machine sotto XP) a Vista , risultato? 1 minuto e 20 secondi, quindi circa il 20% piu' veloce di XP.

A questo punto ho provato a fare la copia piu' e piu' volte ed ogni volta ho ottenuto risultati lievemente differenti.

Com'e' possibile che copiando lo stesso file tra due computer il grafico del trasferimento non sia costante?

E' dovuto al fatto che Vista adotta un sistema di trasferimento dei file che ha diversi parametri variabili che tengono conto di diversi fattori e in base a questi fattori l'andamento del trasferimento risultera' di volta in volta diverso.

Questo nuovo sistema e' stato sicuramente introdotto con l'obiettivo di rendere piu' efficiente il trasferimento dei file e non penso di sbagliarmi dicendo che e' stato pensato per lavorare in modo ottimale con i file server, pero' c'e' anche sicuramente qualche baco che si evidenzia quando la copia avviene tra due singoli computer.

Resto molto perplesso dal fatto che non sia stato considerato un baco di alta priorita' e che Vista sia stato rilasciato con questa pecca che, anche se non e' uno showstopper (non impedisce certo di trasferire i file), e' senza dubbio un baco grave perche' da' all'utente la sensazione che Vista sia peggio di XP e chi in ambiente lavorativo si trova a dover interagire spesso con altri computer con XP e a dover copiare files sicuramente non fara' i salti di gioia nel dover attendere quasi il doppio del tempo rispetto a prima.

Per completezza: in rete si trovano consigli (uno qui e un'altro qua) su come cercare di ovviare a questa lentezza, li ho provati, con scarsi risultati.

[UPDATE: dopo aver scritto questo post ho fatto degli altri test di copia da Vista a XP e ovviamente le cose si sono ulteriormente complicate.

Veniamo subito al sodo guardando questo nuovo tracciato di trasferimento: e' il massimo ottenibile, piu' di cosi' non si puo' ed e' piu' veloce dei trasferimenti da XP a Vista di un buon 20%. Cosa e' cambiato dalle prove precedenti? E' cambiato il file, questo e' da poco piu' di 700 MB, e la cosa assurda e' che la velocita' di trasferimento sembra cambiare a seconda del file. Ho provato a cambiare estensione per vedere se questo poteva influire, ma cosi' non e' stato. Cosa causi un cambiamento cosi' rimarcato tra un file e l'altro al momento mi e' del tutto ignoto.]