Heisenbug: il programma WinApi si arresta in modo anomalo su alcuni computer

Question

Per favore aiutatemi! Sono davvero alla fine del mio ingegno. Il mio programma è un piccolo gestore di note personali (google per " cintanotes "). Su alcuni computer (e ovviamente non ne possiedo nessuno) si blocca con un'eccezione non gestita subito dopo l'avvio. Non si può dire niente di speciale su questi computer, tranne che tendono ad avere CPU AMD.

Ambiente: Windows XP, Visual C ++ 2005/2008, WinApi non elaborato.

Ecco cosa è certo di questo "Heisenbug":

1) L'arresto anomalo si verifica solo nella versione di rilascio.

2) L'incidente scompare non appena rimuovo tutto ciò che riguarda GDI.

3) BoundChecker non ha lamentele.

4) La scrittura di un registro mostra che l'arresto anomalo si verifica in una dichiarazione di una variabile int locale! Come potrebbe essere? Corruzione della memoria?

Qualsiasi idea sarebbe molto apprezzata!

AGGIORNAMENTO: sono riuscito a eseguire il debug dell'app in un "quotato difettoso" PC. I risultati:

" Eccezione non gestita su 0x0044a26a in CintaNotes.exe: 0xC000001D: Istruzione illegale. "

e interruzioni di codice su

0044A26A cvtsi2sd xmm1, dword ptr [esp + 14h]

Quindi sembra che il problema fosse nel " Generazione di codice / Abilita set di istruzioni avanzato " opzione del compilatore. Era impostato su " / arch: SSE2 " e andava in crash sui computer che non supportavano SSE2. Ho impostato questa opzione su " Non impostato " e il bug è sparito. Accidenti!

Grazie mille per l'aiuto !!

Answer 1

Quindi non si arresta in modo anomalo quando la configurazione è DEBUG Configuration? Ci sono molte cose diverse da una configrazione di RILASCIO: 1.) Inizializzazione di globali 2.) Codice macchina effettivo generato ecc.

Quindi il primo passo è scoprire quali sono le impostazioni esatte per ciascun parametro nella modalità RELEASE rispetto alla modalità DEBUG.

-AD

Answer 2

  

4) La scrittura di un registro mostra che l'arresto anomalo si verifica in una dichiarazione di una variabile int locale! come potrebbe essere? Corruzione della memoria?

Qual è il codice sottostante nell'eseguibile / assembly? La dichiarazione di int non è affatto un codice e come tale non può arrestarsi in modo anomalo. Inizializzi int in qualche modo?

Per vedere il codice in cui si è verificato l'incidente, è necessario eseguire quella che viene chiamata analisi post mortem.

Segnalazione errori di Windows

Se vuoi analizzare il crash, dovresti ottenere un dump del crash. Un'opzione per questo è registrarsi per la segnalazione degli errori di Windows - richiede un po 'di denaro (è necessario un ID di firma del codice digitale) e un po' di compilazione del modulo. Per ulteriori informazioni, visitare https://winqual.microsoft.com/ .

Ottieni il crash dump destinato a WER direttamente dal cliente

Un'altra opzione è quella di mettersi in contatto con un utente che sta vivendo il crash e ottenere direttamente da lui un dump di crash destinato a WER. L'utente può farlo quando fa clic sui dettagli tecnici prima di inviare l'arresto anomalo a Microsoft: qui è possibile verificare la posizione del file di dump dell'arresto anomalo.

Il tuo minidump

Un'altra opzione è quella di registrare il proprio gestore di eccezioni, gestire l'eccezione e scrivere un minidump ovunque si desideri. Una descrizione dettagliata è disponibile all'indirizzo Codice progetto Post-Mortem Debug della tua applicazione con Minidumps e Visual Studio. Articolo NET .

Answer 3

  

1) L'arresto anomalo si verifica solo nella versione di rilascio.

Di solito è un segno che stai facendo affidamento su un comportamento che non è garantito, ma sembra essere vero nella build di debug. Ad esempio, se si dimentica di inizializzare le variabili o si accede a un array fuori limite. Assicurati di aver attivato tutti i controlli del compilatore (/ RTCsuc). Controlla anche cose come fare affidamento sull'ordine di valutazione dei parametri della funzione (che non è garantito).

  

2) L'incidente scompare non appena rimuovo tutto ciò che riguarda GDI.

Forse è un suggerimento che stai facendo qualcosa di sbagliato con le cose relative a GDI? Stai usando le MANIGLIE dopo che sono state liberate, per esempio?

Answer 4

Scarica il Strumenti di debug per Windows . Impostare correttamente i percorsi dei simboli, quindi eseguire l'applicazione in WinDbg. Ad un certo punto, si romperà con una violazione di accesso. Quindi dovresti eseguire il comando "! Analizza -v " ;, che è piuttosto intelligente e dovrebbe darti un suggerimento su cosa non va.

Answer 5

La maggior parte dei bug di heisenbugs / solo rilascio sono dovuti a un flusso di controllo che dipende da letture da memoria non inizializzata / puntatori non aggiornati / estremità passate dei buffer, condizioni di gara o entrambi.

Prova a sostituire i tuoi allocatori in modo che azzerino la memoria durante l'allocazione. Il problema scompare (o diventa più riproducibile?)

  

La scrittura di un registro mostra che l'arresto anomalo si verifica in una dichiarazione di una variabile int locale! Come potrebbe essere? Corruzione della memoria?

StackTranslate.it! ;)

Answer 6

  

4) La scrittura di un registro mostra che l'arresto anomalo si verifica in una dichiarazione di una variabile int locale! Come potrebbe essere? Corruzione della memoria

Ho trovato la causa di numerosi "strani arresti anomali" per dereferenziare un this rotto all'interno di una funzione membro di detto oggetto.

Answer 7

Cosa dice l'incidente? Violazione di accesso ? Eccezione ? Questo sarebbe l'ulteriore indizio per risolverlo con

Assicurati di non avere precedenti danni alla memoria usando PageHeap.exe

Assicurati di non avere overflow dello stack (array CBig [1000000])

Assicurati di non avere memoria non inizializzata.

Inoltre è possibile eseguire la versione di rilascio anche all'interno del debugger, una volta generati i simboli di debug (non uguali alla creazione della versione di debug) per il processo. Scorri e vedi se ricevi avvisi nella finestra di traccia del debugger.

Answer 8

" 4) La scrittura di un registro mostra che l'incidente si verifica su una dichiarazione di una variabile int locale! Come potrebbe essere? Corruzione della memoria? & Quot;

Questo potrebbe essere un segno che l'hardware è effettivamente difettoso o è stato spinto troppo. Scopri se hanno overcloccato il loro computer.

Answer 9

Quando ottengo questo tipo di cose, provo ad eseguire il codice tramite gimpels PC-Lint (analisi del codice statico) mentre controlla diverse classi di errori su BoundsChecker. Se stai usando Boundschecker, attiva le opzioni di avvelenamento della memoria.

Citi CPU AMD. Hai esaminato se esiste una simile versione di scheda grafica / driver e / o configurazione in atto sui computer che si arrestano in modo anomalo? Si blocca sempre su queste macchine o solo occasionalmente? Magari esegui lo strumento Informazioni di sistema su queste macchine e vedi cosa hanno in comune,

Answer 10

Sembra una corruzione dello stack per me. Il mio strumento preferito per rintracciarli è IDA Pro . Ovviamente non hai tale accesso al computer dell'utente.

Alcuni controllori di memoria hanno difficoltà a rilevare la corruzione dello stack (se proprio così). Il modo più sicuro per ottenere quelli che penso sia l'analisi di runtime.

Ciò può anche essere dovuto alla corruzione in un percorso di eccezione, anche se l'eccezione è stata gestita. Esegui il debug con 'cattura eccezioni di prima possibilità' attivata? Dovresti il ??più a lungo possibile. Diventa fastidioso dopo un po 'in molti casi.

Puoi inviare a quegli utenti una versione controllata della tua applicazione? Dai un'occhiata a Minidump Gestisci quell'eccezione e scrivi una discarica. Quindi utilizzare WinDbg per eseguire il debug.

Un altro metodo è scrivere registri molto dettagliati. Crea un " Registra ogni singola azione " e chiedi all'utente di attivarlo e inviarlo anche tu. Scaricare la memoria nei registri. Dai un'occhiata a "_CrtDbgReport ()" su MSDN.

Buona fortuna!

EDIT:

Risposta al tuo commento: un errore in una dichiarazione di variabile locale non mi sorprende. L'ho visto molto. Di solito è dovuto a uno stack danneggiato.

Ad esempio, alcune variabili nello stack potrebbero correre oltre i suoi limiti. Dopodiché si scatena l'inferno. Quindi le dichiarazioni delle variabili dello stack generano errori di memoria casuali, le tabelle virtuali vengono danneggiate, ecc.

Ogni volta che ho visto quelli per un lungo periodo di tempo, ho dovuto andare a IDA Pro. Il debug dettagliato dello smontaggio del runtime è l'unica cosa che conosco che li ottiene davvero in modo affidabile.

Molti sviluppatori usano WinDbg per questo tipo di analisi. Ecco perché ho anche suggerito Minidump.

Answer 11

Prova Rational (IBM) PurifyPlus. Cattura molti errori che BoundsChecker non fa.