Guida pratica a Process Monitor (ProcMon) — Individuare in 10 minuti "la configurazione non viene letta" e "ACCESS DENIED"

“Ho riscritto il file di configurazione, ma il comportamento dell’applicazione non cambia.” “Sulla macchina di sviluppo funziona, ma solo sul terminale del cliente si blocca subito dopo l’avvio.” “Funzionava fino a ieri. Non ho cambiato nulla nel programma.” — Le richieste di indagine sui difetti arrivano quasi sempre in questa forma. E in gran parte di questi casi, per quanto si legga il codice sorgente, non si riesce ad arrivare alla causa. Perché quali file l’applicazione legge realmente, quale registro consulta e cosa fallisce davvero non è deciso dal codice, ma dall’ambiente di esecuzione.

Lo strumento che registra questo “cosa è realmente successo” è Process Monitor (ProcMon), uno strumento Sysinternals fornito gratuitamente da Microsoft. È, per così dire, un registratore del comportamento di Windows, che registra in tempo reale tutta l’attività di file system, registro e processi/thread, ed è uno strumento a cui ricorriamo spesso nelle nostre indagini sui difetti, insieme a WinDbg.¹

Per quanto potente, se avviato senza alcuna configurazione arrivano migliaia o decine di migliaia di eventi al secondo, e alla prima occhiata si finisce spesso per pensare “sono troppi, non riesco a leggerli”. In questo articolo mettiamo in ordine la via più breve per usare ProcMon nella pratica quotidiana — come impostare i filtri, come leggere la colonna Result, i pattern di indagine tipici per sintomo, le precauzioni in ambiente di produzione e i criteri di scelta rispetto ad altri strumenti di indagine — con il punto di vista di chi affronta le indagini sui difetti sul campo.

1. Prima di tutto, la conclusione

• La domanda a cui ProcMon risponde è “questo processo, quando, su quale percorso, cosa ha fatto e con quale esito”. In pochi minuti si scopre da dove viene letto il file di configurazione, in quale ordine sono state cercate le DLL, quale operazione ha restituito ACCESS DENIED.
• La prassi d’uso consolidata è “prima applicare un Include su Process Name per isolare il processo target, poi restringere su Result agli esiti anomali”. Non è uno strumento da leggere riga per riga dall’alto sugli eventi grezzi.
• Nella colonna Result molti valori sembrano anomali ma sono in realtà normali. BUFFER OVERFLOW è un normale scambio API, e NAME NOT FOUND è quasi sempre solo un passaggio intermedio nell’ordine di ricerca (capitolo 4).
• Il filtro è una restrizione della sola visualizzazione: dietro le quinte tutti gli eventi vengono comunque registrati. Quando si salva il log per consegnarlo ad altri, va salvato con tutti gli eventi. Al contrario, nelle catture di lunga durata Drop Filtered Events protegge la memoria (capitolo 5).
• ProcMon non è onnipotente. “Quale processo sta tenendo aperto questo file in questo momento” è compito di Process Explorer, lo stato al momento del crash è compito del dump di crash, e dove viene consumata la CPU è compito di PerfView (capitolo 7).

Ecco prima una tabella di riferimento rapido per scegliere lo strumento in base al sintomo.

2. Cos’è ProcMon — l’installazione richiede un minuto

Process Monitor è uno degli strumenti Sysinternals: uno strumento di monitoraggio che mostra in tempo reale l’attività di file system, registro e processi/thread. È il successore che unifica e potenzia i due vecchi strumenti Filemon e Regmon, e dispone di informazioni dettagliate per ogni evento, filtri non distruttivi, registrazione dello stack dei thread e logging fin dal boot.¹

L’installazione è semplice. Non esiste un programma di installazione: basta scaricare lo ZIP dalla pagina di download, estrarlo ed eseguire Procmon.exe. Per indagini urgenti si può anche eseguirlo direttamente tramite il servizio Sysinternals Live, da https://live.sysinternals.com/procmon.exe.² Al primo avvio viene richiesta l’accettazione della licenza d’uso, e poiché carica un driver kernel è necessario un account con privilegi di amministratore (elevazione UAC). Il discorso generale sul perché servano i privilegi di amministratore è quello trattato in “Quando sono necessari i privilegi di amministratore su Windows”: gli strumenti che osservano gli eventi dell’intero sistema operativo rientrano tipicamente nel caso che “richiede elevazione”.

La cattura inizia nel momento stesso dell’avvio, e sullo schermo iniziano subito a scorrere gli eventi. Bastano tre operazioni principali da ricordare.

Ogni riga di evento è composta da “Time (orario), Process Name (processo), PID, Operation (operazione), Path (percorso oggetto), Result (risultato), Detail (dettaglio)”. Operation ha una granularità che corrisponde grosso modo alle API Win32, come CreateFile (apertura/creazione di un file), ReadFile/WriteFile, RegOpenKey/RegQueryValue. In altre parole, il log di ProcMon è “il registro della conversazione tra l’applicazione e il sistema operativo”, ed evidenzia direttamente la differenza tra “l’intenzione” e “la realtà”: dove l’applicazione intendeva leggere il file di configurazione e dove lo ha effettivamente letto.

3. Filtri — ProcMon è uno strumento da leggere dopo aver ristretto il campo

Se si effettua una cattura senza fare nulla, anche su un Windows inattivo scorrono migliaia di eventi al secondo. Si può dire che l’utilità pratica di ProcMon dipende da come si usano i filtri, e la prassi consolidata prevede due fasi.

Prima fase: restringere per processo. Apri la finestra dei filtri con Ctrl+L e aggiungi Process Name / is / myapp.exe / Include. Esiste anche il metodo di trascinare l’icona a forma di mirino della barra degli strumenti sulla finestra dell’applicazione target, per applicare il filtro solo a quel processo.

Seconda fase: restringere per risultato o operazione. Se vuoi cercare le operazioni fallite: Result / is not / SUCCESS / Include (mostra solo gli esiti anomali). Se vuoi vedere solo le scritture: Category / is / Write / Include. Se vuoi sapere chi sta toccando un determinato file di configurazione, senza restringere per processo: Path / contains / app.config / Include, e così via.

Un’altra tecnica molto usata nella pratica è la restrizione interattiva tramite il clic destro sulla riga dell’evento. Trovata una riga vicina all’obiettivo, basta fare clic destro e scegliere “Include ‘questo percorso’” o “Exclude ‘questo processo’”: i filtri si accumulano senza bisogno di aprire la finestra di dialogo. L’operazione base consiste nell’eliminare con Exclude le fonti di rumore (antivirus, indicizzatori, ecc.) fino a lasciare solo ciò che precede e segue l’operazione target. Anche l’evidenziazione (Ctrl+H) è utile come supporto visivo: si può colorare le righe con la stessa sintassi di espressione dei filtri, quindi quando “voglio vedere il flusso complessivo ma far risaltare solo gli esiti anomali” conviene usare l’evidenziazione invece del filtro.

Ci sono tre comportamenti che, se non conosciuti, causano problemi.

• Il filtro restringe la visualizzazione, non la registrazione. Dietro le quinte (per impostazione predefinita) vengono registrati tutti gli eventi, e togliendo il filtro si può sempre tornare alla visione completa. È il motivo per cui viene chiamato filtro non distruttivo: è una progettazione che rende difficile “restringere troppo e perdere le prove”.¹
• Le impostazioni del filtro vengono mantenute al riavvio successivo. Chiedersi perché “non viene mostrato nulla” perché è rimasto il filtro di un’indagine precedente è un’esperienza che prima o poi capita a tutti. Se la visualizzazione sembra strana, la prima cosa da sospettare è Reset Filter (Ctrl+R) nel menu Filter.
• Per impostazione predefinita sono già presenti alcuni Exclude. ProcMon stesso e le operazioni di paging I/O, ad esempio, sono esclusi fin dall’inizio. Nelle indagini in cui il requisito è “l’intero sistema senza omissioni”, bisogna tenere presente l’esistenza di questi filtri predefiniti.

4. Come leggere la colonna Result — cosa sembra anomalo ma è normale

Restringendo agli esiti anomali con il filtro, ci si sorprende a vedere comparire in massa “risultati apparentemente anomali”. Il punto importante qui è che la maggior parte dei valori anomali nella colonna Result fa parte del funzionamento normale. Riassumiamo come leggere i principali valori di Result.

Tra questi, i tre protagonisti dell’indagine sono NAME NOT FOUND, ACCESS DENIED e SHARING VIOLATION. Ognuno ha pattern di indagine tipici, che vedremo nel prossimo capitolo partendo dai sintomi.

Al contrario, un pattern spesso trascurato è quello in cui “la causa è un SUCCESS”. Per esempio, la risposta a “il file di configurazione che ho corretto non viene applicato” si è rivelata più di una volta essere un SUCCESS su un vecchio file di configurazione situato altrove. Se si guardano solo gli esiti anomali, si rischia di non accorgersi di questa “risposta sbagliata” caricata correttamente con successo: la strategia sicura è restringere per percorso e vedere tutti gli accessi a quel tipo di file, inclusi i successi.

5. Pattern di indagine tipici per sintomo

5.1 “Ho corretto la configurazione ma non viene applicata” — individuare da dove viene letta

Applicando un Include su Path / contains / nome del file di configurazione e avviando l’applicazione, si ottiene l’elenco completo di da quali cartelle e in quale ordine l’applicazione ha cercato un file con quel nome. Le verità più comuni sono una di queste:

• Veniva letta una copia in %APPDATA% o sotto ProgramData, non nella stessa cartella dell’eseguibile (era un design che copiava il file al primo avvio)
• L’accesso al registro o alle cartelle di sistema da un processo a 32 bit subiva la redirezione WOW64, e il punto che si credeva di guardare non coincideva con quello reale
• La scrittura sotto Program Files, cartella di installazione, veniva virtualizzata (VirtualStore), e lettura e scrittura finivano trasformate in un percorso diverso

In tutti questi casi ProcMon mostra il percorso completo nella colonna Path, quindi il problema si vede a colpo d’occhio. Il discorso complementare su come progettare la posizione dei file di configurazione è trattato in “Non solo appsettings.json — la pratica della gestione della configurazione”.

5.2 “Non si avvia solo in questo ambiente” — seguire la ricerca delle DLL

Quando l’applicazione si blocca subito dopo l’avvio o compare un errore del tipo “DLL non trovata”, applica un Include sul processo e aggiungi Path / ends with / .dll, poi osserva la catena di NAME NOT FOUND. La ricerca delle DLL su Windows segue un ordine fisso di cartelle, quindi nel log di ProcMon compare esattamente questa forma: “una serie di NAME NOT FOUND nell’ordine di ricerca, seguita da un SUCCESS da qualche parte (oppure mai trovata fino alla fine)”. La DLL che non arriva mai a SUCCESS è la colpevole. Al contrario, qui si trova anche il pattern in cui “arriva a SUCCESS, ma sta caricando una vecchia DLL in un punto non previsto”. La logica dell’ordine di ricerca è spiegata in “Il meccanismo di risoluzione dei nomi delle DLL in Windows”, che consiglio di leggere insieme a questo articolo.

Anche il caso “classe non registrata” legato a COM/ActiveX è dello stesso tipo, e si osserva come un NAME NOT FOUND sotto la chiave CLSID di RegOpenKey. Gli incidenti in cui, per uno scambio tra 32 bit e 64 bit, si finisce per consultare la vista di registro sbagliata sono affrontati con la procedura descritta in “Cause e verifica dei problemi di ActiveX che non funziona con Office 2024/Microsoft 365”, e anche lì ProcMon resta la via più rapida.

5.3 “Compare ACCESS DENIED” — sospettare con quali permessi gira il processo

Trovato un ACCESS DENIED, fai doppio clic su quell’evento e controlla la scheda Process. Compare con quale utente stava girando quel processo, il che permette di scoprire discrepanze come “il servizio girava con un account di servizio limitato invece che con SYSTEM” oppure “solo all’avvio da Task Scheduler l’utente era diverso”. Se l’oggetto è un file, confrontando l’ACL di quel percorso si arriva alla conferma della causa. Va notato che nei casi in cui è coinvolto un antivirus, spesso si vede, appena prima o dopo, un altro processo (il motore dell’antivirus) toccare lo stesso percorso: anche questa è una prova che solo ProcMon, registrando in ordine cronologico, può fornire.

5.4 “A volte l’elaborazione di un file fallisce” — cercare l’antagonista di SHARING VIOLATION

Le violazioni di condivisione sono un’indagine in cui l’ordine cronologico è tutto. Applicando un Include per percorso, senza filtrare per processo, e catturando in questo modo, nelle righe adiacenti al momento del fallimento compare chi aveva aperto lo stesso file. I sospettati abituali sono il software di backup, l’antivirus, o processi residui di Excel. Il design che evita del tutto questo tipo di conflitto nell’interscambio di file è trattato in “Nozioni di base sul controllo di accesso esclusivo nell’interscambio di file”, mentre il problema dei processi EXCEL.EXE residui è riassunto in “Il problema di EXCEL.EXE che rimane in esecuzione con l’interoperabilità COM di Excel in C#”. Va anche detto che, se si vuole sapere solo “chi lo sta tenendo aperto in questo preciso momento”, la ricerca degli handle di Process Explorer (Ctrl+F) è più rapida di ProcMon.³

5.5 “L’avvio è lento” — individuare dove viene consumato il tempo

Aggiungendo la colonna Duration nelle impostazioni delle colonne, si vede il tempo impiegato da ciascuna operazione. Inoltre, con Process Activity Summary e File Summary nel menu Tools, si possono aggregare il numero di operazioni e il tempo per processo e per file. Questo è sufficiente per individuare casi come “all’avvio venivano effettuate decine di migliaia di letture del registro” o “l’accesso a un percorso di rete restava in attesa fino al timeout”. Tuttavia una profilazione approfondita di dove viene consumata la CPU non rientra nell’ambito di ProcMon. Se la lentezza è dovuta al calcolo e non all’I/O, si passa a PerfView e dotnet-trace.

5.6 Problemi all’avvio o al logon — il boot logging

Per casi come “il servizio fallisce prima del logon” o “l’applicazione registrata come avvio automatico non parte”, in cui il problema si verifica prima ancora che si possa avviare manualmente ProcMon, si usa Enable Boot Logging nel menu Options. Vengono registrati gli eventi fin dall’avvio iniziale del boot successivo, e alla successiva esecuzione di ProcMon viene proposto di salvarli. Il boot-time logging è una funzionalità ufficiale offerta da ProcMon,¹ e per le indagini legate all’ordine di avvio o agli script di logon è l’unico strumento adatto.

6. Salvare e trasferire i log — quando la cattura viene fatta nell’ambiente del cliente

Nella pratica dell’indagine sui difetti, non è raro che l’ambiente in cui il problema si riproduce esista solo presso il cliente. I log di ProcMon possono essere salvati come file PML e, aperti su un’altra macchina, mostrano tutte le colonne e tutti i dettagli: questo rende possibile la divisione del lavoro “il cliente effettua la cattura, noi analizziamo”. La procedura che usiamo quando affidiamo questo compito al cliente è la seguente.

1. Eseguire Procmon.exe come amministratore e accettare la licenza d’uso
2. Una volta avviato, fermare la cattura con Ctrl+E e pulire la visualizzazione con Ctrl+X
3. Avviare la cattura con Ctrl+E e riprodurre l’operazione che causa il problema
4. Non appena il problema si riproduce (o compare l’errore), fermare subito con Ctrl+E
5. In File > Save, scegliere All events invece di Events displayed using current filter, salvare in formato PML, comprimere in ZIP e inviare

Il punto chiave è “All events” al punto 5. Anche se sullo schermo del cliente è rimasto un filtro attivo, la registrazione stessa contiene tutti i dati, quindi dal nostro lato possiamo restringere liberamente come vogliamo. Nei casi in cui la riproduzione richiede tempo o non si sa quando avverrà, lasciare la cattura attiva senza precauzioni continua a consumare memoria: bisogna specificare almeno una di queste due opzioni: abilitare Filter > Drop Filtered Events per registrare solo il processo target, oppure passare in File > Backing Files la destinazione di salvataggio dalla memoria virtuale a un file. Se si lascia una cattura in esecuzione per una notte intera senza conoscere queste due opzioni, si finisce per esaurire la memoria e ProcMon raggiunge il proprio limite prima ancora dell’oggetto dell’indagine.

Per chi vuole automatizzare, sono disponibili anche opzioni da riga di comando: /AcceptEula sopprime la finestra di accettazione, /BackingFile specifica il file di destinazione della registrazione, /Runtime imposta l’arresto automatico dopo un numero di secondi specificato, /Terminate termina un’istanza di ProcMon in esecuzione. Combinandole si può arrivare a una configurazione in cui, “in caso di guasto, l’operatore esegue un solo batch e le prove restano registrate”. L’idea di decidere in anticipo cosa raccogliere in caso di guasto è comune anche a la raccolta dei dump di crash e la progettazione del log degli eventi.

7. I limiti di ProcMon e i criteri di scelta rispetto ad altri strumenti

ProcMon è uno strumento che mostra “la sequenza temporale delle operazioni”, e non è adatto a ogni tipo di indagine. Ecco come ripartiamo i ruoli nelle nostre indagini.

Ci sono tre confini in cui è facile esitare:

• Rete: ProcMon registra gli eventi di connessione e invio/ricezione TCP/UDP (quale processo ha comunicato con cosa), ma non è visibile il contenuto dei pacchetti. Per l’indagine a livello di protocollo bisogna passare a Wireshark o allo strumento standard di Windows pktmon.⁴
• Memoria: “l’uso della memoria continua a crescere” non si può seguire con ProcMon. Per l’heap gestito, si procede con la distinzione tra GC e leak, per gli handle con la procedura di indagine sugli handle leak.
• Stack: in realtà anche ProcMon registra lo stack del thread che ha emesso ciascun evento (doppio clic sull’evento → scheda Stack), e configurando i simboli si può individuare a livello di codice “chi ha emesso questo accesso al file”. A questo punto ci si trova già nel territorio di WinDbg, dove conta la gestione dei simboli (PDB).

8. Riepilogo — guardare i fatti prima di leggere il codice

La prima cosa da fare quando si indaga un difetto dipendente dall’ambiente non è leggere il codice né formulare ipotesi, ma registrare cosa è realmente successo. ProcMon è la via più breve per farlo: con un minuto di installazione e pochi minuti di cattura si ottengono fatti incontrovertibili su quale percorso, in quale ordine, con quali permessi è stato toccato e cosa è fallito. Padroneggiando queste tre cose — le due fasi del filtro (processo → Result), come leggere i valori di Result che sembrano anomali ma sono normali, e la consegna con il salvataggio di tutti gli eventi — un’indagine ferma a “non si riproduce sulla macchina di sviluppo” può fare un passo avanti nello stesso giorno.

Ci occupiamo dell’indagine di difetti le cui condizioni di riproduzione non sono chiare, della definizione delle procedure di raccolta delle evidenze per guasti che si verificano solo nell’ambiente del cliente, e dell’analisi delle cause combinando ProcMon, WinDbg e PerfView. Possiamo essere d’aiuto anche a partire dalla fase in cui “il log non mostra nulla, ma il sistema non funziona”.

Articoli correlati

• Leggere i dump di crash con WinDbg + SOS — introduzione pratica all’analisi dopo la raccolta
• Individuare la lentezza con PerfView e dotnet-trace — introduzione pratica all’indagine sulle prestazioni .NET
• Introduzione alla raccolta dei dump di crash su Windows - WER/ProcDump/WinDbg
• Il meccanismo di risoluzione dei nomi delle DLL in Windows - ordine di ricerca e SxS
• Indagine su un crash da esecuzione prolungata di una telecamera industriale - capitolo sull’handle leak

Aree di consulenza correlate

合同会社小村ソフト (KomuraSoft LLC) si occupa di indagine sulle cause di difetti difficili da riprodurre e dipendenti dall’ambiente, di definizione delle procedure di raccolta delle evidenze in caso di guasto e di supporto alla risoluzione dei problemi per applicazioni Windows esistenti.

• Analisi dei difetti e ricerca delle cause
• Consulenza tecnica e revisione del design
• Modifica e manutenzione di software Windows esistente
• Contatti

Riferimenti

</content>

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

È sicuro eseguire ProcMon in ambiente di produzione?

Una cattura di breve durata è una pratica comune nella realtà operativa, ma non è sicura in modo incondizionato. ProcMon carica un driver e registra un volume enorme di eventi, quindi su server con un alto tasso di generazione di eventi consuma in modo evidente CPU e memoria. Le contromisure sono tre: (1) avviare la cattura appena prima dell'operazione che riproduce il problema e fermarla subito dopo, riducendo al minimo il tempo di cattura; (2) se serve un monitoraggio prolungato, abilitare Drop Filtered Events nel menu Filter in modo da non trattenere gli eventi esclusi dal filtro; (3) impostare un Backing File in modo che la registrazione avvenga su file invece che in memoria. Si raccomanda inoltre di far rientrare l'operazione nello stesso processo di approvazione delle normali modifiche, ad esempio eseguendola fuori dall'orario lavorativo o dopo aver acquisito uno snapshot.

Ci sono troppi eventi e non riesco a trovare la riga che cerco. Come restringere la ricerca?

La prassi consolidata è applicare prima un Include su Process Name per isolare solo il processo target, e poi restringere su Result agli esiti anomali (NAME NOT FOUND, ACCESS DENIED, ecc.). Una volta trovata una riga rilevante, la si può restringere ulteriormente in modo interattivo tramite Include o Exclude accessibili con il clic destro su quella riga. Al contrario, capita spesso l'errore opposto: "ho salvato con il filtro attivo e mi mancavano informazioni". Se devi salvare il log su file e consegnarlo ad altri, ricorda che il filtro è solo una restrizione della visualizzazione: salva tutti gli eventi. Inoltre, le impostazioni del filtro vengono mantenute anche al riavvio successivo, quindi se "non viene mostrato nulla", verifica per prima cosa se è rimasto un vecchio filtro dalla sessione precedente usando Reset Filter nel menu Filter.

Il valore BUFFER OVERFLOW nella colonna Result è segno di un bug o di un attacco?

No. Non ha nulla a che vedere con l'attacco di sicurezza noto come buffer overflow: è semplicemente uno scambio API normale, in cui "i dati necessari erano più grandi del buffer preparato dal chiamante, quindi è stata restituita la dimensione richiesta". Molte API sono progettate per essere chiamate prima con un buffer piccolo per ottenere la dimensione necessaria, per poi essere richiamate di nuovo dopo aver allocato un buffer adeguato: se subito dopo compare un SUCCESS sullo stesso percorso, non c'è alcun problema. Allo stesso modo, anche NAME NOT FOUND è spesso solo il risultato di un passaggio intermedio nell'ordine di ricerca, e non è anomalo se alla fine si ottiene un SUCCESS da qualche parte. Un Result anomalo può essere considerato la causa solo dopo aver verificato che il fallimento di quella specifica operazione sia effettivamente collegato causalmente al sintomo dell'applicazione.

Come si scelgono Process Explorer e Process Monitor?

Process Monitor è lo strumento che registra in ordine cronologico "il flusso delle operazioni" (quando, quale processo, su quale percorso, cosa ha fatto e con quale esito), mentre Process Explorer è lo strumento che mostra "lo stato in questo preciso istante" (quali file o DLL ha aperto ciascun processo, l'utilizzo di CPU e memoria). Ad esempio, se vuoi sapere "non riesco a eliminare questo file, chi lo sta tenendo aperto", la ricerca degli handle di Process Explorer è la via più rapida; se invece vuoi sapere "quando e in quale ordine l'applicazione legge questo file", lo strumento giusto è Process Monitor. Nella pratica conviene tenere sempre entrambi a disposizione come parte della Sysinternals Suite, ricordando la regola pratica: lo stato con Process Explorer, la cronologia con Process Monitor.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.