如何诊断 SEHException 错误-外部组件引发了异常

每当用户报告错误时,例如

System.Runtime.InteropServices.SEHException -外部组件引发异常?

作为一个程序员,我能做些什么来确定原因呢?

场景: 一个用户(使用我公司编写的程序)报告了这个错误。 这可能是一次性错误,也可能不是。他们提到,在上个月,计算机已经两次“停止工作”。我从经验中学到,不要把这个描述过于字面化,因为它通常意味着与计算机有关的人没有按照预期工作。他们不能给我更多的细节,我找不到任何记录错误。因此,它可能是,也可能不是这个错误。

从堆栈跟踪来看,实际的错误在于构造一个类时,该类不直接调用任何互操作代码,但是由于该对象可能是数据绑定到 DevExpress Grid 的列表的一部分,这一事实可能会使问题变得更加复杂。

该错误被一个未处理的异常例程“捕获”,该例程通常会关闭程序,但有一个选项可以忽略并继续。如果他们选择忽略错误,那么程序继续工作,但是当下一次运行这个例程时,错误再次发生。但是,在关闭并重新启动应用程序之后,它没有再次发生。

问题中的计算机似乎并没有感到压力过大。它运行 Vista 业务,有2GB 的内存,根据任务管理器只使用了大约一半,我们的应用程序只有200Mb。

还有一条信息可能是相关的,也可能不是。同一个程序的另一个部分使用了第三方组件,这个组件实际上是一个本机 dll 的 dotnet 包装器,并且这个组件确实有一个已知的问题,在这个问题中,您偶尔会得到一个

尝试读取或写入受保护的内存。这通常表示其他内存已损坏

组件制造商说,这个问题已经在我们内部使用的组件的最新版本中得到解决,但是这个问题还没有提供给客户。

考虑到这个错误的后果很小(没有丢失任何工作,重新启动程序并返回原来的位置最多只需要一分钟) ,考虑到客户很快就会得到一个新版本(带有更新的第三方组件) ,我当然可以祈祷这个错误不会再次发生。

还有什么我能做的吗?

193860 次浏览

Yes. This error is a structured exception that wasn't mapped into a .NET error. It's probably your DataGrid mapping throwing a native exception that was uncaught.

You can tell what exception is occurring by looking at the ExternalException.ErrorCode property. I'd check your stack trace, and if it's tied to the DevExpress grid, report the problem to them.

The component makers say that this has been fixed in the latest version of their component which we are using in-house, but this has been given to the customer yet.

Ask the component maker how to test whether the problem that the customer is getting is the problem which they say they've fixed in their latest version, without/before deploying their latest version to the customer.

if you are having a problem as describe in this post:

asp.net mvc debugger throwing SEHException

then the solution is:

if you have any application from Trusteer (like rapport or anything ) just uninstall and reboot your system, it'll work fine ... found this solution here:

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

I had a similar problem with an SEHException that was thrown when my program first used a native dll wrapper. Turned out that the native DLL for that wrapper was missing. The exception was in no way helpful in solving this. What did help in the end was running procmon in the background and checking if there were any errors when loading all the necessary DLLs.

I have come across this error when the app resides on a network share, and the device (laptop, tablet, ...) becomes disconnected from the network while the app is in use. In my case, it was due to a Surface tablet going out of wireless range. No problems after installing a better WAP.

Just another information... Had that problem today on a Windows 2012 R2 x64 TS system where the application was started from a unc/network path. The issue occured for one application for all terminal server users. Executing the application locally worked without problems. After a reboot it started working again - the SEHException's thrown had been Constructor init and TargetInvocationException

My machine configurations :

Operating System : Windows 10 Version 1703 (x64)

I faced this error while debugging my C# .Net project in Visual Studio 2017 Community edition. I was calling a native method by performing p/invoke on a C++ assembly loaded at run-time. I encountered the very same error reported by OP.

I realized that Visual Studio was launched with a user account which was not an administrator on the machine. Then I relaunched Visual Studio under a different user account which was an administrator on the machine. That's all. My problem got resolved and I didn't face the issue again.

One thing to note is that the method which was being invoked on C++ assembly was supposed to write few things in registry. I didn't go debugging the C++ code to do some RCA but I see a possibility that the whole thing was failing as administrative privileges are required to write registry in Windows 10 operating system. So earlier when Visual Studio was running under a user account which didn't have administrative privileges on the machine, then the native calls were failing.

I got this error while running unit tests on inmemory caching I was setting up. It flooded the cache. After invalidating the cache and restarting the VM, it worked fine.