Quali funzionalità sono utili quando si eseguono debug / diagnostici remoti?

Abbiamo due strumenti per gestire ciò in cui lavoro. Il primo è uno strumento di segnalazione delle eccezioni. Lo aggiungi al file di progetto e assicurati che il linker generi un file di mappa e, quando viene sollevata un'eccezione non gestita, raccoglierà informazioni, scriverà un file di errore e invierà un'e-mail a noi.

Il secondo è il logging. Creando un log di punti di esecuzione significativi, abbiamo una tabella di marcia su ciò che l'EXE stava facendo appena prima che si verificasse un errore, che può davvero aiutare a rintracciare i problemi.

Prova ad aggiungere queste due funzionalità al tuo progetto e verifica se non ti aiutano a rintracciare più facilmente gli errori sul sito del cliente.

Ci sono varie risposte a seconda del livello di controllo che hai sulla piattaforma di destinazione e della fiducia tra te e il cliente.

Se sei strettamente legato, potresti essere in grado di eseguire il debug remoto vero e proprio. Questo è improbabile che si verifichi.

Le tue opzioni si trasferiscono rapidamente per registrare file e crash-dump.

Probabilmente dovresti avere una sorta di framework di registrazione già presente nel tuo codice. Se non lo fai, scegli uno adatto alla tua lingua e al tuo ambiente. Rendilo utilmente commutabile tra vari livelli di registrazione. Presta attenzione a ciò che registri: ricorda che il debugging psichico verrà eseguito dalle stringhe che hai emesso nel registro.

In alternativa, puoi usare crash-dump, come i core dump su unix o minidump su windows. Questi memorizzano lo stato interno del tuo programma in un momento specifico. Puoi quindi caricarlo localmente in un debugger per vedere lo stato del tuo sistema prima che sia morto.

Spero che questo ti fornisca alcuni suggerimenti generali per iniziare.

In uno dei miei co-op ho lavorato su una piattaforma embedded sviluppata in c ++. Implementano alcuni metodi per specificare quali dati / variabili di classe potrebbero essere interessanti se il sistema si arresta in modo anomalo. Non sono esattamente sicuro di come l'hanno fatto, ma essenzialmente scarica tutti i dati marcati in modo che lampeggino quando il sistema si arresta, il che può essere estratto tramite una porta seriale e inviato al supporto.

Hai scaricato tutto che può in qualcosa che può essere inviato (facoltativamente) a te la prossima volta che viene eseguito. Questo è il modo migliore che posso descrivere per ottenere informazioni su ciò che è accaduto in modo da dedicare il minor tempo possibile al computer di un cliente.

Proprio come qualsiasi altra scienza, semplicemente osservare osservare le cose spesso ha un comportamento diverso dal normale. Vuoi davvero che il programma ti dica perché è morto.

Lavoro principalmente con i sistemi operativi UNIX, quindi i miei esempi potrebbero non essere una soluzione rapida, ma si spera che illustrino il modo di pensare:

• Gestire qualsiasi segnale o errore fatale che è possibile gestire e registrarlo quando appropriato. Devi sapere perché un programma (o il suo kernel) ha deciso che non c'era più alcun punto in cui vivere.
• Avere "cose strane" ma non fatali nel tuo programma avverte l'utente che il logging aggiuntivo avrà luogo e che le cose non sembrano andare come previsto. Ciò aiuta a risparmiare la fiducia degli utenti riducendo il prelievo di cervelli dai fornitori.
• Quando chiedi agli utenti se vogliono inviare segnalazioni di errore, specifica in particolare "Ciò potrebbe comportare una correzione per l'emissione di questo problema a breve", e assicurarti che le correzioni ne vengano la maggior parte del tempo. Non dirlo come "Questo ci aiuta migliorare ", poiché questo è un problema agnostico e non quello che un utente irato vuole vedere.
• Se possibile, usa il checkpoint. Ciò ti consente di riprodurre e ricreare il problema fino a quando non viene risolto. Nel giorno e nell'età della virtualizzazione, questa sta diventando una possibilità più ampia.
• Comprendi che i clienti tendono a "ripulire" un po 'prima di offrire il loro PC a qualcun altro. Potrebbe non essere possibile riprodurre il problema, anche sul proprio computer. Mi chiedo solo che cosa non è lì prima.

Devi essere trasparente quando raccogli i dati, ma rimarrai sbalordito da ciò che le persone ti daranno se riesci a convincerli che farlo è un loro vantaggio immediato.