Alcuni articoli del supporto Ms sono sempre utili e conviene davvero averli pronti sottomano in caso di bisogno. Nel mio caso, come purtroppo a volte accade, il “caso” si è verificato il giorno in cui la mia workstation (Windows 10 pro x64) ha cominciato a bloccarsi in modo completamente inaspettato.
Il blocco si manifestava in modi diversi che sono andati peggiorando con il tempo. In alcuni casi si trattava del completo congelamento dell’interfaccia, senza alcuna attività apparente della macchina. L’unica cosa fattibile era spegnere e riaccendere il pc.
In altri casi invece, diventati via via più frequenti, la macchina si bloccava completamente con la purtroppo famigerata schermata blu contenenti poche informazioni utili al troubleshooting.
I codici di errore riportati non erano oltre tutto costanti e rimbalzavano dal:
IRQ NOT LESS OR EQUAL
al
PAGE FAULT IN NONPAGED AREA
Chi è avvezzo al troubleshooting dei sistemi Windows sa che purtroppo questi due messaggi sono tipici di due macro tipologie di problemi dietro i quali può essere successo più o meno di tutto: problemi di driver o problemi di memoria.
Da qui quindi è partita la mia indagine.
1) Sono state fatte installazioni/aggiornamenti di recente?
Purtroppo windows 10 fa aggiornamenti in autonomia pertanto la risposta a questa domanda non è così immediata. Per verificarlo comunque è bastato un passaggio su gestione aggiornamenti dove ho verificato che non vi erano stati aggiornamenti particolari oltre alle ultime definizioni di Windows Defender
2) Il sistema riporta errori o problemi inattesi nei log?
Secondo passaggio: verifica in Event viewver. Anche qui nulla di particolare se non degli errori ricorrenti dovuti forse a qualche disinstallazione non andata proprio a buon fine. Questo è forse uno dei punti più “ambigui” dell’analisi in quanto i messaggi potenzialmente preoccupanti possono essere davvero molti. Ho perso molto tempo a risolvere messaggi di errore che nulla avevano a che fare con il mio problema. Male certo non fa… ma è frustrante ritrovarsi a distanza di qualche ora dopo il lavoro di nuovo con lo stesso problema. Unico suggerimento: ignorate gli errori ricorrenti precedenati al problema o, quanto meno, lasciateli in secondo piano e verificateli solo in un secondo momento
3) Il sistema riporta anomalie a livello di periferiche/driver?
Un bel giro in gestione risorse risolve rapidamente questo dubbio. Se nessuna periferica riporta anomalie è comunque consigliabile una verifica della presenza di eventuali driver aggiornati che coprano eventuali bug delle versioni precedenti. Sopratutto se di recente avete aggiunto qualche periferica!
4) Il sistema operativo è integro o riporta anomalie a livello di file, grant, etc… ?
Questo è il punto più difficile da verificare ma Ms ci viene in aiuto con 2 tool: sfc.exe (System File Check utility) e dism.exe (Distributed Image System Maintenance) entrambi disponibili nel sistema operativo. Eccone le descrizioni.
https://support.microsoft.com/it-it/help/947821/fix-windows-update-errors-by-using-the-dism-or-system-update-readiness
https://support.microsoft.com/it-it/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system
Il loro utilizzo, come potete vedere dal contenuto degli articoli, si riassume nel lanciare da un prompth con privilegi elevati i seguenti comandi:
DISM.exe /Online /Cleanup-image /Checkhealth
DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow
5) I dischi sono integri?
Questa è un’ipotesi remota ma è comunque meglio verificarla in modo da scartarla a priori. Windows usa come memoria ausiliaria il file di paging che a sua volta è ospitato su uno dei dischi fissi della macchina. Un problema sul disco che ospita questo file potrebbe tradursi in uno degli errori sopra indicati. Ipotesi remota ma lanciare un check dei dischi, in particolare quello di sistema dove c’è il file di paging, male non fa. Possiamo farlo con tramite gli strumenti grafici (pulsante destro sul disco, “Strumenti”, “Controllo disco”) oppure tramite il vetusto ma sempre affidabile chkdsk
chkdsk [volume] /scan
Maggiori dettagli sul comando anche qui potete trovarli sul supporto Ms:
https://technet.microsoft.com/it-it/library/bb491051.aspx
6) Il problema permane? Allora purtroppo potrebbe trattarsi davvero di un problema di RAM hardware…
Per questa verifica Ms ci mette a disposizione un ulteriore too di diagnostica predisposto per lo scopo: MdSched.exe (Strumento Diagnostica Memoria Windows). Il check della memoria per ovvie ragioni può essere verificato solo da tool appositi eseguiti prima dell’avvio del sistema operativo pertanto, con questo strumento, sarà possibile schedulare un checò imediato al prossimo riavvio di windows. Il tool ha diverse modalità di funzionamento (Base,Standard e Advanced) ma la modalità di deafult (Standard) da documentazione risulta già sufficente alla nostra verifica.
Sempre da un promth con privilegi elevati (o tramite la ricerca) lanciamo MdSched.exe
Maggiori dettagli su questo tool li trovate qui:
https://technet.microsoft.com/en-us/library/ff700221.aspx
In ogni caso il check parte automaticamente e basta lasciarlo andare. Se tutto va bene, dopo la conclusione e successivo riavvio, troverete in Event Viewver un messaggio con il risultato del test.
Se invece qualcosa non va il software potrebbe indicarvi un problema su uno dei moduli di memoria oppure addirittura bloccarsi durante il test.
Cosa si fa a quel punto? Come nel mio caso (*sigh*) l’unica cosa che potete fare è togliere i moduli di memoria rilanciando il test fino a quando non riuscirete a capire quale sia il modulo guasto. Consigliabile in particolare fare tentativi di riavvio togliendo prima le memorie di un canale e poi quelle dell’altro. A seguire scambiate i moduli finchè non capite qual’è quello guasto.
Nel mio caso, alla fine dell’analisi, ho salutato con tutti gli onori del caso, un glorioso ma ormai vetusto e difettoso modulo RAM Samsung da 1Gb.
Ma tutto è tornato a funzionare come prima 😉
zabolab 