Quali informazioni acquisite quando il software si arresta in modo anomalo sul campo?

Question

Sto lavorando per riscrivere il mio processo di gestione degli errori imprevisti e vorrei chiedere alla community:

Quali informazioni acquisite sia automaticamente che manualmente, quando il software che avete scritto si blocca?

In questo momento, mi catturano alcuni elementi, alcuni dei quali sono:

automatica:

1. Nome di app che si è schiantato
2. versione di app che si è schiantato
3. traccia Pila
4. Versione sistema operativo
5. RAM utilizzata dall'appli cazione
6. Numero di processori
colpo
7. schermo: (solo su applicazioni non pubbliche)
8. nome utente e le informazioni di contatto (da Active Directory)

manuale:

1. In quale contesto si trova l'utente (ovvero: quale azienda, numero di telefono dell'assistenza tecnica, numero RA, ecc ...)
2. Quando è stato fatto? l'utente si aspetta che accada? (Risposta tipica: "Non crash”)
3. Procedura per riprodurre

Quali altri bit di informazioni si fa a catturare che ti aiuta a scoprire la vera causa di un problema di applicazioni, soprattutto in considerazione che la maggior parte degli utenti semplicemente poltiglia. la tastiera quando gli viene chiesto di raccontare cosa è successo

per la cronaca sto usando C#, WPF e .NET versione 4, ma non necessariamente voglio limitarmi a quelli

correlati:.. What to: Collect Information When Software Crashes

Correlati: What should be included in the state-of-the-art error and exception handling strategy?

Answer 1

(Questo è un po di Windows/.NET specifico, ma questo è ciò che si è specificato nella domanda, e penso che questo sia informazioni molto utile in quel contesto.)

A meno che la vostra applicazione è rigorosamente single-threaded, si desidera un file di dettagli (che fornirà lo stack per tutti i thread, come minimo), non solo una traccia di stack per il thread che genera l'eccezione.

Generazione di una discarica che non è troppo grande e che ha informazioni sufficienti per darvi utili analisi dello stack gestito è un po 'complicato, ma c'è un programma di utilità molto utile chiamato clrdump che gestirà alcuni dei dettagli cruento per voi.

Clrdump è principalmente un wrapper per DbgHelp.dll di Microsoft. È possibile utilizzare direttamente DbgHelp, vedere this question, ma si otterrà un "minidump completo" che sarà grande quanto lo spazio degli indirizzi virtuali dell'applicazione, che può essere piuttosto ampio. Clrdump fa un buon lavoro nel creare un piccolo dump con solo le tracce dello stack più informazioni sufficienti per SOS per poterle leggere.

Answer 2

LA Transtar conserva anche un registro delle chiavi che viene salvato solo per guasti. Questo registro contiene l'input e una traccia del programma mentre procede. Il log viene ripristinato all'inizio di ogni nuova transazione.

Answer 3

Non si parla di registrazione del processo (come syslog in Linux, Event Viewer per Windows?). Dal momento che ho anche uno sfondo amministratore di sistema apprezzo davvero i programmi con una funzione di registrazione. Ancora meglio se è possibile selezionare il livello di verbosità.

È bene per voi sapere di più sull'ambiente ed è un bene per i vostri utenti se devono eseguire un qualche tipo di integrazione con altri strumenti.

Se gli utenti sono più tecnici, è possibile chiedere loro di impostare la verbosità di registrazione al massimo e riprodurre nuovamente l'errore.

Answer 4

Fondamentalmente, non esiste una regola d'oro che devi seguire e implementarla in ogni applicazione. A seconda dell'applicazione e dello scenario aziendale, sono diverse le cose più appropriate da includere per la raccolta di informazioni quando si verifica un errore.

Quelli che hai citato sono OK, ma ecco un po 'di più ciò che è buono essere registrato:

• parametri di input per operazioni critiche e complesse
• contesto del vostro programma - alcuni oggetti con algoritmi pesanti - il maggior numero di classi di rischio-possesso
• lo stato in cui è il tuo programma di

esempio: il flusso del programma è come un automi a stati e si dispone di 5 membri uno d si è raggiunto lo stato 3.

• se si dispone di un'applicazione che è server-client, raccogliere entrambi i registri - dal provider e assorbita

• dump della memoria non è generalmente un buon suggerimento - farlo solo quando è necessario comprendere i problemi nei framework o JVM (ad esempio) di cui non si ha il controllo. OutOfMemoryError per esempio

Answer 5

non vedo nella lista le informazioni più importanti (quando si parla di livello dotnet/java di codice).
Il tipo di eccezione, messaggio e traccia.
È possibile utilizzare un codice semplice, per rilevare qualsiasi eccezione e "scrivere sul registro"/"inviare direttamente all'e-mail".

Answer 6

E ora dal campo paranoia :(

considerare ciò che l'industria degli obiettivi del software. Gathering alcuna informazione sull'utente (anche attiva nome della directory) oppure la rete può ottenere il vostro app blackballed e potenzialmente porta la responsabilità. Ciò che vale a dire se il database dei bug è compromesso e tali informazioni vengono utilizzate per entrare in una banca o in una rete di laboratori governativi, si noterà la segnalazione di bug contenente i loro IP?

Ad esempio, se è necessario raccogliere dati specifici della rete per diagnosticare i problemi di rete, considerare di fare in modo che l'app sostituisca i nomi di sistema o IP con i segnaposto prima che i dati vengano reinviati. (emailSrvr1, bankAcctNumSrv, diventa srvr1 e srvr2) È un problema maggiore nel rintracciare i problemi, ma potrebbe valerne la pena. Questo cattura ancora informazioni che potrebbero metterti nei guai, ma potrebbe aiutarti.

Ho lavorato con aziende e governi di fascia alta per alcuni anni che colora la mia prospettiva, ma probabilmente vale la pena considerare ciò che si sta raccogliendo e come viene memorizzato.