Comment diagnostiquer l'erreur SEHException - Le composant externe a généré une exception
Lorsqu'un utilisateur signale une erreur telle que
System.Runtime.InteropServices.SEHException - Le composant externe a levé une exception?
en tant que programmeur, y a-t-il quelque chose que je puisse faire pour en déterminer la cause?
Scénario: un utilisateur (utilisant un programme écrit par ma société) a signalé cette erreur. Cela peut ou peut ne pas avoir été une erreur unique. Ils ont mentionné qu'au cours du dernier mois, l'ordinateur a deux fois "cessé de fonctionner". Mon expérience m'a appris à ne pas prendre cette description trop à la lettre, car cela signifie généralement qu'une personne en relation avec l'ordinateur ne fonctionne pas comme prévu. Ils ont été incapables de me donner plus de détails et je n'ai trouvé aucune erreur consignée. Par conséquent, il se peut que cette erreur ait été commise ou non.
À partir de la trace de pile, l’erreur réelle se produisait lors de la construction d’une classe qui n’appelait directement aucun code interop, mais était peut-être compliquée par le fait que l’objet pouvait faire partie d’une liste liée à une grille DevExpress.
L'erreur a été "interceptée" par une routine d'exception non gérée qui normalement fermera le programme, mais a une option permettant d'ignorer et de continuer. S'ils choisissaient d'ignorer l'erreur, le programme continuait de fonctionner, mais l'erreur se reproduisait lors de la prochaine exécution de cette routine. Cependant, cela ne s'est pas reproduit après la fermeture et le redémarrage de notre application.
L'ordinateur en question n'a pas semblé être stressé. Il exécute Vista Business, dispose de 2 Go de mémoire et, selon Task Manager, n'en utilisait que la moitié environ avec notre application, environ 200 Mo.
Il existe un autre élément d’information qui peut être pertinent ou non. Une autre section du même programme utilise un composant tiers qui est en réalité un wrapper dotnet autour d'une dll native et ce composant a un problème connu dans lequel, très occasionnellement, vous obtenez un
Tentative de lecture ou d'écriture de la mémoire protégée. Cela indique souvent que d'autres mémoires sont corrompues
Les fabricants de composants disent que cela a été corrigé dans la dernière version de leur composant que nous utilisons en interne, mais cela n’a pas encore été communiqué au client.
Etant donné que les conséquences de l’erreur sont faibles (aucun travail n’est perdu, le redémarrage du programme et le retour à leur état initial ne prend qu’une minute au plus) et le client recevra bientôt une nouvelle version (avec la troisième mise à jour). partie), je peux évidemment me croiser les doigts et espérer que l’erreur ne se reproduira plus.
Mais y a-t-il autre chose que je puisse faire?
Oui. Cette erreur est une exception structurée qui n'a pas été mappée dans une erreur .NET. C'est probablement votre mappage DataGrid qui génère une exception native qui n'a pas été capturée.
Vous pouvez savoir quelle exception se produit en consultant la propriété ExternalException.ErrorCode . Je vérifierais votre trace de pile et, si elle est liée à la grille DevExpress, signalez-leur le problème.
J'ai eu un problème similaire avec une SEHException qui a été levée lorsque mon programme a utilisé pour la première fois un wrapper dll natif. Il s'est avéré que la DLL native de cet encapsuleur était manquante. L'exception n'était d'aucune utilité pour résoudre ce problème. Ce qui a aidé en fin de compte a été d'exécuter procmon en arrière-plan et de vérifier s'il y en avait erreurs lors du chargement de toutes les DLL nécessaires.
si vous rencontrez un problème comme décrit dans ce post:
débogueur asp.net en lançant SEHException
alors la solution est:
si vous avez une application de Trusteer (telle que rapport ou quoi que ce soit), désinstallez et redémarrez votre système, tout se passera bien ... nous avons trouvé cette solution ici:
http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+thrown+when+I+run+the+application
Les fabricants de composants disent que cela a été corrigé dans la dernière version de leur composant, que nous utilisons en interne, mais cela a encore été transmis au client.
Demandez au fabricant de composants comment vérifier si le problème rencontré par le client est celui qu'il a résolu dans sa dernière version, sans/avant de déployer sa dernière version sur le client.
J'ai rencontré cette erreur lorsque l'application réside sur un partage réseau et que le périphérique (ordinateur portable, tablette, ...) se déconnecte du réseau pendant l'utilisation de l'application. Dans mon cas, cela était dû à une tablette Surface sortant de la portée sans fil. Aucun problème après l'installation d'un meilleur WAP.
Juste une autre information ... Ce problème se pose aujourd'hui sur un système Windows 2012 R2 x64 TS où l'application a été démarrée à partir d'un chemin unc/réseau. Le problème s'est produit pour une application pour tous les utilisateurs du serveur Terminal Server. L'exécution de l'application a fonctionné localement sans problème. Après un redémarrage, il a recommencé à fonctionner - les exceptions lancées par SEHEx étaient Constructor init et TargetInvocationException.
Mes configurations de machine:
Système d'exploitation: Windows 10 Version 1703 (x64)
J'ai rencontré cette erreur lors du débogage de mon projet C # .Net dans l'édition Visual Studio 2017 Community. J'appelais une méthode native en effectuant p/invoke sur un assembly C++ chargé au moment de l'exécution. J'ai rencontré la même erreur signalée par OP.
J'ai réalisé que Visual Studio avait été lancé avec un compte d'utilisateur qui n'était pas un administrateur sur la machine. Ensuite, j'ai relancé Visual Studio sous un compte d'utilisateur différent, qui était un administrateur de la machine. C'est tout. Mon problème a été résolu et je n'ai plus été confronté au problème.
Une chose à noter est que la méthode qui était invoquée sur C++ Assembly était supposée écrire peu de choses dans le registre. Je ne suis pas allé déboguer le code C++ pour faire de la RCA, mais je vois une possibilité que tout cela échoue, car des privilèges d’administration sont nécessaires pour écrire le registre dans le système d’exploitation Windows 10. Ainsi, lorsque Visual Studio était exécuté sous un compte d'utilisateur ne disposant pas de privilèges d'administrateur sur la machine, les appels natifs échouaient.