Après avoir appelé un composant COM-dll, les exceptions C# ne sont pas interceptées par le débogueur

Question

J'utilise une DLL COM fournie par une société de logiciels tierce (je n'ai pas le code source). Je sais avec certitude qu'ils ont utilisé Java pour l'implémenter parce que leurs objets contiennent des noms de propriété comme 'JvmVersion'. Après avoir instancié un objet introduit par la DLL COM fournie, toutes les exceptions dans mon programme C# ne peuvent pas être interceptées par le débogueur VS et chaque fois qu'une exception se produit, j'obtiens le dialogue de débogueur Windows par défaut (Et c'est pendant l'exécution de mon programme en mode débogage sous un environnement de débogage VisualStudio complet).

À titre d'illustration:

throw new Exception("exception 1"); 
m_moo = new moo(); // Component taken from the COM-dll 
throw new Exception("exception 2"); 

Exception 1 sera pris par VS et montrent la "fenêtre d'exception jaune". Exception 2 ouvre une boîte de dialogue intitulée "Débogueur Just-In-Time Visual Studio" contenant le texte "Une exception win32 non gérée s'est produite dans myfile.vshost.exe [1348]." suivi d'une liste des instances VS existantes sur mon système à sélectionner.

Je suppose que l'instanciation de l'objet "moo" remplace le gestionnaire d'exceptions de C# ou quelque chose comme ça. Ai-je raison et existe-t-il un moyen de préserver le gestionnaire d'exceptions de C#?

Answer 1

Eh bien, ce n'est pas bon. Vous n'avez cependant pas encore prouvé que la logique de gestion des exceptions du CLR est complètement bloquée. Ce que vous décrivez peut aussi s'expliquer par quelque chose qui détache le débogueur. La JVM Java serait certainement candidate. Vérifiez si un essai fonctionne toujours, si vous avez encore une chance d'utiliser ce serveur COM.

Le débogage va cependant être douloureux. Avec un peu de chance, le détachement n'arrive qu'une seule fois. Essayez d'écrire System.Diagnostics.Debugger.Break() après le premier appel au serveur, cliquez sur "Debug" sur la boîte de dialogue que vous obtiendrez.

Également tester si une exception de référence nulle fonctionne encore, c'est une exception matérielle qui est susceptible d'être redirigée par une VM appelant SetUnhandledExceptionFilter() de Windows. Si cela ne peut pas être détecté, vous ne devriez pas utiliser ce serveur COM tel quel, cela déstabiliserait trop votre processus. L'exécuter dans un processus séparé et en parler avec WCF ou Remoting est un mouvement de désespoir qui pourrait fonctionner. Inutile de dire que ce fournisseur de composants viole gravement le contrat de serveur COM.

Vous ne devriez pas avoir à supporter ça.

Answer 2

ajoutant la ligne suivante (la première ligne) dans ma main() (dans le fichier Program.cs) fait exception fonctionnent à nouveau:

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); 

La ligne ci-dessus overides le gestionnaire automatique qui (je suppose) pour une raison quelconque cessé de travailler après l'utilisation du composant COM.