Individuare i crash delle applicazioni con CMPivot in SCCM

Perché CMPivot è utile quando un’applicazione crasha

Quando un’applicazione va in crash su più postazioni, il problema non è quasi mai la mancanza di un singolo evento. Il punto debole è il tempo: i log ci sono, ma arrivano tardi, sono distribuiti su decine o centinaia di endpoint e spesso raccontano solo metà della storia. CMPivot, dentro Microsoft Configuration Manager, serve proprio a ridurre questa latenza operativa. Invece di aspettare report aggregati o esportazioni manuali, interroghi i client attivi e raccogli in pochi minuti indizi concreti su processi, eventi, servizi, patch, spazio disco e stato generale del sistema.

Qui l’obiettivo non è “fare forensics completa”, ma trovare rapidamente il punto di rottura: il crash è isolato a una versione specifica? Coinvolge un modello di PC? È legato a un aggiornamento recente, a un driver, a un servizio dipendente o a un profilo utente corrotto? CMPivot non sostituisce i log applicativi, però ti porta subito al sottoinsieme di macchine che meritano attenzione.

Il tipo di evidenza che conviene cercare prima

Per un crash applicativo, la priorità è distinguere tra sintomo e causa probabile. Se l’applicazione si chiude senza messaggi, gli indizi utili sono spesso laterali: processi terminati in modo anomalo, eventi Application Error, .NET Runtime, Windows Error Reporting, code di servizio bloccate, riavvii del processo in loop, fault su moduli DLL, memoria esaurita o file mancanti dopo un update fallito. CMPivot non legge tutto il contenuto del sistema come un EDR, ma ti permette di chiedere ai client cose molto specifiche e molto veloci da filtrare.

La logica corretta è questa: prima individui la popolazione impattata, poi cerchi un pattern tecnico ripetibile. Se il crash compare solo su una build di Windows, su una versione di applicazione o su una OU particolare, hai già tagliato gran parte del rumore. Se invece il problema è diffuso e non segue una distribuzione chiara, conviene fare un primo giro su eventi, processi e software installato prima di toccare configurazioni.

Query CMPivot che danno valore subito

Il vantaggio pratico di CMPivot è che puoi partire da query semplici e renderle più strette in base ai risultati. Non serve costruire subito una vista perfetta: serve una foto affidabile.

Una prima query utile è quella sui processi. Se l’app crasha ma il processo si riapre, o scompare subito dopo l’avvio, puoi verificare su quali client il processo esiste davvero e con quale frequenza viene osservato. In ambienti dove l’app è gestita da un servizio Windows, è utile controllare anche lo stato del servizio e l’eventuale restart automatico.

Processes | where Name == 'NomeApp.exe'

Se vuoi capire se l’app è in esecuzione solo in modo intermittente, puoi arricchire il filtro con il percorso o con l’utente che la avvia, quando il contesto lo richiede. Il punto non è la sintassi perfetta in astratto, ma la capacità di restringere i client che mostrano il binario e quelli che non lo mostrano affatto.

Il secondo blocco di controllo riguarda gli eventi di sistema e applicazione. Qui cerchi le firme classiche dei crash: Application Error, faulting module, .NET Runtime, Windows Error Reporting. Il valore non sta nel singolo evento, ma nella ripetizione su più endpoint nello stesso intervallo temporale.

Events | where EventLog == 'Application' and (EventID == 1000 or EventID == 1001 or EventID == 1026)

Se l’app è .NET, EventID 1026 è spesso un buon punto di partenza. Se è una componente nativa, il 1000 e il 1001 aiutano a vedere il modulo che ha causato il fault e il bucket WER. Non basta leggere il codice evento: serve confrontare il nome del processo, il modulo e il timestamp con la finestra del problema segnalata dagli utenti.

Un terzo filtro molto pratico è la versione del software installato. Quando i crash iniziano dopo un rollout, la differenza tra client sani e client rotti spesso è una sola release. Se l’app è distribuita con SCCM, CMPivot ti consente di verificare rapidamente chi ha ancora la build precedente e chi ha già ricevuto quella nuova.

InstalledSoftware | where ProductName contains 'NomeApp'

In scenari più sporchi, conviene incrociare anche patch recenti, driver e uptime. Un crash apparso subito dopo un aggiornamento cumulativo o dopo una modifica al driver video, stampante o storage non va trattato come coincidenza finché non hai escluso la correlazione temporale.

Come leggere i risultati senza farsi ingannare

Con CMPivot è facile raccogliere molti dati e costruire una falsa sensazione di controllo. Il rischio classico è confondere “molti client rispondono” con “abbiamo capito il guasto”. In realtà servono tre domande semplici: quali macchine mostrano il crash, cosa hanno in comune e cosa manca ai client sani.

Se il crash riguarda solo un gruppo ristretto, la lettura più utile è per cluster: stessa OU, stesso modello hardware, stessa immagine, stesso pacchetto applicativo, stesso profilo utente o stessa subnet. Se il problema segue il modello hardware, la pista è spesso driver o firmware. Se segue la versione software, la pista è il deploy. Se segue l’utente, i temi tipici sono profilo, permessi, cache locale o dati applicativi corrotti.

Un esempio concreto: l’applicazione si chiude subito dopo l’apertura solo sui notebook con SSD quasi pieno. In CMPivot puoi verificare lo spazio disco e il processo, e noti che i client col crash hanno meno margine libero rispetto ai client sani. In quel caso il crash non è “misterioso”: l’app ha bisogno di cache o file temporanei che non riesce a scrivere. La correzione strutturale non è riavviare il PC, ma liberare spazio e correggere il comportamento della cache o del profilo.

Altro caso frequente: un crash appare dopo un update dell’app, ma solo su macchine con una vecchia DLL condivisa in `System32` o in una directory applicativa. CMPivot può non dirti direttamente che la DLL è sbagliata, ma può mostrarti la separazione netta tra client aggiornati e client che conservano componenti vecchi. A quel punto la verifica successiva va fatta sui log dell’app o sui pacchetti distribuiti.

Workflow operativo: dal segnale al gruppo impattato

Il flusso più efficace è lineare. Prima definisci la finestra temporale del crash, poi fai una query ampia, poi stringi. Cercare subito il dettaglio perfetto spesso fa perdere tempo, perché il dettaglio giusto emerge solo dopo aver visto il pattern generale.

1. Parti da una collezione limitata o da un sottoinsieme noto di client che hanno riportato il problema.
2. Interroga processi, eventi e software installato nella stessa finestra oraria del crash.
3. Confronta i client colpiti con un gruppo di controllo sano: stessa area, stessa versione, stesso hardware se possibile.
4. Se emerge una correlazione, verifica il dettaglio fuori da CMPivot con i log locali dell’applicazione o con l’Event Viewer.
5. Solo dopo, decidi se il problema richiede rollback, hotfix, reinstallazione o correzione di configurazione.

Questa sequenza evita il classico errore: cambiare qualcosa troppo presto. CMPivot è ottimo per ridurre l’incertezza, non per sostituire la diagnosi. Se fai rollback di un pacchetto senza aver capito il pattern, rischi di peggiorare la situazione o di nascondere il vero difetto sotto una mitigazione temporanea.

Quando il crash è un problema di servizi o dipendenze

Non tutti i crash sono crash dell’eseguibile principale. In ambienti Windows molte applicazioni dipendono da servizi ausiliari, componenti COM, runtime .NET, agent di stampa, driver filtro o database locali. Se uno di questi elementi fallisce, l’utente vede solo “l’app si chiude”. CMPivot aiuta a controllare se il servizio è attivo e se il problema è sistemico.

Se l’app gira come servizio, la query sui servizi è spesso più utile del solo processo. Un servizio che entra in stop/restart in modo ripetuto è un segnale molto forte, soprattutto quando l’errore compare all’avvio o al login dell’utente.

Services | where Name contains 'NomeServizio'

Se il servizio non esiste su alcuni client, il problema potrebbe essere una distribuzione incompleta. Se esiste ma non parte, la causa può essere una dipendenza mancante, un account di servizio non valido o un file binario danneggiato. A quel punto il passo successivo non è “riprovare”, ma controllare i log del servizio e l’event viewer per l’errore preciso.

Uso corretto in un incidente: rapidità sì, improvvisazione no

In un incidente reale, CMPivot va usato come strumento di triage. Non è il posto giusto per fare tuning profondo, ma è il posto giusto per prendere decisioni veloci con un livello di confidenza accettabile. Se il crash impatta utenti attivi, il criterio è ridurre il blast radius: identificare il gruppo impattato, evitare modifiche globali e intervenire prima sul segmento più probabile.

Un approccio sensato è questo: se il crash coincide con una nuova release, sospendi la distribuzione e verifica i client già aggiornati. Se il crash segue un update OS, separa i client per build e valuta il rollback solo dopo aver confermato la correlazione. Se il problema è confinato a una OU o a un modello, l’intervento va limitato a quel perimetro finché non hai chiuso la causa.

La metrica da guardare non è solo “quanti crash”, ma anche la riduzione del numero di endpoint sospetti dopo ogni query. Se da 300 client passi a 18, hai già fatto un salto utile. Se restano 300 e non emerge alcuna differenza, il problema potrebbe essere a livello di applicazione centrale, di rete o di servizio condiviso, e CMPivot da solo non basta.

Limiti pratici da conoscere prima di fidarsi troppo

CMPivot dipende dalla raggiungibilità dei client e dallo stato dell’agente. Se il client SCCM è rotto, offline o non aggiornato, il dato può essere incompleto. Inoltre, alcune evidenze che servono davvero per un crash serio non sono esposte in modo diretto: dump memory, stack trace completi, parametri applicativi e log custom spesso restano fuori dal perimetro di CMPivot.

Questo non è un difetto dello strumento, è il suo ruolo. Il valore sta nel primo taglio della ricerca. Quando sospetti un bug applicativo vero e proprio, la chiusura del cerchio passa quasi sempre da log locali, Event Viewer, file di dump o telemetria dell’applicazione. CMPivot ti dice dove guardare, non sempre cosa correggere.

Un altro limite è la qualità del dato. Se i nomi dei processi cambiano tra versioni, se l’app usa launcher diversi o se il crash avviene prima dell’avvio del processo principale, devi adattare la query. In questi casi conviene basarsi su eventi e software installato più che sul solo nome del binario.

Una strategia robusta per i team di supporto

La pratica migliore è preparare in anticipo un piccolo set di query standard: processo, eventi applicativi, servizi, software installato, patch recenti e spazio disco. Così, quando arriva la segnalazione, non devi inventare la diagnostica sotto pressione. Il tempo guadagnato lo spendi per interpretare i risultati, non per riscrivere la query da zero.

Per i team che gestiscono incidenti ricorrenti, conviene anche documentare i pattern emersi: quale EventID compare, quale versione è coinvolta, quale hardware è esposto, quale fix ha funzionato. Dopo due o tre casi simili, CMPivot diventa una scorciatoia operativa molto concreta, perché ti permette di trasformare una segnalazione vaga in un perimetro tecnico preciso.

Il punto non è usare più strumenti, ma usarli nell’ordine giusto. CMPivot per restringere, Event Viewer e log applicativi per confermare, poi remediation mirata. È una sequenza semplice, ma in produzione è spesso quella che fa la differenza tra una diagnosi in mezz’ora e una giornata persa a inseguire sintomi generici.

Assunzione operativa: i client sono gestiti da Microsoft Configuration Manager con CMPivot disponibile e gli eventi locali sono accessibili sul sistema endpoint.