Guida completa all'analisi di BSOD e kernel dump in Windows

Informatec Digital » Risorse » Guida completa all'analisi di BSOD e kernel dump in Windows

Quando un computer Windows si blocca con una schermata blu, non è solo fastidioso: spesso, il dump della memoria nasconde informazioni preziose che ci rivelano esattamente cosa è successo nel kernel. Invece di dare la colpa alla RAM, al BIOS o di formattare immediatamente il computer, vale la pena imparare a leggere questi dati.

Con un po' di pratica, strumenti come WinDbg e funzioni come !analyze -v, .bugcheck o l'uso corretto dei simboli ci permettono di passare da "Ricevo un errore di schermata blu" a "So quale driver, risorsa o dispositivo ha causato la schermata blu". In questo articolo, analizzeremo passo passo e in modo dettagliato come analizzare una schermata blu utilizzando il suo dump del kernel, quali tipi di dump esistono, come preparare tutto e quali comandi utilizzare per ottenere il massimo dall'analisi.

Cos'è un BSOD e quali informazioni contiene?

Quando Windows riscontra una condizione che compromette l'integrità del sistema e non è in grado di ripristinarsi in modo sicuro, effettua una chiamata interna al kernel chiamata KeBugCheckEx . Questa chiamata è ciò che innesca la famigerata schermata blu della morte (BSOD).

KeBugCheckEx riceve sempre cinque argomenti: un codice STOP (codice di errore) e quattro parametri aggiuntivi che forniscono il contesto tecnico dell'errore. Questi stessi dati sono quelli che possiamo poi consultare.

• Sullo schermo blu classico, se il sistema non è configurato per il riavvio automatico.
• Nel registro eventi di Windows, all'interno del Visualizzatore eventi (registro di sistema).
• Nel file di dump della memoria (minidump, kernel dump o full dump), utilizzando WinDbg e comandi come !analyze -v o .bugcheck.

Ogni codice di errore ha un nome simbolico e un valore esadecimale associato . Ad esempio, l'errore DRIVER_POWER_STATE_FAILURE ha il codice 0x9F , mentre RESOURCE_NOT_OWNED corrisponde a 0xE3 . Questi codici e i relativi parametri sono documentati nel manuale di riferimento dei codici di errore di Microsoft, che è sempre consigliabile tenere a portata di mano.

Oltre al codice, la schermata blu potrebbe visualizzare il nome di un driver .sys potenzialmente coinvolto . Se si tratta di un driver di terze parti (antivirus, scheda di rete, scheda grafica, ecc.), spesso abbiamo un chiaro sospettato. Se compare un componente di sistema generico (ntoskrnl.exe, win32k.sys, ecc.) o se non compare nulla, dovremo eseguire un dump della memoria e utilizzare WinDbg per ulteriori indagini.

Tipi di dump di memoria in Windows

Per analizzare a fondo una schermata blu di errore (BSOD), è necessario che Windows generi un file di dump della memoria (DMP) al momento dell'errore. Questo file cattura lo stato del sistema al momento dell'errore e può essere di diversi tipi.

Nelle opzioni "Avvio e ripristino" (fare clic con il pulsante destro del mouse su "Questo PC / Risorse del computer" → Proprietà → Impostazioni di sistema avanzate → scheda "Avanzate" → pulsante "Impostazioni" in "Avvio e ripristino"), è possibile scegliere tra diversi tipi di dump. Ognuno presenta vantaggi e svantaggi.

Piccolo dump di memoria (Minidump)

Il formato minidump è il più piccolo (circa 64 KB) e anche il più limitato per il debug avanzato. Tuttavia, rimane utile per ottenere una diagnosi rapida in molti scenari di schermata blu (BSOD).

Un minidump memorizza, tra gli altri dati:

• Il messaggio di stop, il codice di controllo dei bug e i suoi parametri.
• Il contesto del processore (PRCB) del processore che ha causato il guasto.
• Informazioni sul processo del kernel (EPROSS) del processo attivo al momento dell'arresto anomalo.
• Informazioni sul thread nel kernel (ETHREAD) del thread che ha causato l'arresto anomalo.
• Lo stack delle chiamate in modalità kernel per quel thread (fino a 16 KB).
• Elenco dei driver caricati al momento della sentenza.
• Elenco dei moduli caricati e scaricati.
• Un blocco di dati di debug con informazioni di sistema di base.

Questo tipo di dump viene in genere salvato in %SystemRoot%\Minidump (ad esempio, C:\Windows\Minidump ). Per molti casi di supporto o diagnostica di base, un minidump analizzato a fondo con !analyze -v può essere più che sufficiente.

Dump della memoria del kernel

Il dump della memoria del kernel contiene il contenuto della memoria del kernel al momento del crash, escludendo gli spazi di memoria dei processi utente. Offre un valido compromesso tra dimensioni e dettagli ed è spesso l'opzione consigliata per la diagnosi della maggior parte delle schermate blu di errore (BSOD).

Questo dump viene salvato come MEMORY.DMP in %SystemRoot% (per impostazione predefinita, C:\Windows\MEMORY.DMP ). Le sue dimensioni dipendono dalla memoria utilizzata dal kernel, ma in genere è molto più grande di un minidump e molto più gestibile di un dump completo.

Scarica memoria completa

Un dump completo della memoria salva praticamente tutto il contenuto della RAM al momento dell'errore: kernel, processi utente, ecc. È il più dettagliato, ma anche quello che occupa più spazio ed è il più impegnativo in termini di configurazione.

Affinché un dump completo sia valido, devono essere soddisfatti diversi requisiti:

• El file di paging deve essere nel stessa partizione in cui è installato Windows.
• Ci deve essere spazio su disco almeno pari alla dimensione della memoria fisica della macchina.
• Se si desidera evitare dump danneggiati, non spostare il file di paging su un altro disco fisico.

Negli ambienti di produzione con molta RAM, un dump completo potrebbe risultare poco pratico, ma in casi molto complessi o intermittenti può fare la differenza nell'individuazione del problema.

Configurare Windows per acquisire e registrare i BSOD

Prima di addentrarci nell'utilizzo di WinDbg, è fondamentale assicurarsi che il sistema generi correttamente i dump e registri l' evento della schermata blu.

Nella finestra "Avvio e ripristino" troviamo diverse opzioni rilevanti:

• Scrivi un evento nel registro di sistema: deve essere abilitato affinché il bugcheck venga registrato nel Visualizzatore eventi.
• Scrivi informazioni di debug: qui scegliamo Minidump, Kernel memory dump o Complete memory dump.
• percorso del file di dump: predefinito %SystemRoot%\MEMORY.DMP per kernel/full.
• Riavvia automaticamente: è consigliabile deselezionarlo se vogliamo guarda con calma lo schermo blu e prendi nota di ciò che appare.

Per alcuni produttori o reparti di supporto, come nel caso di determinate schede di rete, all'utente viene richiesto di inviare il file di dump . Solitamente si trova in C:\Windows\memory.dmp ed è consigliabile cercarlo per data/ora per identificare quello corrispondente all'ultimo errore.

Se l'obiettivo è forzare un dump anche quando il sistema è bloccato (senza che tastiera o mouse rispondano), esiste un trucco molto utile per le tastiere PS/2 (non USB/Bluetooth), che consiste nel configurare il registro di sistema per attivare un dump tramite una combinazione di tasti.

Forzare un dump tramite tastiera in caso di blocco

Per generare un dump della memoria anche se lo schermo è completamente bloccato, è possibile utilizzare l' opzione CrashOnCtrlScroll sulle tastiere PS/2. Questo metodo non è valido per le tastiere USB o Bluetooth.

Nel registro dobbiamo creare o modificare la seguente chiave:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Dopo il riavvio, in qualsiasi momento (anche con lo schermo bloccato) è possibile provocare un arresto anomalo controllato e far sì che il sistema generi un dump della memoria premendo il tasto CTRL destro e poi due volte il tasto Bloc Scorr . Questa funzione è molto utile per analizzare gli arresti anomali gravi che non visualizzano automaticamente una schermata blu di errore (BSOD).

Introduzione a WinDbg per l'analisi dei dump del kernel

WinDbg è lo strumento principale di Microsoft per il debug del kernel e l'analisi dei dump di memoria . È disponibile gratuitamente (attualmente anche nel Microsoft Store come WinDbg Preview) e, sebbene a prima vista possa sembrare complesso, per un'analisi iniziale di una schermata blu di errore (BSOD) è sufficiente conoscere alcune opzioni di base.

Possiamo installare WinDbg direttamente sul computer interessato o su qualsiasi altro computer ; il file .dmp può essere copiato in rete, tramite USB o persino compresso in un file CAB. Il processore e la versione di Windows su cui analizziamo il dump non devono necessariamente corrispondere a quelli del computer che ha subito il crash.

Avvia WinDbg con un dump dalla riga di comando

Un metodo classico per aprire un dump di memoria in WinDbg consiste nell'utilizzare la riga di comando con il parametro `-z` , specificando il percorso del file di dump. Questo parametro può essere combinato con altri, come il percorso del simbolo o del file binario.

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Il modificatore -v attiva la modalità dettagliata , molto utile per visualizzare un contesto più ampio. Oltre a WinDbg, esiste anche kd.exe , un debugger basato su console che permette di fare praticamente la stessa cosa ma senza un'interfaccia grafica.

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Aprire un dump dall'interfaccia grafica

Se WinDbg è già aperto in modalità passiva, è possibile caricare un file di dump degli arresti anomali utilizzando il menu File → Apri file di dump degli arresti anomali o la scorciatoia da tastiera Ctrl+D . Seleziona il file .dmp (o anche un file .cab che lo contiene) e WinDbg caricherà le informazioni sull'arresto anomalo.

Un'altra alternativa è avviare WinDbg e, una volta aperto, eseguire il comando .opendump specificando il percorso del file di dump e quindi il comando g (Go) per avviare la sessione di debug del dump:

.opendump C:\Windows\Memory.dmp
g

WinDbg consente anche ripulisci più dump contemporaneamenteaggiungendo più parametri -z sulla riga di comando o ripetendo .opendump con percorsi diversi e gestione della sessione multi-destinazione.

Configurare il percorso dei simboli in WinDbg

Senza i simboli, WinDbg funziona quasi alla cieca. I simboli (.pdb) contengono informazioni di debug su funzioni, strutture interne, variabili, offset, ecc. , e sono essenziali per un'analisi affidabile, soprattutto quando si lavora con il kernel.

Per utilizzare i simboli pubblici di Microsoft senza doverli scaricare manualmente, la procedura consigliata è configurare un server di simboli che punti al server ufficiale di Microsoft e una directory di cache locale. Ad esempio, possiamo innanzitutto creare una cartella C:\symbols e quindi, in WinDbg, configurare il percorso dei simboli come segue:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Questa operazione può essere eseguita dal menu File → Percorso file simboli oppure, in WinDbg Preview, da File → Impostazioni → Impostazioni di debug , regolando il "Percorso simboli predefinito". La prima volta che si analizza un dump di un sistema specifico, il debugger scaricherà automaticamente i simboli necessari da Internet, operazione che potrebbe richiedere alcuni minuti a seconda della velocità della connessione.

È importante notare che i simboli pubblici di Microsoft a volte non includono tutte le informazioni interne sui tipi e potresti visualizzare avvisi come "Il debugger non sta utilizzando i simboli corretti" o riferimenti a tipi non risolvibili. Per un'analisi di base delle schermate blu (BSOD), i simboli pubblici sono generalmente sufficienti, ma se hai bisogno di maggiori dettagli, ci saranno delle limitazioni.

Prima analisi: comandi base e controllo bug

Una volta caricato il dump e configurati i simboli, WinDbg di solito visualizza un'intestazione con le informazioni di sistema e un avviso come "Usa !analyze -v per ottenere informazioni di debug dettagliate". Questo è il nostro primo passo per un'analisi iniziale.

Il comando !analyze -v esegue un'analisi automatica del dump e in genere fornisce:

• Il codice di controllo degli errori (ad esempio, 0xE3, 0xD1, 0x9F, 0x44…).
• I parametri Arg1, Arg2, Arg3 e Arg4 dal bugcheck.
• Il modulo o il driver più probabile causa del fallimento (Probably caused by).
• Il processo associato in quel momento (ad esempio, Teams.exe).
• Lo stack delle chiamate (stack trace) del thread che ha causato l'arresto anomalo.
• Informazioni sul bucket e hash di errore, utili per correlare errori ripetuti.

Ad esempio, in un caso reale di errore di sistema RESOURCE_NOT_OWNED (0xE3) , l'analisi potrebbe indicare che un thread ha tentato di rilasciare una risorsa di cui non è proprietario , mostrando Teams.exe come processo e puntando a win32kbase.sys in una funzione come DrvEnumDisplaySettings . Ciò suggerisce che il thread in questione stava interrogando o manipolando le impostazioni di visualizzazione dallo spazio utente attraverso il livello grafico di Windows.

Per approfondire un po' di più i dettagli del codice di arresto e dei suoi parametri, abbiamo anche il comando .controllo bugche visualizza nuovamente il bugcheck e i quattro argomenti, il che è utile se vogliamo ripetere tali informazioni senza dover rieseguire tutto. !analyze -v.

Casi pratici: driver e conflitti tipici

L'analisi di una schermata blu (BSOD) si concentra in genere sull'identificazione di driver difettosi o malfunzionanti , conflitti tra driver, accessi impropri alla memoria, gestione errata dei pacchetti di richiesta I/O (IRP) e così via. Esaminiamo alcuni esempi pratici tratti da casi reali per comprendere meglio il processo.

RESOURCE_NOT_OWNED (0xE3) associato a Teams e win32kbase.sys

In uno scenario di Windows 10 in cui, dopo diversi giorni di funzionamento, compare una schermata blu (BSOD) con errore 0xE3 (RESOURCE_NOT_OWNED) , il dump del minikernel mostra qualcosa di simile a:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

In questo caso, il debugger indica che l'errore viene attivato da un thread associato a Teams.exe , ma il codice effettivamente presente nello stack al momento critico appartiene a win32kbase.sys , nello specifico alla funzione DrvEnumDisplaySettings . Ciò non significa necessariamente che Teams sia il colpevole diretto, ma piuttosto che Teams stia chiamando un'API utente che causa un bug di sincronizzazione o di rilascio delle risorse nel sottosistema grafico.

In questo tipo di diagnosi, la conclusione è spesso che si tratta di un bug nello stack grafico di Windows, in uno specifico driver video o nell'interazione tra l'applicazione e i driver. La soluzione effettiva potrebbe prevedere l'aggiornamento dei driver della GPU, l'aggiornamento di Teams o persino l'applicazione di patch specifiche di Windows , anziché limitarsi ad attendere che il problema si risolva da solo.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) con NotMyFault

L'utility NotMyFault di Sysinternals è uno strumento didattico che consente di generare errori del kernel in modo controllato per imparare ad analizzare gli screenshot. Ad esempio, se si avvia l' opzione High IRQL fault (modalità kernel) da NotMyFault e si fa clic su "Do Bug", si forzerà un errore DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Nella schermata blu, vedremo qualcosa del tipo DRIVER_IRQL_NOT_LESS_OR_EQUAL e possibilmente un driver candidato (ad esempio, MyFault.sys , il driver utilizzato dallo strumento). Una volta generato il dump e aperto con WinDbg, l'output iniziale potrebbe apparire più o meno così:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Sebbene il debugger segnali un danneggiamento della memoria , sappiamo che la vera causa è legata a NotMyFault e al suo driver. Per confermarlo, possiamo continuare la tracciatura con comandi come !thread per vedere quali chiamate effettua il thread al momento dell'errore e !irp per analizzare l'IRP coinvolto se l'errore è correlato a operazioni di I/O.

Ad esempio, con `!thread <dir_thread>` possiamo visualizzare la traccia dello stack del thread e individuare l'istruzione in cui compare `myfault+0x403` , che indica dove il driver di test ha commesso un errore. Da lì, possiamo esaminare l'IRP, lo stato della memoria e così via, proprio come faremmo con un bug reale.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) e conflitti USB

Un altro caso molto esemplificativo è il bugcheck RICHIESTE_IRP_COMPLETE_MULTIPLE (0x44)Questo errore si verifica quando Un IRP (pacchetto di richiesta I/O) viene completato più di una volta, di solito perché due conducenti diversi credono di possedere lo stesso IRP ed entrambi chiamano IoCompleteRequest().

L'analisi con !analyze -v potrebbe produrre una descrizione simile a questa:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

Inizialmente, il sospettato sembra essere usbehci.sys , un driver Microsoft per i controller USB EHCI. Tuttavia, è relativamente raro che un bug sia effettivamente causato da un driver nativo di Windows senza alcuna interazione di terze parti. Per arrivare al dunque, utilizziamo l'indirizzo IRP fornito dal bugcheck (Arg1) ed eseguiamo !irp <INDIRIZZO_IRP> :

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

Nell'ultima riga, vediamo chiaramente la stringa \Driver\usbehci ax88172 , che rivela come l'IRP sia passato attraverso sia usbehci.sys che un driver chiamato ax88172.sys , associato a uno specifico chipset di rete USB (AX88172). Pertanto, possiamo concludere che il conflitto ha origine da questo driver di terze parti per la scheda di rete USB , e non dal driver EHCI generico di Microsoft.

In tal caso, la soluzione prevede l'aggiornamento del driver dell'adattatore USB, la sostituzione del dispositivo o, se necessario, la sua rimozione . Questo tipo di analisi IRP è particolarmente utile per le schermate blu (BSOD) relative a USB, dispositivi di archiviazione, schede di rete e, in generale, qualsiasi componente che utilizzi un'attività di I/O intensiva.

Comandi WinDbg utili in modalità kernel

Oltre a !analyze -v e .bugcheck , esistono diverse estensioni e comandi di WinDbg molto utili quando si desidera approfondire l'analisi del kernel.

Alcuni dei più comuni sono:

• !filo: Visualizza informazioni dettagliate su un thread, tra cui il suo stack di chiamate, lo stato, gli IRP associati, ecc. Consente di visualizzare le "ultime azioni" del thread in esecuzione quando il sistema si è bloccato.
• !processo 0 0Elenca tutti i processi attivi al momento dell'arresto anomalo. È utile per identificare eventuali processi, servizi, EDR, antivirus, ecc. sospetti in esecuzione sul computer.
• !irp: analizza un IRP specifico e mostra la traccia dei conducenti che ha attraversatoIl comando I/O, i flag, ecc., sono fondamentali nei bug correlati a MULTIPLE_IRP_COMPLETE_REQUESTS e altri errori di I/O.
• !cpuinfo: fornisce informazioni sul processore (produttore, MHz, firme, caratteristiche), utili per verificare gli ambienti hardware.
• !peb: visualizza i dettagli del PEB (Process Environment Block), come il nome del computer, il percorso di installazione di Windows, il numero di processori, ecc.
• !token: fornisce informazioni sui token di sicurezza, sulle autorizzazioni e sul contesto di sicurezza del processo o del thread.
• .cls: cancella la finestra dei comandi, come in una normale console.

Inoltre, molte estensioni specifiche del file system (ad esempio, per PnP, NTFS, ecc.) consentono di estrarre ancora più informazioni dai dump. In alcuni casi, WinDbg indicherà la presenza di BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), ovvero blocchi di dati aggiuntivi acquisiti durante il controllo degli errori per facilitare la diagnosi di aree specifiche del sistema.

Utilizzo di Driver Verifier per trovare driver problematici

Una percentuale molto elevata di errori BSOD (Schermata Blu della Morte) di Windows è causata da driver difettosi o programmati in modo errato . Per rilevare in modo proattivo questo tipo di problemi, il sistema include un potente strumento: Driver Verifier.

Il Driver Verifier viene eseguito in tempo reale e sottopone i driver selezionati a una serie di test e stress test: verifica il corretto utilizzo della memoria, l'utilizzo del pool del kernel, IRQL, IRP, ecc. Se rileva che un driver non si comporta correttamente, può forzare una schermata blu di errore controllata in modo da poter analizzare un dump molto più chiaro, dove il colpevole è solitamente facile da identificare.

Per avviare il gestore Driver Verifier, è sufficiente aprire un prompt dei comandi con privilegi di amministratore e digitare:

verifier

Da lì, possiamo scegliere quali driver vogliamo verificare. È consigliabile essere prudenti: il Verificatore aggiunge un sovraccarico al sistema e può degradarne le prestazioni , quindi si raccomanda di abilitare la verifica solo per il minor numero possibile di driver sospetti, anziché selezionarli indiscriminatamente tutti.

Una volta che Verifier genera una schermata blu (BSOD) a seguito del rilevamento di un comportamento errato, possiamo analizzare il dump del kernel con WinDbg e, si spera, individuare chiaramente quale driver è stato rilevato e cosa ha fatto di sbagliato. Gli articoli di riferimento di Microsoft su Driver Verifier spiegano in dettaglio le varie opzioni e le strategie di utilizzo.

Consigli pratici per ingegneri e tecnici

Che tu sia uno sviluppatore di driver, uno sviluppatore di software che interagisce con il kernel o semplicemente il tecnico di riferimento che riceve tutte le schermate blu di errore, ci sono alcune linee guida che vale la pena assimilare per evitare di perdersi nella giungla dei BSOD.

Il primo passo, quando l'errore è legato al proprio codice, è utilizzare sistematicamente il debugger del kernel per riprodurre e analizzare il problema . Collegando un debugger alla macchina di destinazione (tramite rete, seriale, ecc.), un errore di sistema (bugcheck) farà sì che il sistema si arresti all'interno del debugger anziché visualizzare direttamente la schermata blu. Da lì, è possibile ispezionare la memoria, gli stack, le strutture e correggere il codice.

In altri scenari, i bug check possono essere dovuti a driver, hardware o software di terze parti che non controlliamo. In questi casi, l'obiettivo si sposta dalla "correzione del codice" all'isolamento e alla mitigazione del problema.

• Identificare il driver o il componente hardware sospetto utilizzando WinDbg e l'analisi dump.
• Aggiorna o ripristina versioni dei driver, BIOS, firmware o applicazioni correlate.
• Rimuovere o sostituire Dispositivi USB, schede grafiche, adattatori di rete conflittuale.
• Per appoggiarsi al Visualizzatore eventi, Sysinternals, strumenti di monitoraggio e analisi della rete per ulteriore contesto.

Molti problemi apparentemente misteriosi si risolvono con procedure di risoluzione dei problemi di base : consultare la documentazione, verificare le versioni e le date dei file, reinstallare i componenti chiave o disabilitare i moduli in conflitto. L'analisi del dump ci fornisce una chiara indicazione su dove cercare e spesso ci fa risparmiare ore di tentativi ed errori.

È inoltre importante ricordare che, in ambienti come quello che ha causato l' incidente Falcon di CrowdStrike e altri EDR, le domande più frequenti riguardano cosa ha scatenato la schermata blu di errore (BSOD) e come identificarla rapidamente . Avere WinDbg configurato correttamente, con simboli e una procedura chiara per aprire e analizzare i dump, consente di circoscrivere in pochi minuti ciò che altrimenti potrebbe concludersi con una "formattazione e reinstallazione" senza comprenderne realmente la causa.

In breve, combinando una buona configurazione di dump della memoria, l'uso disciplinato di strumenti come WinDbg, Driver Verifier e Sysinternals, e l'abitudine di esaminare metodicamente log e stack, le schermate blu di un nemico imprevedibile si trasformano in una fonte di informazioni molto precisa su cosa non ha funzionato nel kernel , aiutandoci a prendere decisioni tecniche molto più consapevoli.