Arrêter la gestion des exceptions pour Win32 / C ++

Question

J'ai un processus qui gère les exceptions grandes. Il appelle:

_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

Chaque fois qu'une exception se produit, l'un des gestionnaires est appelé ce qui crée un vidage sur incident pour moi. La vie est bonne.

Sauf sur un site client. Quand ils arrêter le processus, il y a une exception qui ne passe pas par ces appels pour une raison quelconque, et ils obtiennent l'erreur:

L'instruction à "0x101ba9df" mémoire à "0x00000004". La mémoire n'a pas pu être lue". Cliquez sur OK pour terminer .... "

La référence mémoire de x000000004 ressemble il est probablement un pointeur NULL. Et regardant cette adresse apparaît pour un destructor de l'objet global STL (probablement dans l'appel initterm du CRT où sont nettoyés GLOBALS).

En ce moment je suis un peu coincé bien que je ne peux pas obtenir une pile de vidage et appel de diagnostic et de voir exactement ce qui se passe. Alors ....

Pourquoi ne pas l'exception étant acheminée par les gestionnaires ci-dessus, et étant affiché à la place de l'utilisateur?

Est-il possible de cacher cette boîte de dialogue (car aucun mal est fait à ce moment-là)?

Et est-il un moyen de traquer l'erreur racine?

Merci pour toutes les idées.

Answer 1

Quel système d'exploitation sont-ils en cours d'exécution?

Je suppose que vous configurez le mode d'erreur en utilisant quelque chose comme

::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);

pour vous assurer que les fenêtres ne saute pas avec sa propre gestion des erreurs?

Answer 2

Cela sonne comme le CRT a mis un bloc try / catch SEH (ne peut pas écrire correctement, Markdown entre en jeu) autour d'un morceau de code, et attrapant l'exception pour afficher le message, de sorte que vous ne finissent jamais par appeler unhandled chemin de code d'exception. Vous pourriez avoir à faire quelques bidouillages CRT pour savoir ce qui se passe.

Answer 3

Il est possible que le code STL est en cours d'exécution lors de la destruction des variables globales au moment de l'arrêt du programme et peut-être (selon la version de STL que vous utilisez) des variables globales dont elle a besoin ont déjà été détruits.

Je l'ai vu avec la STL de VS2008. Il y a des objets de verrouillage STL qui sont créés par un niveau de fichier statique lors du démarrage.

Vous utilisez STL dans vos fonctions de gestionnaire d'erreur? Il se pourrait que l'un d'entre eux va de la fin de l'arrêt du programme et la cause du problème.