Quando un PC Windows si riavvia senza spiegazioni, un programma smette di funzionare o una periferica scompare, la risposta spesso è già registrata nel sistema. Il registro eventi di Windows raccoglie errori, avvisi e attività di servizi, driver e applicazioni: imparare a leggerlo permette di distinguere un guasto reale da un semplice messaggio informativo.
La lettura corretta degli eventi accelera la diagnosi
- Visualizzatore eventi è lo strumento integrato per consultare i log di Windows.
- Il registro Sistema aiuta a indagare su driver, servizi, avvii e arresti anomali.
- Un ID evento isolato non basta: servono origine, orario e messaggio completo.
- Con PowerShell è possibile filtrare rapidamente centinaia di eventi.
- I log possono contenere nomi utente, percorsi e indirizzi IP, quindi vanno condivisi con attenzione.
Dove si apre e cosa mostra il registro di Windows
Il modo più rapido per aprire lo strumento è premere Win + R, digitare eventvwr.msc e confermare. In alternativa, basta cercare “Visualizzatore eventi” dal menu Start. La console è presente nelle versioni moderne di Windows 10 e Windows 11, senza installare software aggiuntivo.
Nel pannello sinistro trovi la sezione Registri di Windows. Qui compaiono soprattutto Applicazione, Sicurezza, Installazione, Sistema ed Eventi inoltrati. Per problemi legati al funzionamento del computer, io inizierei quasi sempre da Sistema, perché raccoglie informazioni su kernel, driver, servizi, rete e alimentazione.
Il registro non è la stessa cosa del Registro di sistema, cioè il database delle impostazioni di Windows. Il primo documenta ciò che è accaduto; il secondo conserva configurazioni e parametri. Confonderli è un errore comune e può portare a cercare il problema nello strumento sbagliato.
La posizione dei file
I log vengono salvati normalmente nella cartella %SystemRoot%\System32\winevt\Logs, in file con estensione .evtx. Non consiglio di modificarli o cancellarli manualmente da Esplora file. La gestione corretta passa dal Visualizzatore eventi, da PowerShell oppure dall’utility wevtutil.
Quale registro consultare per primo
Ogni registro risponde a domande diverse. Cercare un errore nel posto sbagliato fa perdere tempo, soprattutto quando il computer genera molti eventi apparentemente simili.
| Registro | Che cosa contiene | Quando consultarlo |
|---|---|---|
| Sistema | Driver, servizi, avvio, arresto, alimentazione e componenti di Windows | Riavvii, schermate blu, periferiche non riconosciute e blocchi |
| Applicazione | Errori e avvisi prodotti dai programmi installati | Un software si chiude, non parte o perde dati |
| Sicurezza | Accessi, autenticazioni e attività controllate dai criteri di audit | Accessi sospetti, problemi di autorizzazione e analisi di sicurezza |
| Installazione | Informazioni relative all’installazione e agli aggiornamenti | Update falliti o modifiche recenti al sistema |
| Applicazioni e servizi | Log specifici di componenti Microsoft e software | Diagnosi mirate di Windows Update, rete, Defender o singoli servizi |
Un caso tipico è il riavvio improvviso. L’evento Kernel-Power 41 segnala che Windows non si è chiuso correttamente, ma non identifica da solo la causa. Potrebbe esserci stato un problema di alimentazione, un blocco, un reset hardware o un arresto forzato. Per capire qualcosa in più bisogna controllare gli eventi nei minuti precedenti e verificare anche driver, temperature e hardware.
Lo stesso principio vale per gli errori dei servizi. Un evento del Service Control Manager può indicare che un servizio si è arrestato, ma il messaggio non prova automaticamente che quel servizio sia l’origine del guasto. Spesso è una conseguenza di un problema precedente.
Come leggere un evento senza saltare alle conclusioni
Facendo doppio clic su una riga si apre la scheda dell’evento. Le informazioni più utili sono data e ora, livello, origine, ID evento e nome del computer. Io confronto sempre l’orario con ciò che l’utente stava facendo: un errore comparso esattamente durante l’installazione di un driver è più interessante di un avviso avvenuto ore prima.
Il livello aiuta a orientarsi, ma non va interpretato come un verdetto. Gli eventi critici meritano attenzione immediata, mentre un avviso può descrivere una situazione temporanea perfettamente normale. Anche molti eventi di tipo Informazioni possono essere utili, perché mostrano la sequenza delle operazioni prima del problema.
Leggi anche: Indicizzazione in Windows 11, come velocizzare la ricerca
Le informazioni che contano davvero
- Origine, cioè il componente che ha scritto l’evento.
- ID evento, un numero utile per riconoscere il tipo di attività.
- Livello, che distingue informazioni, avvisi, errori e criticità.
- Messaggio dettagliato, spesso più importante del titolo breve.
- Dati XML, utili quando il testo mostrato è troppo generico.
L’ID evento è un punto di partenza, non una diagnosi pronta. Due computer possono mostrare lo stesso numero per ragioni differenti, mentre la combinazione tra origine, versione del driver, orario e sequenza degli eventi offre un quadro molto più affidabile. Questa è la differenza tra leggere un log e interpretarlo.
Filtri, PowerShell ed esportazione dei log
Il filtro integrato del Visualizzatore eventi è sufficiente per la maggior parte delle verifiche. Seleziona il registro, scegli “Filtra registro corrente” e limita la ricerca a un intervallo di tempo, a uno o più livelli oppure a specifici ID evento. Filtrare prima per ultime 24 ore è spesso più utile che scorrere anni di registrazioni.
Per un’analisi più rapida uso PowerShell, soprattutto quando il registro contiene migliaia di righe. Questo comando mostra gli ultimi 50 eventi del registro Sistema con le colonne più utili:
Get-WinEvent -LogName System -MaxEvents 50 |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-Table -WrapPer cercare soltanto gli eventi di errore si può restringere il risultato:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 2
StartTime = (Get-Date).AddDays(-1)
}Quando serve inviare il log a un tecnico, è preferibile esportarlo nel formato originale .evtx, che conserva metadati e struttura. Dal menu del registro puoi scegliere “Salva tutti gli eventi con nome”, oppure usare:
wevtutil epl System "%USERPROFILE%\Desktop\system.evtx"Prima di condividere il file controlla la presenza di nomi utente, percorsi personali, indirizzi IP e informazioni sui programmi installati. Cancellare il registro non risolve il problema e può eliminare proprio le prove necessarie alla diagnosi. Se devi liberare spazio, esporta prima i dati e conserva una copia.
Windows e Linux seguono logiche diverse
Il concetto è simile, ma gli strumenti cambiano. In Windows gli eventi sono organizzati in canali strutturati e vengono letti soprattutto tramite Visualizzatore eventi, PowerShell o strumenti centralizzati. In Linux, sulle distribuzioni moderne, il riferimento principale è spesso systemd-journald, mentre alcuni sistemi conservano anche file testuali in /var/log gestiti da syslog o rsyslog.
| Esigenza | Windows | Linux |
|---|---|---|
| Leggere gli eventi del sistema | Visualizzatore eventi o Get-WinEvent
|
journalctl o file in /var/log
|
| Controllare il boot corrente | Filtri sul registro Sistema | journalctl -b |
| Seguire un servizio | Eventi del servizio e del Service Control Manager | journalctl -u nome-servizio |
| Analizzare il kernel | Eventi di sistema e driver | journalctl -k |
La differenza pratica è importante quando si gestiscono ambienti misti. Su Linux è normale combinare comandi, unità systemd e file di testo; su Windows conviene ragionare per canale, origine e ID evento. In entrambi i casi, il metodo resta uguale: definire l’intervallo temporale, isolare il componente e ricostruire la sequenza.
Per infrastrutture più grandi, i log locali non bastano. Server Windows possono inoltrare gli eventi verso una raccolta centralizzata, mentre ambienti Linux possono usare agenti e sistemi SIEM. Il vantaggio è avere correlazione tra più macchine, ma aumentano costi, configurazione e responsabilità sulla conservazione dei dati.
Una routine semplice per ottenere risposte utili
Quando compare un problema, annota prima ora precisa, sintomo e ultima modifica, come un aggiornamento o l’installazione di un driver. Poi apri il registro Sistema o Applicazione appropriato, filtra l’intervallo e confronta gli eventi immediatamente precedenti al malfunzionamento.
Non inseguire ogni errore rosso e non cancellare i log come prima reazione. Esporta gli eventi rilevanti, verifica se il problema si ripete e cerca una correlazione tra più fonti. Con questo approccio il registro eventi Windows smette di essere un elenco confuso di messaggi e diventa uno strumento concreto per capire che cosa è successo davvero.
