Como você deve diagnosticar o erro SehException - o componente externo lançou uma exceção

Question

Sempre que um usuário relata um erro como

System.runtime.interOpsVices.SeHexception - Componente externo lançou uma exceção?

Existe algo que eu, como programador, possa fazer para determinar a causa?

Cenário: Um usuário (usando um programa que minha empresa escreveu) relatou esse erro. Isso pode ou não ter sido um erro único. Eles mencionaram que, no último mês, o computador duas vezes "parou de funcionar". Aprendi com a experiência, a não aceitar essa descrição literalmente, pois geralmente significa que alguém relacionado ao computador não está funcionando como esperado. Eles não conseguiram me dar mais detalhes e eu não consegui encontrar erros registrados. Portanto, pode ou não ter sido esse erro.

A partir do rastreamento da pilha, o erro real foi ao construir uma classe que não chama diretamente nenhum código de interoper, mas talvez complicado pelo fato de que o objeto pode fazer parte de uma lista que é bancos de dados para uma grade de Devexpress.

O erro foi 'pego' por uma rotina de exceção não tratada que normalmente fechará o programa, mas tem a opção de ignorar e continuar. Se eles optaram por ignorar o erro, o programa continuou funcionando, mas o erro re-ocorrido quando essa rotina foi executada em seguida. No entanto, isso não ocorreu novamente após fechar e reiniciar nossa aplicação.

O computador em questão não parecia estar estressado. Ele está executando o negócio do Vista, possui 2 GB de memória e, de acordo com o gerente de tarefas, estava usando apenas metade disso com nosso aplicativo apenas 200 MB.

Há outra informação que pode ou não ser relevante. Outra seção do mesmo programa usa um componente de terceiros, que é efetivamente um invólucro de dotnet em torno de uma DLL nativa e esse componente tem um problema conhecido em que ocasionalmente, você obtém um

Tentou ler ou escrever memória protegida. Isso geralmente é uma indicação de que outra memória é corrupta

Os fabricantes de componentes dizem que isso foi corrigido na versão mais recente de seu componente que estamos usando internamente, mas isso ainda não foi dado ao cliente.

Dado que as consequências do erro são baixas (nenhum trabalho está perdido e reiniciando o programa e voltando para onde eles estavam levando apenas um minuto no máximo) e, já que o cliente estará recebendo uma nova versão (com o terceiro atualizado- componente da parte), obviamente, posso cruzar os dedos e espero que o erro não ocorra novamente.

Mas há mais algo que eu possa fazer?

Answer 1

Sim. Este erro é uma exceção estruturada que não foi mapeada em um erro .NET. Provavelmente é o seu mapeamento de datagrid lançando uma exceção nativa que não foi capturada.

Você pode dizer que exceção está ocorrendo olhando para o Externalexception.errorCode propriedade. Eu verificaria seu rastreamento de pilha e, se estiver ligado à grade do Devexpress, relatasse o problema a eles.

Answer 2

Eu tive um problema semelhante com uma SehException que foi lançada quando meu programa usou um invólucro de DLL nativo. Aconteceu que a DLL nativa para esse invólucro estava faltando. A exceção não foi de forma alguma útil para resolver isso. O que ajudou no final foi executar o Procmon em segundo plano e verificar se houve algum erro ao carregar todas as DLLs necessárias.

Answer 3

Se você está tendo um problema como descreva neste post:

ASP.NET MVC Debugger jogando Sehexception

Então a solução é:

Se você tiver algum aplicativo da Triderer (como relacionamento ou algo assim), desinstale e reinicie seu sistema, funcionará bem ... Encontre esta solução aqui:

http://forums.asp.net/t/1704958.aspx/8/10?re+SeHexception+thrown+when+i+run+the+Application

Answer 4

Os fabricantes de componentes dizem que isso foi corrigido na versão mais recente de seu componente que estamos usando internamente, mas isso foi dado ao cliente ainda.

Pergunte ao fabricante de componentes como testar se o problema que o cliente está obtendo é o problema que eles dizem ter corrigido em sua versão mais recente, sem/antes de implantar sua versão mais recente para o cliente.

Answer 5

Encontrei esse erro quando o aplicativo reside em um compartilhamento de rede, e o dispositivo (laptop, tablet, ...) fica desconectado da rede enquanto o aplicativo estiver em uso. No meu caso, foi devido a um comprimido de superfície sai da faixa sem fio. Sem problemas depois de instalar um WAP melhor.

Answer 6

Apenas mais uma informação ... tinha esse problema hoje em um sistema Windows 2012 X64 TS, onde o aplicativo foi iniciado a partir de um caminho UNC/rede. O problema ocorreu para um aplicativo para todos os usuários do servidor de terminal. Executar o aplicativo trabalhou localmente sem problemas. Após uma reinicialização, ele começou a funcionar novamente - a SehException jogada foi o construtor init e TargetInvocationException

Answer 7

Minhas configurações de máquina:

Sistema operacional: Windows 10 versão 1703 (x64)

Enfrentei esse erro ao depurar meu projeto C# .NET no Visual Studio 2017 Community Edition. Eu estava chamando um método nativo realizando P/Invoke em uma montagem C ++ carregada em tempo de execução. Encontrei o mesmo erro relatado pelo op.

Percebi que o Visual Studio foi lançado com uma conta de usuário que não era um administrador na máquina. Em seguida, relançei o Visual Studio em uma conta de usuário diferente, que era um administrador na máquina. Isso é tudo. Meu problema foi resolvido e eu não enfrentei o problema novamente.

Uma coisa a observar é que o método que estava sendo invocado na montagem de C ++ deveria escrever poucas coisas no registro. Não depurei o código C ++ para fazer algum RCA, mas vejo a possibilidade de que tudo estivesse falhando, pois os privilégios administrativos são obrigados a escrever registro no sistema operacional Windows 10. Então, mais cedo, quando o Visual Studio estava em execução em uma conta de usuário que não tinha privilégios administrativos na máquina, as chamadas nativas estavam falhando.