How should you diagnose the error SEHException - External component has thrown an exception

Question

Whenever a user reports an error such as

System.Runtime.InteropServices.SEHException - External component has thrown an exception?

is there anything that I as a programmer can do to determine the cause?

Scenario : One user (using a program my company wrote) has reported this error. This may or may not have been a one off error. They mentioned that in the last month, the computer has twice 'stopped working'. I have learnt from experience, not to take this description too literally, as it usually means that someone relating to the computer is not working as expected. They were unable to give me more details and I could not find any logged errors. Hence it may or may not have been this error.

From the stack-trace, the actual error was when constructing a class which does not directly call any interop code, but perhaps complicated by the fact that the object may be part of a list that is databound to a DevExpress Grid.

The error was 'caught' by an unhandled exception routine which normally will close down the program, but has an option to ignore and continue. If they opted to ignore the error, then the program continued working but the error re-occurred when this routine was next run. However it did not occur again after closing and restarting our application.

The computer in question did not seem to be stressed out. It is running Vista Business, has 2GB of memory and according to Task Manager was only using about half of that with our application just about 200Mb.

There is one other piece of information that may or may not be relevant. Another section of the same program uses a third party component which is effectively a dotnet wrapper around a native dll and this component does have a known issue where very occasionally, you get a

Attempted to read or write protected memory. This is often an indication that other memory is corrupt

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 not been given to the customer yet.

Given that the consequences of the error are low (no work is lost and restarting the program and getting back to where they were only takes a minute at most) and given that the customer will shortly be getting a new version (with the updated third-party component), I can obviously cross my fingers and hope the error won't occur again.

But is there anything more I can do?

Allometry

Answer 1

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.

Telepathy

StackTrace didn't mention DevExpress anywhere, but just my class. Will have to check to see what the ErrorCode was. – Allometry

In that case, try to figure out what exactly threw the error message. – Telepathy

"by looking at the ExternalException.ErrorCode property" - do you have any hints on how exactly to do that? VS shows me "An unhandled exception of type 'System.Runtime.InteropServices.SEHException' occurred in ....dll Additional information: Eine externe Komponente hat eine Ausnahme ausgelöst.", but other than in e.g. C# applications, there is no link to look at "Details" of the exception object anywhere. – Boylan

VSCode's debugger shows an $exception instance under Locals - this includes a Message field, which includes the code and a human-readable error message. – Austronesia

Answer 2

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.

Zoroastrianism

Answer 3

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

Ely

Answer 4

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.

Boozy

Answer 5

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.

Concerning

I was getting it randomly while accessing different kinds of reflection (GetAssemblyName, GetProperty, Activator, etc.) both in my code and third party libraries, and just in one customer environment, similarly with libraries on remote location. Plenty of evidence it's .net framework bug. – Ellyellyn

Andriy K: I don't think this is a .NET problem, I think handles to opened file(s) on network share are lost\dropped somehow, maybe a bug in Windows or network problem. Assemblies are memory mapped and will be paged in from disk on demand (time bomb), possibly the memory can be discarded in low memory situations too. If the opened file handles are not stable this probably blows up in smoke. .NET could maybe had handled it and reopened the file (smooth over the problem), but it may be complicated. – Parrett

I have the same problem. I get System.Runtime.InteropServices.SEHException (0x80004005) with no stack trace. This is the InnerException of a TargetInvocationException. The TargetInvocationException does have stack trace, but it made no sense to me as it seemed to come from main or Application.Run. It happens very random, mostly at evenings\night. I guess the only "solution" is to not run from network drive:-| Maybe I add a check that can block this scenario: #8634180 – Parrett

Answer 6

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

Gawlas

Answer 7

My machine configurations :

Operating System : Windows 10 Version 1703 (x64)

I faced this error while debugging a 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.

After doing some analysis, I found that Visual Studio was running with a non-admin user account. So I relaunched Visual Studio under a different user account which had administrative privileges 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 further analysis. But I see a possibility that the whole thing was failing as administrative privileges are required to write in registry. So earlier when Visual Studio was running under a user account without administrative privileges on the machine, then the native calls were failing.

Strasser

Answer 8

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.

Serg

Answer 9

I got this error in a mere if like:

if (table.Equals("asd", StringComparison.OrdinalIgnoreCase))
{
...
}

Solved wrapping in a try catch like bellow. Why it happened, why it solved, still a mistery:

try
{
  if (table.Equals("asd", StringComparison.OrdinalIgnoreCase))
  {
  ...
  }
}
Exception()
{

}

Toggery