VS2008 Debugger ne rompt pas à l'exception non gérée

Question

Je rencontre un problème étrange avec mon vs débogueur. Lors de l'exécution de mon programme sous le débogueur vs, le débogueur ne rompt pas sur une exception non gérée. Au lieu de cela, le contrôle est renvoyé à VS comme si le programme se terminait normalement. Si je regarde dans l'onglet de sortie, il y a une exception de première chance listée juste avant la fin du thread.

Je comprends comment utiliser l'option "Exceptions". boîte du menu Débogage. Je vérifie la rupture des exceptions non gérées. Si je vérifie les exceptions de la première chance pour l’exception spécifique qui se produit, le débogueur s’arrêtera.

Cependant, je crois comprendre que le débogueur devrait également s’arrêter sur toutes les "exceptions non gérées". Il ne fait pas cela pour moi.

Voici les dernières lignes de mon onglet Sortie:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).

Je ne comprends pas pourquoi l'exception est les drapeaux en tant que "première chance". exception quand il n'est pas géré.

Je crois que le code de sortie 0xe0434f4d est une erreur COM générique.

Des idées?

Métro.

Answer 1

Si vous utilisez un système d’exploitation 64 bits, il y a de bonnes chances que vous soyez piqué par un comportement au niveau du système d'exploitation qui provoque la disparition des exceptions. Le moyen le plus fiable de le reproduire est de créer une nouvelle application WinForm qui lève simplement une exception dans OnLoad; il semblera ne pas être jeté. Jetez un coup d'œil à ceux-ci:

1. Visual Studio ne rompt pas avec une exception non gérée avec Windows 64 bits
   • http: // social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb
2. Le cas de l'exception OnLoad en train de disparaître
3. Exceptions silencieuses sur les machines de développement x64 (Microsoft Connect)
   • https: // connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

Le premier est ce que j'ai trouvé sur Google (après que ce fil n'ait pas aidé), et ce fil m'a conduit aux deux suivants. La seconde a la meilleure explication, et la troisième est le bogue / ticket Microsoft (qui réaffirme qu'il s'agit d'un comportement "de par sa conception").

Donc, si votre application lève une exception qui atteint une limite en mode noyau en remontant la pile, elle est bloquée à cette limite. Et l’équipe Windows a décidé que la meilleure façon de traiter ce problème était de prétendre que l’exception était gérée; l'exécution se poursuit comme si tout se déroulait normalement.

Oh, et cela se produit partout . Le débogage par rapport à la libération n'est pas pertinent. .Net vs C ++ n'est pas pertinent. C'est un comportement au niveau du système d'exploitation.

Imaginez que vous deviez écrire des données critiques sur le disque, mais elles échouent du mauvais côté d’une limite en mode kernal. Un autre code essaie de l'utiliser plus tard et, si vous avez de la chance, vous détectez un problème avec les données ... mais pourquoi? Je parie que vous ne considérez jamais que votre application n'a pas réussi à écrire les données, car vous vous attendiez à ce qu'une exception soit levée.

Jerks.

Answer 2

Lorsque je lis la réponse à propos de la présence de deux cases à cocher dans le champ "Exception ..." dialogue, je suis retourné et a ouvert le dialogue à nouveau. Je n'avais qu'une colonne de cases à cocher - pour la pause sur "Jetée".

Il se trouve que vous n'avez pas l'option "Activer uniquement mon code (géré uniquement)". cochée dans les options de débogage, l'option " non gérée par l'utilisateur " colonne n'apparaît pas dans le champ "Exceptions". dialogue.

J'ai sélectionné l'option "Activer uniquement mon code". option et vérifié que l'option " non gérée par l'utilisateur " Cochez la case "Exceptions". La boîte de dialogue a été sélectionnée pour toutes les catégories d’exceptions.

J'ai pu obtenir des exceptions non gérées pour entrer dans le débogueur pendant une session. Mais quand je suis revenu le lendemain, le comportement était comme avant.

Métro.

Answer 3

Ctl-D, E ouvre la fenêtre Exceptions. Vous pouvez définir les exceptions que vous souhaitez et que vous ne voulez pas interrompre.

Answer 4

Il y a deux cases à cocher dans les "Exceptions ...". case, je dois généralement les faire vérifier tous les deux pour le faire casser sur des exceptions non gérées. Indépendamment de cela, il se lit comme si vous deviez en vérifier un.

Answer 5

Cela m’arrive aussi une fois de temps en temps. Cela ressemble à un bogue ou à un problème, car lorsque je réplique le scénario, l’exception est interceptée et affichée comme d’habitude.

Answer 6

J'ai rencontré un problème similaire en cochant la case "Activer uniquement mon code (géré uniquement)". corrige le problème, alors que si je le désactivais, le problème revenait, on ne savait pas pourquoi (mais il est possible que certaines DLL qui semblent se charger lorsqu'elles ne sont pas cochées provoquent ce comportement).