Comment diagnostiquer l'erreur SEHException - Le composant externe a levé une exception


86

Chaque fois qu'un utilisateur signale une erreur telle que

System.Runtime.InteropServices.SEHException - Le composant externe a levé une exception?

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

Scénario: un utilisateur (utilisant un programme écrit par mon entreprise) a signalé cette erreur. Cela peut ou non avoir été une erreur ponctuelle. Ils ont mentionné que le mois dernier, l'ordinateur avait «cessé de fonctionner» deux fois. J'ai appris par expérience, de ne pas prendre cette description trop littéralement, car cela signifie généralement que quelqu'un lié à l'ordinateur ne fonctionne pas comme prévu. Ils n'ont pas pu me donner plus de détails et je n'ai trouvé aucune erreur enregistrée. Par conséquent, cela peut ou non avoir été cette erreur.

À partir de la trace de pile, l'erreur réelle était lors de la construction d'une classe qui n'appelle directement aucun code d'interopérabilité, mais peut-être compliquée par le fait que l'objet peut faire partie d'une liste liée aux données d'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 pour ignorer et 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 ne semble pas stressé. Il exécute Vista Business, dispose de 2 Go de mémoire et, selon Task Manager, n'en utilisait que la moitié avec notre application à peu près 200 Mo.

Il y a une autre information qui peut être pertinente ou non. Une autre section du même programme utilise un composant tiers qui est en fait un wrapper dotnet autour d'une DLL native et ce composant a un problème connu où très occasionnellement, vous obtenez un

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

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é donné au client.

Étant donné que les conséquences de l'erreur sont faibles (aucun travail n'est perdu et le redémarrage du programme et le retour à l'endroit où ils étaient ne prennent qu'une minute au maximum) et étant donné que le client obtiendra sous peu une nouvelle version (avec la troisième mise à jour - partie), je peux évidemment croiser les doigts et espérer que l'erreur ne se reproduira plus.

Mais y a-t-il autre chose que je puisse faire?

Réponses:


28

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 lançant une exception native qui n'a pas été interceptée.

Vous pouvez savoir quelle exception se produit en examinant la propriété ExternalException.ErrorCode . Je vérifierais votre trace de pile et si elle est liée à la grille DevExpress, je leur signale le problème.


1
StackTrace n'a mentionné DevExpress nulle part, mais juste ma classe. Devra vérifier pour voir quel était le ErrorCode.
sgmoore

Dans ce cas, essayez de comprendre exactement ce qui a jeté le message d'erreur.
Reed Copsey

4
"en regardant la propriété ExternalException.ErrorCode" - avez-vous des conseils sur la façon de procéder exactement? VS me montre "Une exception non gérée de type 'System.Runtime.InteropServices.SEHException' s'est produite dans .... dll Informations supplémentaires: Eine externe Komponente hat eine Ausnahme ausgelöst.", Mais à part par exemple les applications C #, il n'y a pas de lien pour regarder les "Détails" de l'objet d'exception n'importe où.
OR Mapper

Le débogueur de VSCode montre une instance $ exception sous Locals - cela inclut un champ Message, qui comprend le code et un message d'erreur lisible par l'homme.
nightblade9 il y a

8

J'ai eu un problème similaire avec une SEHException qui a été lancé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 ce wrapper était manquante. L'exception n'a en aucun cas aidé à résoudre ce problème. Ce qui a aidé à la fin était d'exécuter procmon en arrière-plan et de vérifier s'il y avait des erreurs lors du chargement de toutes les DLL nécessaires.



3

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é donné au client.

Demandez au fabricant de composants comment tester si le problème rencontré par le client est le problème qu'il dit avoir résolu dans sa dernière version, sans / avant de déployer sa dernière version auprès du client.


1

J'ai rencontré cette erreur lorsque l'application réside sur un partage réseau et que l'appareil (ordinateur portable, tablette, ...) se déconnecte du réseau pendant que l'application est en cours d'utilisation. Dans mon cas, c'était dû à une tablette Surface hors de portée sans fil. Aucun problème après l'installation d'un meilleur WAP.


1
Je l'obtenais au hasard en accédant à différents types de réflexion (GetAssemblyName, GetProperty, Activator, etc.) à la fois dans mon code et dans des bibliothèques tierces, et juste dans un environnement client, de même avec des bibliothèques sur un emplacement distant. Beaucoup de preuves sont le bogue du framework .net.
Andriy K du

Andriy K: Je ne pense pas que ce soit un problème .NET, je pense que les poignées des fichiers ouverts sur le partage réseau sont perdues \ abandonnées d'une manière ou d'une autre, peut-être un bogue dans Windows ou un problème de réseau. Les assemblys sont mappés en mémoire et seront paginés à partir du disque à la demande (bombe à retardement), éventuellement la mémoire peut également être supprimée dans des situations de mémoire insuffisante. Si les descripteurs de fichiers ouverts ne sont pas stables, cela explosera probablement en fumée. .NET aurait peut-être pu le gérer et rouvrir le fichier (régler le problème), mais cela peut être compliqué.
osexpert

J'ai le même problème. J'obtiens System.Runtime.InteropServices.SEHException (0x80004005) sans trace de pile. Il s'agit de l'InnerException d'une TargetInvocationException. TargetInvocationException a une trace de pile, mais cela n'a aucun sens pour moi car il semble provenir de main ou Application.Run. Cela se produit de manière très aléatoire, principalement le soir / la nuit. Je suppose que la seule "solution" est de ne pas fonctionner à partir du lecteur réseau: - | Peut-être que j'ajoute un chèque qui peut bloquer ce scénario: stackoverflow.com/questions/8633680/…
osexpert

0

Juste une autre information ... Eu ce problème aujourd'hui sur un système Windows 2012 R2 x64 TS où l'application a été démarrée à partir d'un chemin unc / network. Le problème est survenu pour une application pour tous les utilisateurs du serveur Terminal Server. L'exécution de l'application localement a fonctionné sans problème. Après un redémarrage, il a recommencé à fonctionner - l'exception SEHException lancée était Constructor init et TargetInvocationException


0

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 communautaire de Visual Studio 2017. J'appelais une méthode native en exécutant p / invoke sur un assemblage 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 a été lancé avec un compte d'utilisateur qui n'était pas un administrateur sur la machine. Ensuite, j'ai relancé Visual Studio sous un autre compte d'utilisateur qui était un administrateur sur la machine. C'est tout. Mon problème a été résolu et je n'ai plus rencontré le problème.

Une chose à noter est que la méthode qui était invoquée sur l'assembly C ++ était censée écrire peu de choses dans le registre. Je ne suis pas allé déboguer le code C ++ pour faire du RCA, mais je vois une possibilité que tout échoue car les privilèges administratifs sont nécessaires pour écrire le registre dans le système d'exploitation Windows 10. Donc, plus tôt, lorsque Visual Studio s'exécutait sous un compte d'utilisateur qui ne disposait pas de privilèges administratifs sur la machine, les appels natifs échouaient.


0

J'ai eu cette erreur lors de l'exécution de tests unitaires sur la mise en cache en mémoire que j'étais en train de configurer. Il a inondé la cache. Après avoir invalidé le cache et redémarré la machine virtuelle, cela a bien fonctionné.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.