HRException au démarrage de mon application C# WPF

Question

J'ai une application C# WPF qui lance soudainement une exception au démarrage, et je n'arrive pas à comprendre pourquoi.

L'exception est une HRException C++, et il se produit dans MSCORLIBCreateInstanceSlow() à, qui est appelé à partir de CreateInstance(), qui est appelé à partir de BamlRecordReader.CreateInstanceFromType() dans l'ensemble System.Windows.Markup.

J'ai déplacé tous mes assemblys de cette application, ainsi qu'une bibliothèque tierce que je venais juste de mettre à jour, et j'ai finalement fait redémarrer l'application (même si c'était juste un shell). Puis j'ai ajouté la librairie tierce partie, sans problème, puis j'ai réintégré chacune de mes assemblées, en les ajoutant comme référence, et en déclarant une variable d'un type défini dans cette application dans mon application principale, et cela a fonctionné. OK. J'ai donc soufflé tout ça et je suis retourné à ce qui a été archivé, et je suis de nouveau à l'exception, donc je ne pense pas que ce soit une DLL qui ne peut pas être trouvée, ou une qui gonfle à l'initialisation - mais Je ne peux pas comprendre ce que c'est.

J'ai essayé de descendre la callstack et de regarder dans les fonctions d'analyse, mais le débogueur m'indique que je ne peux pas examiner la plupart des variables en raison d'un cadre natif en haut de la pile.

J'apprécierais vraiment des conseils sur comment faire pour savoir ce que XAML est réellement analysé lorsque l'exception est levée, ainsi que d'entendre toute autre personne qui a eu des problèmes similaires.

Answer 1

Je commencerais par VS qui a suivi le débogage natif et géré activé, et un serveur de symboles de travail. Cela devrait au moins permettre une trace de pile. Une autre option pourrait être de forcer un processus de doublage et d'utiliser WinDBG (avec beaucoup de lecture de blog/livre qui couvrent ce genre de débogage).

De même, le chargement XAML est-il le wrapper le plus simple possible (c'est-à-dire juste assez pour utiliser une instance de XamlReader)?

Answer 2

Bien que j'apprécierais toujours des conseils sur la façon de déboguer ces exceptions, j'ai été capable de dépister celui-ci. Un de mes DLL a utilisé une classe d'une autre DLL, qui était construite incorrectement (bien que je ne sois pas encore sûr pourquoi). Une fois que j'ai pu reconstruire cette DLL et celle qui l'a consommée, puis reconstruire mon application, tout a fonctionné. Mais ce qui est frustrant, c'est que je poignardais aveuglément dans l'obscurité, en utilisant des essais et des erreurs pour déterminer quelle DLL (et quelle classe dans cette DLL) causait le problème. Et la seule chose que le système pouvait me dire était qu'il y avait une sorte d'erreur dans un XAML quelque part. Je devrais mentionner que ces assemblys que j'utilisais dans mon application C# étaient écrits en C++/CLI et contenaient du code C++ natif - mais je ne pense pas que c'était vraiment un problème d'interopérabilité. Donc, de toute façon, des conseils supplémentaires sur la façon de vraiment comprendre ce qui est vraiment faux serait grandement apprécié!