Nous avons une application C ++ non gérée qui utilise des API tierces pour lire des fichiers CAO. Sur certains fichiers CAO corrompus, la bibliothèque 3ème partie se bloque et apporte notre exe avec elle. Pour cette raison, notre application principale est une exe distincte et de cette manière, elle ne s'affiche pas par le crash. Howeverver, nous finissons avec des dialogues d'erreur d'erreur Microsoft gênants.
Je ne veux pas désactiver l'ensemble du système de rapport d'erreur Microsoft. Existe-t-il un moyen d'éteindre les rapports d'erreur pour une seule application, de sorte que, si elle se bloque, elle se bloque silencieusement sans dialogues de contextuels d'erreur?
5 Réponses :
Je ne suis pas du tout sûr, mais peut-être seterrormode ou setthreaderormode fonctionnera pour vous?
Remarque supplémentaire, si cette crash est dû à une exception structurée non manquée (violation d'accès, débordement de pile, etc.), vous souhaiterez peut-être examiner à l'aide de gestionnaires d'exception structurés. Vous pouvez les utiliser pour enregistrer des informations et une crash silencieusement ou tout ce que vous voudrez peut-être faire.
sur Vista et ci-dessus, le WERADDEXCOUREDApplication La fonction API peut être utilisée exclure une application spécifiée exécutable du rapport d'erreur. Pour autant que je sache, il n'y a pas d'option similaire sur XP et d'autres versions OS OS.
Cependant, étant donné que WER n'entraînera que sur des exceptions d'application non gérées, vous devriez être capable de le supprimer en ajoutant un gestionnaire d'exception "attrape-tout" à votre exe. Voir manipulation des exceptions vectorisées pour quelques idées sur la façon dont pour atteindre cela.
Notez que supprimer toutes les exceptions non fabriquées est généralement une mauvaise idée (et, par exemple, car votre application échoue à la certification de logo Windows), vous ne devez donc pas utiliser cette technique sans discernement ...
Ouais, il y a quelque chose que vous pouvez faire. Call SetunhandleXceptionFilter () dans votre méthode principale () pour enregistrer un rappel. Il sera appelé lorsque personne ne fait du bénévolat pour gérer l'exception, juste avant que la boîte de dialogue Microsoft Wer apparaisse.
Faites en réalité quelque chose dans ce rappel d'avoir des ennuis. Le programme est mort avec, invariablement, quelque chose de méchant comme une exception d'accèsViolation. Qui est souvent déclenché par la corruption du tas. Essayer de faire quelque chose comme Affichage d'une boîte de message pour que l'utilisateur sache est gênant lorsque le tas est grillé. L'impasse est toujours caduque autour du coin aussi, prête à enfermer le programme sans aucun diagnostic du tout.
La seule chose sûre à faire est d'avoir un processus d'assistance qui protège votre processus principal. Réveillez-vous en signalant un événement nommé dans votre rappel. Donnez-lui les informations d'exception dont il a besoin avec un fichier mappé de mémoire. L'assistant peut faire à peu près tout ce qu'il veut quand il voit l'événement signalé. Y compris montrant un message, prenant un minidup. Et mettre fin au processus principal.
Quelle est exactement comment fonctionne l'aide de Microsoft Werfault.
Les UEFS sont problématiques et peu fiables en général. Il y a quelques cas rares quand ils ne sont pas rappelés par le système, même quand ils devraient être. De plus, ils sont globaux et peuvent être remplacés par des extensions de shell cheeky, des bibliothèques 3ème partie, etc. Calling WeraddexCludedApplication (proposé par l'utilisateur "MDB") ou appelant seterrormode avec avec avec avec SEM_NOGPFAULTERRORBOX (proposé par l'utilisateur "Jan Goyvaerts") est à la fois plus robuste.
La réponse de Hans Passant sur SetunhandleFrateFilter est sur la bonne voie. Il fait également de bons points à propos de ne pas être capable de ne pas trop faire dans le rappel, car diverses parties du processus pourraient être dans un état instable.
Cependant, de la manière dont le problème est décrit, cela ne sonne pas comme vous Voulez-vous faire quoi que ce soit, sauf indiquer au système de ne pas mettre en place la boîte de dialogue Crash Normal. Dans ce cas, il est facile et devrait être en sécurité quelles que soient les parties du processus que l'accident peut avoir affecté. P>
Faire une fonction comme ceci: p>
SetUnhandledExceptionFilter(UnhandledExceptionCallback);
Cela ne fonctionne pas, rien n'a été traité. Il suffira de redémarrer l'instruction erronée à nouveau, écrasant de la même manière. Boucle sans fin.
Certes, j'ai écrit cela en fonction d'une combinaison de mémoire et d'un extrait de certains vieux code qui n'était plus en mesure de tester cela. Mais je viens de le mettre dans un programme de test rapide que j'ai passé un crash en essayant d'utiliser un pointeur NULL et qu'il semble fonctionner comme prévu. Je vois que ça se termine silencieusement, pas de boucle. Ce ne serait-il pas exceptionnel_continue_execution qui le fait reprendre sur l'instruction erronée?
Si je ne me trompe pas, il ne sert à rien de vérifier un débogueur dans votre rappel UEF ( isdebuggerpresent ), car ils ne sont pas rapportés du tout lorsqu'un débogueur est présent.
Je me suis retrouvé dans cette situation tout en développant une application Delphes. J'ai constaté que j'avais besoin de deux choses pour supprimer de manière fiable la boîte de dialogue "APP ont cessé de fonctionner".
appeler Pour supprimer le gestionnaire d'exception de Delphi, j'appelle Donc, le squelette d'une application client DelphI qui exécute le code sujettes aux chocs devient: SETERRORMODE (SEM_NOGPFAULTERRORBOX); supprime la boîte de dialogue "APPORT ARRÊTEUR TRAVAILLE". Mais le gestionnaire d'exception de Delphi montre une boîte de message avec un message d'erreur d'exécution à la place. setunhandleXceptionFilter avec un gestionnaire personnalisé qui termine le processus en appelant HALT .
Pour Visual C ++ dans de nombreux cas, il suffit d'utiliser la SETERRORMODE (SEM_NOGPFAULTERRORBOX); suffit.