Appunti sulla risoluzione di un blue screen

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 😉

Recover a database with a DAMAGED and/or LOST log file

In this procedure we’ll manage one of the worst situation a DBA has to manage: corrupted files and data loss. When this heppen usually the common way is restoring but we’ll use sql server features to reduce stop time (avoiding a complete restore) and data loss.

Possible starting problems:
Corrupted logfile
Corrupted logfile during a long transaction
Logfile volume corrupted or lost during transactions

At this point there are different solutions following current database settings:

SCENARIO 1: No transactions running during crash.
Solution:
If no transactions were running at crash point the solution is easy.This because SQL server rebuild automatically lost log file during database startup. So:
1) Detach corrupted database
2) Rename the old corrupted logfile in *.OLD
3) Attach database using:

CREATE DATABASE [MYDATABASE] ON
 ( FILENAME = N'D:Microsoft SQL ServerYourDataPathDataDatabase.mdf' )
 FOR ATTACH_REBUILD_LOG
 GO
 Notes:
 - SQL Server will try to rebuild log file in the ORIGINAL path.

SCENARIO 2: Transactions running during crash
Solution:
ATTACH_REBUILD_LOG in this situation *IS NOT* allowed because SQL Server find open transactions in the database and pending rollback/rollforward operations. So you’ll find the following error trying:

“File activation failure. The physical file name “D:Microsoft SQL ServerYourDataPathDataLogfile.ldf” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘MYDATABASE’.
CREATE DATABASE is aborted. “

So, follow this procedure:
1) DETACH DATABASE MyDatabase
2) Rename datafile and logfile in MDF.OLD and LDF.OLD
3) Create a new database with THE SAME name and identical original datafile and logfile position. I
4) ALTER DATABASE MyDatabase SET OFFLINE
5) Now you can put the original datafile in the original position
6) ALTER DATABASE MyDatabase SET ONLINE. This will fail but now we’ll can rebuild the log file
7) ALTER DATABASE [MyDatabase ] REBUILD LOG ON (NAME=’MyDatabaseLog’,FILENAME=’D:Microsoft SQL ServerYourDataPathDataLogfile.ldf’)
At this point the database will be usable but SQL Server at the end will show this warning:
Warning: The log for database ‘MyDatabase’ has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
8) Final Step: open the database to users:
ALTER DATABASE [nomedb] SET MULTI_USER

Notes:
– In recovery model FULL make a new FULL BACKUP as soon as possible because the RESTORE chain is broken and you need a new baseline for log backup.
*Ask to double-check application consistency* because data recovered could be NOT consistent at application level. (we have done an uncomplete recover). If applicaton checks fails and nothing is fixable rapidly at application levele you have to consider, at the end, only a complete restore.

Queries to see rapidly what your SQL Server is doing NOW

1) Blocked And Blocking queries.
If this query returns no rows you have no blocked queries in this moment. Run it more then once to see any few-seconds blocking queries. NOTE: This exclude ONLY problems with long-locking running queries. Cumulative short-term locking contentions need other kinds of debug (see point 2)

SELECT 'BLOCKING STATUS' as Controllo,
BlockedSPID=left(blocked.session_id,5) ,
BlockedQuery=convert(varchar(50),blockedsql.text),
BlockingSPID=convert(varchar(50),blocking.session_id),
BlockingQuery=convert(varchar(50),blockingsql.text)
FROM sys.dm_exec_requests blocked
JOIN sys.dm_exec_requests blocking
ON blocked.blocking_session_id = blocking.session_id
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocked.sql_handle)
) blockedsql
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocking.sql_handle)
) blockingsql
GO

2) Time-Wait analysis
SQL Server collects informations about time wait events of your instance for every session. Every event (IO,CPU Processing,Locking and so on) is collected and showed in some dynamic management views from instance start/restart. To see what’s heppening now you can reset one af this views and collect for a short time windows events details for debug purpose. To understand the meaning of every SQL Wait Events see: http://msdn.microsoft.com/it-it/library/ms179984.aspx.
Following you can see a good wait analysis script to cross informations for a fast debug (source: http://www.sqlskills.com/blogs/paul/advanced-performance-troubleshooting-waits-latches-spinlocks/)

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR); --reset DM view
GO

SELECT
	[owt].[session_id],
	[owt].[exec_context_id],
	[owt].[wait_duration_ms],
	[owt].[wait_type],
	[owt].[blocking_session_id],
	[owt].[resource_description],
	[es].[program_name],
	[est].1,
	[est].[dbid],
	[eqp].[query_plan],
	[es].[cpu_time],
	[es].[memory_usage]
FROM sys.dm_os_waiting_tasks [owt]
INNER JOIN sys.dm_exec_sessions [es] ON
	[owt].[session_id] = [es].[session_id]
INNER JOIN sys.dm_exec_requests [er] ON
	[es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE [es].[is_user_process] = 1
ORDER BY [owt].[session_id], [owt].[exec_context_id];
GO

3) Open transactions with plan and sql texts
It’s really simple to see informations about current sessions using the old and trusty exec sp_who2 or the dynamic management view sys.dm_exec_requests
But if you need exactly what statements are running and wich plan are they using you need a more complicate query.
This is a good script from http://www.sqlskills.com/blogs/paul/script-open-transactions-with-text-and-plans/ useful to see current transactions with detailed informations about every sessions running.

 SELECT s_tst.[session_id],
   s_es.[login_name] AS [Login Name],
   DB_NAME (s_tdt.database_id) AS [Database],
   s_tdt.[database_transaction_begin_time] AS [Begin Time],
   s_tdt.[database_transaction_log_record_count] AS [Log Records],
   s_tdt.[database_transaction_log_bytes_used] AS [Log Bytes],
   s_tdt.[database_transaction_log_bytes_reserved] AS [Log Rsvd],
   s_est. AS [Last T-SQL Text],
   s_eqp.[query_plan] AS [Last Plan]
FROM sys.dm_tran_database_transactions s_tdt
   JOIN sys.dm_tran_session_transactions s_tst
      ON s_tst.[transaction_id] = s_tdt.[transaction_id]
   JOIN sys.[dm_exec_sessions] s_es
      ON s_es.[session_id] = s_tst.[session_id]
   JOIN sys.dm_exec_connections s_ec
      ON s_ec.[session_id] = s_tst.[session_id]
   LEFT OUTER JOIN sys.dm_exec_requests s_er
      ON s_er.[session_id] = s_tst.[session_id]
   CROSS APPLY sys.dm_exec_sql_text (s_ec.[most_recent_sql_handle]) AS s_est
   OUTER APPLY sys.dm_exec_query_plan (s_er.[plan_handle]) AS s_eqp
ORDER BY [Begin Time] ASC;
GO 

File System Watcher Tool

FSWatcher (watch.exe) is a simple tool developed to monitor file system for every kind of activity of users or applications.

FSWatcher is able to monitor file creation, change, update and delete on file systems with directory and subdirectories. Any activity is logged on a log file with automatic rotation based on log file size and date.

FSWatcher is a completely FREE command line tool, developed for Windows, based on Microsoft .NET Framework (2.0). No installation is needed, simply create a folder and unzip downloaded zip archive  there.

You can download it from HERE

VB.NET source code is downloadable FREE from HERE

How to use it:

Run from cmd with no parameters to show help about how to use it:

C:fswatcher>watch
-------------------------------------------------------------
ZABOILAB FSWatcher v.1.0                   (www.zaboilab.com)
-------------------------------------------------------------
Usage: watch [options] [directory]
Where:
[options]   :  events watched
                  c - change
                  r - create
                  d - delete
                  n - rename
               other options
                  s - watch subfolders (default=false)
[directory] :  directory watched
-------------------------------------------------------------
Log Info:
Events are logged in standard output and in tool's directory
Log file name convention is watch.[1...6].log).
The tool rotate log files on following events (max 6 files):
- on every day change
- When a file becomes bigger than 1Mb
- On every tool's startup
-------------------------------------------------------------
Samples:
watch rd c:mydir
watch crdn c:mydir
watch crdns c:mydir
-------------------------------------------------------------

Sample Usage:

C:fswatcher>watch crdns C:DATA 
-------------------------------------------------------------
ZABOILAB FSWatcher v.1.0                   (www.zaboilab.com)
-------------------------------------------------------------
Monitoring: C:DATA
Logging in: C:fswatcherwatch.1.log
Started: 29/09/2012 20:30:44
Events watching:
- Change
- Create
- Delete
Subdirectory INCLUDED

Press 'q' to STOP
-------------------------------------------------------------
29/09/2012 20:31:34 - File: C:DATAnewfile.doc CREATED by Sam from PCOFFICE1
29/09/2012 20:31:37 - File: C:DATAnewfile2.xls CREATED by Tom From PCOFFICE2
29/09/2012 20:31:42 - File: C:DATAnewfile.doc DELETED by Sam From PCOFFICE1
....