Como você deve diagnosticar o erro SEHException – componente externo lançou uma exceção

Sempre que um usuário relata um erro, como

System.Runtime.InteropServices.SEHException – componente externo lançou uma exceção?

Existe alguma coisa 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. Eles mencionaram que, no último mês, o computador parou duas vezes de funcionar. Eu aprendi com a experiência, não para levar essa descrição muito literalmente, como 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 encontrei nenhum erro registrado. Por isso, pode ou não ter sido esse erro.

Do rastreamento de pilha, o erro real foi ao construir uma class que não chama diretamente nenhum código de interoperabilidade, mas talvez complicado pelo fato de que o object pode fazer parte de uma lista que está vinculada a um DevExpress Grid.

O erro foi ‘apanhado’ por uma rotina de exceção não tratada que normalmente encerra 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 ocorreu novamente quando essa rotina foi executada na próxima vez. No entanto, isso não ocorreu novamente depois de fechar e reiniciar nosso aplicativo.

O computador em questão não parecia estar estressado. Ele está executando o Vista Business, tem 2GB de memory e de acordo com o Gerenciador de Tarefas estava usando apenas cerca de metade do que com o nosso aplicativo de cerca de 200Mb.

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

Tentativa de ler ou gravar memory protegida. Isso geralmente é uma indicação de que outra memory está corrompida

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

Dado que as conseqüências do erro são baixas (nenhum trabalho é perdido e reiniciar o programa e voltar para onde eles levaram apenas um minuto no máximo) e dado que o cliente em breve estará recebendo uma nova versão (com a terceira versão atualizada). componente do partido), eu obviamente posso cruzar os dedos e esperar que o erro não ocorra novamente.

Mas há mais alguma coisa que eu possa fazer?

Sim. Este erro é uma exceção estruturada que não foi mapeada em um erro do .NET. É provavelmente o seu mapeamento DataGrid lançando uma exceção nativa que não foi detectada.

Você pode dizer qual exceção está ocorrendo observando a propriedade ExternalException.ErrorCode . Eu verificaria seu rastreio de pilha e, se estivesse vinculado à grade do DevExpress, informe o problema a eles.

Eu tive um problema semelhante com uma SEHException que foi lançada quando meu programa usou pela primeira vez um wrapper de dll nativo. Acabou que a DLL nativa para esse wrapper estava faltando. A exceção não foi de forma alguma útil para resolver isso. O que ajudou no final foi executado procmon em segundo plano e verificar se houve algum erro ao carregar todas as DLLs necessárias.

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

debugger asp.net mvc jogando SEHException

então a solução é:

se você tem algum aplicativo da Trusteer (como rapport ou qualquer outra coisa) apenas desinstale e reinicie o seu sistema, ele vai funcionar bem … encontrei essa solução aqui:

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

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

Pergunte ao fabricante do componente como testar se o problema que o cliente está tendo é 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.

Uma pergunta antiga, mas para os Googlers: Eu me deparei com esse erro quando o aplicativo reside em um compartilhamento de rede e o dispositivo (laptop, tablet, …) fica desconectado da rede enquanto o aplicativo está em uso. No meu caso, foi devido a um tablet Surface saindo do alcance sem fio. Não há problemas depois de instalar um WAP melhor.

Apenas outra informação … Tive esse problema hoje em um sistema Windows 2012 R2 x64 TS onde o aplicativo foi iniciado a partir de um caminho unc / network. O problema ocorreu para um aplicativo para todos os usuários do servidor de terminal. Executar o aplicativo localmente funcionou sem problemas. Após a reboot, ele começou a funcionar novamente – o lançamento do SEHException foi Constructor init e TargetInvocationException

Minhas configurações de máquina:

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

Eu enfrentei esse erro durante a debugging do meu projeto C # .Net no Visual Studio 2017 Community edition. Eu estava chamando um método nativo executando p / invoke em um assembly C ++ carregado em tempo de execução. Eu encontrei o mesmo erro relatado pelo OP.

Eu 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, relancei o Visual Studio com uma conta de usuário diferente, que era um administrador na máquina. Isso é tudo. Meu problema foi resolvido e não enfrentei o problema novamente.

Uma coisa a notar é que o método que estava sendo chamado no assembly C ++ deveria escrever algumas coisas no registro. Eu não fui depurar o código C ++ para fazer alguns RCA, mas vejo a possibilidade de que a coisa toda estava falhando como privilégios administrativos são necessários para gravar o registro no sistema operacional Windows 10. Portanto, mais cedo, quando o Visual Studio estava sendo executado em uma conta de usuário que não tinha privilégios administrativos na máquina, as chamadas nativas estavam falhando.