SEHException não capturado pelo Try / Catch
Em um thread de segundo plano, meu aplicativo examina regularmente uma pasta de rede (caminho UNC) para atualizações de aplicativos. Ele lê a versão de montagem do arquivo, da seguinte forma:
Try
newVers = System.Reflection.AssemblyName.GetAssemblyName("\\server\app.exe").Version
Catch ex As Exception
' ignore
End Try
Este snippet é executado com bastante frequência, no total, eu suponho que tenha sido mais de 100.000 vezes em vários sites de clientes até agora sem nenhum problema.
As vezes,GetAssemblyName
levanta umFileNotFoundException
, por exemplo, caso a pasta da rede não esteja acessível (o que pode acontecer e deve ser resolvido). Essa exceção é capturada peloCatch
bloco logo abaixo, e tudo funciona muito bem.
Em três casos relatados, no entanto,GetAssemblyName
chamada levantou umSEHException
. O estranho é que essa exceção não foi pego peloCatch
bloco logo abaixo, mas pelo meu manipulador de exceção não tratada global (System.AppDomain.CurrentDomain.UnhandledException
). Como resultado, o aplicativo falha.
Aqui está o detalhe da exceção (infelizmente, oErrorCode
eCanResume
campos da exceção não são registrados pela minha rotina de tratamento de erros):
Caught exception: System.Runtime.InteropServices.SEHException
Message: External component has thrown an exception.
Source: mscorlib
TargetSite: System.Reflection.AssemblyName nGetFileInformation(System.String)
StackTrace:
at System.Reflection.AssemblyName.nGetFileInformation(String s)
at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
at SyncThread.Run()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Por que é que a exceção não é pego peloCatch
bloquear logo abaixo?
(Talvez isso seja relevante: isso só aconteceu em sites de clientes, onde o caminho UNC apontava para um servidor que não fazia parte da rede local, mas um servidor remoto em uma VPN.)