Bonjour à tous,
 
J'ai un problème un peu spécial, que je n'ai pas la moindre idée de comment résoudre...
 
Je travaille sur une application assez complexe, composée d'un tas de threads différents. Parfois, cette application plante (et oui, ça arrive). Quand c'est le cas, j'obtiens la fenêtre Windows de plantage, avec l'adresse mémoire concernée, etc.
 
Le problème, c'est quand tant que cette fenêtre Windows n'est pas fermée, tous les autres threads de l'application continuent de fonctionner normalement. C'est un problème car cette application effectue un travail critique. En cas de plantage, il faut la redémarrer.
 
Donc, questions :
1. Est-ce que c'est normal que tant qu'on ne ferme pas la fenêtre Windows de plantage, le reste de mon application continue de tourner ?
2a. Si non, à quoi est-ce que ça pourrait être dû ?
2b. Si oui, comment faire pour détecter le plantage / faire planter l'application complètement ?
 
Help me Obi-Wan Kenobi, parce que là je pédale dans la semoule !

 
1. Oui, c'est tout à fait normal. Lorsque ton thread execute une mauvaise instruction, l'exception CPU est capturée par l'OS qui t'affiche le dialogue, sans déranger les autres threads. Ce n'est que lorsque tu fermes le dialogue que le processus est détruit.
2. Deux façons d'empécher ça :

• Désactiver le rapport d'erreur en cas de crash (http://answers.google.com/answers/threadview/id/433370.html). C'est un peu violent dans la mesure où plus aucun rapport ne sera généré.
• Une autre méthode que j'utilise avec MinGW (il doit certainement y avoir la même chose pour Visual Studio ou autre), c'est d'intercepter les exceptions CPU avant Windows. Dr MinGW fournit une dll (exchndl.dll), qui si elle est chargée au démarrage du programme (LoadLibrary("exchndl.dll" )), va intercepter les exceptions, te créer un fichier texte .RPT au niveau de l'application et faire un stacktrace, puis terminer le programme. Edit: ça ne fonctionne qu'avec MinGW, car la dll ne sait lire que les blocs de debug de gcc.

Merci de la réponse. En fait entre temps j'ai découvert la fonction SetUnhandledExceptionFilter() qui permet de définir un comportement spécifique au lieu d'appeler le "debugger" (le générateur de rapport d'erreur) Windows standard.
 
Je suis encore en train de tester, mais ça a l'air de me permettre de faire exactement ce que je veux : générer un rapport (via MiniDumpWriteDump) et tuer l'application.