Gestione delle eccezioni di arresto per Win32/C++

Question

Ho un processo che gestisce le eccezioni alla grande.Chiama:

_set_se_translator(exception_trans_func); 
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit

Ogni volta che si verifica un'eccezione, viene chiamato uno dei gestori che crea per me un crash dump.La vita è bella.

Tranne che presso la sede di un cliente.Quando arrestano il processo, si verifica un'eccezione che per qualche motivo non viene instradata attraverso queste chiamate e viene visualizzato l'errore:

L'istruzione in "0x101ba9df" faceva riferimento alla memoria in "0x00000004".Non è stato possibile "leggere" la memoria.Fare clic su OK per terminare...."

Il riferimento alla memoria di x000000004 sembra probabilmente un puntatore null.E guardando quell'indirizzo appare per essere il distruttore di un oggetto STL globale (probabilmente nella chiamata initterm di CRT in cui i globali vengono ripuliti).

In questo momento sono un po' bloccato, dato che non riesco a ottenere un dump diagnostico e uno stack di chiamate e vedere esattamente cosa sta succedendo.COSÌ....

Perché l'eccezione non viene instradata attraverso i gestori di cui sopra e invece viene mostrata all'utente?

Esiste un modo per nascondere quella finestra di dialogo (poiché a quel punto non viene fatto alcun danno)?

E c'è un modo per rintracciare l'errore di root?

Grazie per qualsiasi idea.

Answer 1

Quale sistema operativo che in esecuzione?

Presumo si sta impostando la modalità di errore usando qualcosa come

::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);

per fare in modo che le finestre non sta saltando in con la propria gestione degli errori?

Answer 2

Sembra che CRT abbia inserito un blocco try/catch SEH (non è possibile scriverlo correttamente, Markdown entra in azione) attorno a un pezzo di codice e sta rilevando l'eccezione per visualizzare il messaggio, quindi non finisci mai per chiamare il non gestito percorso del codice di eccezione.Potrebbe essere necessario eseguire qualche hacking CRT per capire cosa sta succedendo.

Answer 3

potrebbe essere che il codice STL viene eseguito durante la distruzione di variabili globali in fase di chiusura del programma e forse (a seconda della versione del STL che si sta utilizzando) alcune variabili globali che essa richiede sono già stati distrutti.

Ho visto questo con STL di VS2008. Ci sono alcuni oggetti di blocco STL che vengono creati tramite un livello di file statici durante l'avvio.

Stai usando STL nelle funzioni del gestore di errore? Potrebbe essere che uno di questi sta andando fuori a tarda chiusura del programma e la causa del problema.