Comment devriez-vous diagnostiquer le SEHException d'erreur - composant externe a jeté une exception

Question

Chaque fois qu'un utilisateur signale une erreur comme

  

System.Runtime.InteropServices.SEHException - composant externe a jeté une exception

est quelque chose que je en tant que programmeur peut faire pour déterminer la cause?

Scénario: Un utilisateur (en utilisant un programme écrit mon entreprise) a signalé cette erreur. Cela peut ou peut ne pas avoir été un hors erreur. Ils ont mentionné que dans le dernier mois, l'ordinateur a deux fois "cessé de fonctionner. Je l'ai appris de l'expérience, de ne pas prendre cette description trop littéralement, comme cela signifie généralement que quelqu'un se rapportant à l'ordinateur ne fonctionne pas comme prévu. Ils ont été incapables de me donner plus de détails et je ne pouvais pas trouver des erreurs enregistrées. Par conséquent, il peut ou peut ne pas avoir été cette erreur.

De la pile trace, l'erreur réelle était lors de la construction d'une classe qui ne remet pas directement un code Interop, mais peut-être compliqué par le fait que l'objet peut faire partie d'une liste qui est DataBound à une grille DevExpress.

L'erreur a été « pris » par une routine d'exception non gérée qui normalement fermer le programme, mais a une option d'ignorer et de continuer. S'ils ont choisi d'ignorer l'erreur, le programme a continué à travailler, mais l'erreur se est produite lorsque cette routine était la prochaine course. Cependant, il n'y a pas eu de nouveau après la fermeture et le redémarrage de notre application.

L'ordinateur en question ne semble pas être stressé. Il est en cours d'exécution Vista Business, dispose de 2 Go de mémoire et selon le Gestionnaire des tâches n'utilisait environ la moitié de cela avec notre application à peu près 200Mo.

Il y a un autre élément d'information qui peuvent ou peuvent ne pas être pertinents. Une autre section du même programme utilise un composant tiers qui est effectivement une enveloppe dotnet autour d'une dll native et ce composant a un problème connu très de temps en temps, vous obtenez un

  

Tentative de lecture ou d'écriture de mémoire protégée. Cela est souvent une indication qu'une autre mémoire est corrompue

Les fabricants de composants disent que cela a été corrigé dans la dernière version de leur composante que nous utilisons en interne, mais cela n'a pas été remis au client encore.

Étant donné que les conséquences de l'erreur sont faibles (pas de travail est perdu et redémarrer le programme et revenir à l'endroit où ils étaient prend une minute seulement au plus) et étant donné que le client sera bientôt devient une nouvelle version (avec le mis à jour le composant tiers), je peux évidemment croiser les doigts et espérer l'erreur ne se reproduira pas.

Mais est-il quelque chose de plus que je peux faire?

Answer 1

Oui. Cette erreur est une exception structurée qui n'a pas été mis en correspondance une erreur de .NET. Il est probablement votre cartographie DataGrid lancer une exception native qui était uncaught.

Vous pouvez dire ce que exception se produit en regardant le propriété de ExternalException.ErrorCode. Je vérifie votre trace de la pile, et si elle est liée à la grille DevExpress, signaler le problème à eux.

Answer 2

J'ai eu un problème similaire avec un SEHException qui a été levée lorsque mon programme d'abord utilisé une enveloppe dll native. Avéré que la DLL native de cette enveloppe était manquante. L'exception était aucunement utile pour résoudre cela. Qu'est-ce que l'aide à la fin était en cours d'exécution procmon en arrière-plan et vérifier s'il y avait des erreurs lors du chargement de toutes les DLL nécessaires.

Answer 3

si vous avez un problème précisées dans cette message:

asp.net débogueur lancer mvc SEHException

alors la solution est:

si vous avez une application de Trusteer (comme rapport ou quoi que ce soit) simplement désinstaller et redémarrer votre système, ça va fonctionner très bien ... trouvé cette solution ici:

http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+thrown+when+I+run+the+application

Answer 4

  

Les fabricants de composants disent que cela a été corrigé dans la dernière version de leur composante que nous utilisons en interne, mais cela a été remis au client encore.

Demandez au fabricant de composants comment vérifier si le problème que le client obtient le problème qu'ils disent qu'ils ont fixé dans leur dernière version, sans / avant de déployer leur dernière version du client.

Answer 5

Je suis venu dans cette erreur lorsque l'application se trouve sur un partage réseau, et le dispositif (ordinateur portable, tablette, ...) est déconnecté du réseau lorsque l'application est en cours d'utilisation. Dans mon cas, cela était dû à un comprimé de surface allant hors de portée sans fil. Aucun problème après l'installation d'une meilleure WAP.

Answer 6

Juste une autre information ... Si cela avait problème aujourd'hui sur un système R2 64 bits de Windows TS 2012 où l'application a été lancée à partir d'un chemin unc / réseau. La question est survenue pour une application pour tous les utilisateurs de serveur terminal. L'exécution de l'application travaillé localement sans problème. Après un redémarrage, il a commencé à travailler à nouveau - de la SEHException avait été jeté Constructor init et TargetInvocationException

Answer 7

Mes configurations de la machine:

Système d'exploitation: Windows 10 Version 1703 (64 bits)

Je fait face à cette erreur lors du débogage de mon projet C # .Net dans l'édition communautaire Visual Studio 2017. Je me appelle une méthode native en effectuant p / invoquer sur un ensemble C ++ chargé au moment de l'exécution. Je rencontrais la même erreur signalée par OP.

J'ai réalisé que Visual Studio a été lancé avec un compte utilisateur qui n'a pas été un administrateur sur la machine. Ensuite, je relancé Visual Studio sous un compte d'utilisateur différent qui était un administrateur sur la machine. C'est tout. Mon problème résolu obtenu et je ne pas face à la question à nouveau.

Une chose à noter est que la méthode qui a été invoquée à l'assemblée C était censé écrire peu de choses dans le registre. Je ne suis pas le débogage du code C ++ pour faire un peu de RCA mais je vois une possibilité que la chose ne parvenait pas que des privilèges d'administrateur sont nécessaires pour écrire registre dans le système d'exploitation Windows 10. Donc, plus tôt au moment de l'exécution de Visual Studio sous un compte utilisateur qui ne dispose pas des privilèges d'administrateur sur la machine, les appels natifs échouaient.