Come generare un report delle prestazioni di sistema in Windows 11

Su Windows 11 il modo più pulito per fare un report delle prestazioni non è aprire a caso Task Manager e fare screenshot. Se vuoi un’analisi che serva davvero, devi raccogliere dati coerenti, leggere il sistema nel punto giusto e salvare un output che si possa confrontare nel tempo. Il punto non è vedere se il PC è lento, ma capire cosa lo rallenta, quando succede e quale componente sta saturando prima degli altri.

In pratica hai tre livelli di lettura: una vista rapida per l’operatore, una raccolta più tecnica con strumenti di sistema e una sintesi finale che collega i numeri a una causa probabile. Se salti il primo livello, rischi di raccogliere troppo. Se salti il terzo, finisci con un file pieno di contatori ma senza conclusione utile.

Che cosa deve contenere un report utile

Un report fatto bene su Windows 11 deve rispondere a quattro domande: il problema è costante o intermittente, riguarda CPU o I/O, è legato all’avvio o al carico normale, e il collo di bottiglia è locale o introdotto da un software specifico. Per questo conviene includere almeno questi elementi: uso medio e picchi di CPU, memoria disponibile, latenza e coda del disco, tempi di boot, processi più pesanti e, se serve, eventi del sistema che coincidono con il degrado.

Windows 11 mette già a disposizione abbastanza dati per fare una prima diagnosi senza installare nulla. La combinazione migliore, nella maggior parte dei casi, è Monitoraggio prestazioni, Task Manager, Visualizzatore eventi e il report di diagnostica generato da strumenti integrati. Se il caso è più serio, si passa a un tracciamento con Performance Monitor o con acquisizioni ETW, ma non partire da lì se non hai un motivo preciso.

Metodo rapido: report dalla GUI senza strumenti esterni

Se vuoi un documento leggibile da chi non deve fare reverse engineering del sistema, il percorso più rapido è usare le console MMC già presenti. Il vantaggio è che ottieni una fotografia chiara e ripetibile, senza introdurre variabili extra.

1. Apri Esegui con Win + R.
2. Avvia perfmon per aprire Monitoraggio prestazioni.
3. Nell’albero a sinistra espandi Set di raccoglitori dati e poi Definiti dall’utente.
4. Se vuoi un report pronto, avvia il set System Diagnostics o System Performance se presente sul sistema.
5. Attendi il completamento della raccolta, poi apri il report sotto Rapporti nel ramo Sistema.

Il report generato in questo modo è utile perché mette insieme contatori, eventi e valutazioni del sistema in un unico punto. Se l’obiettivo è fare troubleshooting operativo, è spesso la strada più veloce. Se invece devi produrre un documento da allegare a ticket o da confrontare dopo una modifica, conviene esportare anche i dati grezzi in modo da poterli rileggere.

Per aprire il Visualizzatore eventi e incrociare i messaggi con il periodo del degrado, usa eventvwr.msc. Cerca soprattutto errori o warning che cadono nello stesso intervallo del rallentamento. In un report serio, non basta dire “ci sono errori”: va indicato il canale, l’ID evento, l’ora e il servizio coinvolto.

Raccolta da riga di comando con strumenti nativi

La CLI serve quando vuoi automatizzare la raccolta, ripeterla su più macchine o salvare l’output in una posizione precisa. Su Windows 11 il comando più utile per un report standard è perfmon /report, che avvia la raccolta delle prestazioni e, al termine, apre il report diagnostico.

perfmon /report

Il comando richiede privilegi amministrativi. Se lanciato da un prompt elevato, avvia una sessione di raccolta che dura in genere circa 60 secondi e poi presenta il riepilogo. È una buona base quando devi verificare rapidamente se il collo di bottiglia è evidente: CPU al limite, disco con risposta lenta, memoria sotto pressione o driver che introducono latenza.

Se vuoi salvare una traccia più tecnica, puoi usare logman per creare un set di raccolta e archiviarlo in un file. Questo è il passaggio giusto quando l’anomalia non è continua e devi catturare un intervallo preciso.

logman create counter Win11Perf -o C:\temp\flightreport.blg -f bincirc -c "\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer" -si 00:00:05

Con quel profilo raccogli tre segnali fondamentali: saturazione CPU, pressione sulla memoria e latenza del disco. Il file .blg è comodo perché lo puoi riaprire in Performance Monitor e confrontare con altri intervalli. Se il problema è sporadico, imposta una durata di raccolta coerente con l’orario in cui il difetto si presenta davvero, altrimenti rischi di fotografare solo il sistema in stato normale.

Per avviare e fermare il set puoi usare i comandi standard di logman:

logman start Win11Perf

logman stop Win11Perf

Se il tuo obiettivo è un report da allegare a un ticket, salva anche il nome del profilo, l’orario di avvio e quello di stop. Senza questi dati, il file resta utile ma perde contesto.

Come leggere CPU, disco, memoria e avvio senza farsi ingannare

Il dato più facile da interpretare è spesso quello più fuorviante. Una CPU al 100% non dice da sola che il problema sia il processore: può essere un servizio in loop, un antivirus in scansione, un driver rumoroso o un’applicazione che genera richieste a cascata. Per questo nel report conviene sempre affiancare il totale al processo dominante e al periodo temporale in cui il picco si verifica.

Per la CPU, guarda se il carico è distribuito su più core o concentrato su uno solo. Un singolo core saturo con media bassa può indicare un collo di bottiglia seriale, mentre un uso alto e costante su tutti i core suggerisce saturazione reale. In Task Manager la colonna CPU aiuta, ma in Performance Monitor è più utile confrontare % Processor Time con la coda di esecuzione e con i processi attivi nello stesso intervallo.

Per il disco non fermarti alla percentuale di attività. Quello che conta davvero è la latenza: se il disco è impegnato poco ma risponde lentamente, il problema può essere nel controller, nel file system, in un filtro di sicurezza o in uno storage quasi pieno. Nel report, i contatori più utili sono Avg. Disk sec/Read, Avg. Disk sec/Write e Current Disk Queue Length. Se la latenza cresce mentre la coda si allunga, hai un indizio forte di saturazione o di I/O inefficiente.

Per la memoria, non guardare solo quanta RAM è occupata. Su Windows 11 conta anche quanta memoria è davvero disponibile e quanta pressione c’è sul paging. Se il sistema sembra lento ma la RAM libera è ancora alta, il problema può essere altrove. Se invece la memoria disponibile scende in modo stabile e il disco inizia a lavorare di più, è probabile che il sistema stia paginando troppo. In quel caso il report deve evidenziare anche il processo che consuma più memoria privata o commit.

Per l’avvio, il dato utile non è soltanto il tempo totale di boot, ma la parte che rallenta davvero il rientro operativo: servizi, driver, login o applicazioni in startup. Un boot lungo con desktop subito utilizzabile è diverso da un boot apparentemente rapido ma seguito da minuti di attività disco e CPU. Se il report parla di avvio, includi sempre la finestra temporale post-login, perché è lì che molti rallentamenti si nascondono.

Quando il report deve diventare più tecnico

Se il problema è intermittente o non si ripresenta a comando, la sola fotografia non basta. In quel caso conviene passare a una raccolta più dettagliata con contatori multipli o con tracing. Non serve farlo sempre: ha senso quando devi catturare una finestra precisa, ad esempio un rallentamento che compare all’apertura di una app, durante il login o dopo il risveglio da sospensione.

Una buona pratica è definire prima la metrica obiettivo. Se il problema è percepito come “lento”, scegli un indicatore concreto: tempo di avvio, latenza disco, uso CPU sostenuto, memoria disponibile o tasso di errore di un servizio. Senza una metrica target, il report diventa una collezione di numeri non confrontabili.

Per esempio, se vuoi capire se il sistema degrada durante il login, il report deve coprire almeno il periodo da prima dell’accesso fino a qualche minuto dopo il desktop. Se vuoi capire un rallentamento sotto carico, fai partire la raccolta prima dell’azione che lo scatena e fermala subito dopo. Il file finale deve dire non solo “c’è stato un picco”, ma anche “il picco coincide con questo evento o con questo processo”.

Esportare e conservare i dati per confronto

Un report che serve davvero non è solo leggibile oggi: deve essere confrontabile domani. Per questo conviene tenere separati il riepilogo umano e il dato grezzo. Il riepilogo spiega cosa è successo; il file di raccolta permette di verificare se la correzione ha funzionato o se il sintomo si ripresenta dopo un aggiornamento.

Se usi Performance Monitor, salva il profilo e il file .blg in una cartella con nome coerente, ad esempio con data, host e scenario. Un nome leggibile evita errori quando devi confrontare più sessioni. Se devi allegare il materiale a un ticket, aggiungi anche una breve nota con l’orario esatto di inizio e fine raccolta, la build di Windows 11 e l’utente loggato, perché il contesto cambia la lettura dei dati.

Se il sistema è gestito in modo centralizzato, puoi anche esportare il report come evidenza per un team diverso dal tuo. In quel caso il valore non è la bellezza del grafico, ma la ripetibilità della raccolta. Un report fatto bene deve permettere a un secondo tecnico di arrivare alla stessa conclusione senza dover ricostruire tutto da zero.

Interpretazione pratica: come chiudere il cerchio

Alla fine il report deve produrre una frase operativa, non solo un elenco di contatori. La forma giusta è qualcosa del tipo: il rallentamento è causato da disco in latenza elevata durante il login, oppure la CPU va in saturazione quando parte questo servizio, oppure la memoria scende sotto soglia e il paging aumenta dopo l’apertura di questa applicazione. Se non arrivi a una frase del genere, il report è ancora incompleto.

Quando i dati sono ambigui, non forzare una conclusione. Meglio scrivere che il report non distingue ancora tra due ipotesi e indicare come chiuderle: ad esempio con una raccolta più lunga, con un confronto prima/dopo una modifica o con un tracciamento più mirato del processo sospetto. È più utile di una diagnosi inventata.

In sintesi, su Windows 11 il report delle prestazioni funziona bene quando unisce tre cose: raccolta nativa, contesto temporale e lettura per sintomi. Se tieni insieme questi tre elementi, ottieni un documento che serve davvero per troubleshooting, confronto e verifica post-intervento, senza toccare il sistema più del necessario.