Comment puis-je réparer une application Windows .NET qui plante au démarrage avec le code d'exception : 0xE0434352?

Question

J'ai construit une application .NET Windows Forms dans Visual Studio 2010. J'ai également construit un package d'installation correspondant via Visual Studio 2010. Il s'agit d'une application 32 bits (x86). (Nous utilisons des contrôles Windows Forms tiers qui sont uniquement en 32 bits).

Je suis capable d'exécuter le package d'installation et de le déployer avec succès sur d'autres environnements Windows 7 64 bits et des boîtes Windows XP 32 bits. L'application installée fonctionne correctement sur ces environnements.

Cependant, lorsque j'essaie d'exécuter Windows Server 2008 R2 - 64 bits, l'application se bloque au démarrage. Elle s'est installée avec succès via l'installateur sans aucune erreur.

Il semble qu'elle se bloque lors du chargement de l'application. J'ai mis une boîte de message en tant que première ligne de l'application pour voir si elle passait le chargement. La boîte de message n'apparaît pas, donc je suppose que cela se produit pendant le chargement/l'initialisation de l'application.

Jusqu'à présent, je n'ai pas trouvé beaucoup d'indications. À partir des Détails, je vois ce qui suit :

Code d'Exception : E0434352

J'ai fouillé un peu/googlé pour voir s'il y avait quelque chose d'évident, mais je n'ai rien vu. J'ai vu quelques références à un possible débordement de pile dans le CLR.

L'application Windows Forms est construite avec les références suivantes :

• DevExpress
• Contrôles Winforms Infragistics
• ORACLE DataAccess DLL
• RabbitMQ

Quel est le problème ? Comment puis-je aborder la résolution de ce problème ? Comment puis-je déboguer pour obtenir des informations plus utiles ?

Answer 1

Alors j'avais remarqué dans l'observateur d'événements que ce plantage correspondait à une erreur de "System.IO.FileNotFoundException".

Alors j'ai lancé ProcMon et j'ai remarqué qu'une des dll du programme échouait à charger vcruntime140. Alors j'ai simplement installé vs15 redist et ça a fonctionné.

Answer 2

Je sais que ce fil de discussion est quelque peu ancien, mais j'ai également eu ce problème avec une application c#/WPF que je créais. L'application fonctionnait bien sur la machine de développement, mais ne démarrait pas sur la machine de test. Le journal d'application dans l'Observateur d'événements donnait une erreur Runtime .NET quelque peu vague de System.IO.DirectoryNotFoundException.

J'ai essayé d'utiliser un logiciel de débogage mais l'application ne restait pas en cours d'exécution assez longtemps pour attacher le débogueur au processus. Après avoir cogner ma tête contre mon bureau pendant une journée et avoir consulté de nombreuses pages Web comme celle-ci, ce que j'ai fini par faire pour résoudre ce problème a été d'installer VS2019 sur ma machine de test. J'ai ensuite fait glisser le fichier .exe de son dossier (il était profondément enfoui dans le dossier Utilisateurs\[utilisateur]\AppData\Apps\2.0...) vers l'instance ouverte de VS2019 et j'ai essayé de le démarrer à partir de là. Immédiatement, une boîte de dialogue est apparue donnant l'exception et la cause.

Dans mon cas, lors de l'ajout d'une icône à l'un des formulaires, le chemin complet vers l'icône a été placé dans le XAML au lieu du simple nom de l'icône. J'avais copié le fichier d'icône dans le dossier du projet, mais comme le dossier du projet n'existait pas sur la machine de test, c'était la cause de l'erreur. J'ai ensuite supprimé le chemin du XAML, laissant uniquement le nom de l'icône, reconstruit la solution, republié et elle s'est exécutée parfaitement sur la machine de test. Bien sûr, il existe de nombreuses causes autres que celle qui m'a donné l'erreur, mais cette méthode de dépannage devrait identifier avec un peu de chance la cause première de l'erreur, puisque l'Observateur d'événements de Windows donne une réponse quelque peu vague.

Pour résumer, utilisez Visual Studio sur la machine de test comme un débogueur de types. Mais, pour que cela fonctionne correctement, j'ai dû faire glisser le fichier .exe dans l'IDE et le démarrer à partir de là. Je pense que cela fonctionnera également avec VS2017 ainsi qu'avec VS2019. J'espère que cela aidera quelqu'un qui rencontre toujours ce problème.

Answer 3

Lorsque vous exécutez une application en ligne de commande, elle se ferme immédiatement, et j'ai vu cette exception dans l'Observateur d'événements mais je n'ai pas reçu d'autres retours. Dans mon cas, exécuter l'invite de commandes en tant qu'administrateur a résolu le problème.

Je pense qu'une des leçons à tirer de cela est simplement que vous pouvez obtenir cette exception en raison d'un problème de permission.

Quelques heures plus tard, nous avons eu la même exception avec une version plus récente de l'application console pour une autre raison. Cette fois, il s'est avéré qu'il y avait une incompatibilité de version de dll. L'utilisation de la version dll plus récente requise a résolu le problème.

Peut-être que cette erreur générique survient en raison d'un code qui ne gère pas les exceptions de manière élégante; la meilleure solution étant probablement de gérer les exceptions assez bien pour fournir de meilleurs messages d'erreur.

Answer 4

Dans mon cas, j'étais à court de mémoire et mon fichier d'échange du système Windows était désactivé. Après l'avoir réactivé, l'erreur a disparu.

Pour modifier les paramètres du fichier d'échange :

• Cliquez sur Démarrer, tapez Paramètres système avancés dans le menu Démarrer et appuyez sur Entrée pour l'ouvrir.
• Cliquez sur le bouton Paramètres sous performances.
• Basculez vers l'onglet Avancé et cliquez sur le bouton Modifier dans la section Mémoire virtuelle.