views:

1638

answers:

2

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 literately, 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's of memory and according to TaskManager was only using about half of that with out 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 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 give 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?

+3  A: 

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.

Reed Copsey
StackTrace didn't mention DevExpress anywhere, but just my class. Will have to check to see what the ErrorCode was.
sgmoore
In that case, try to figure out what exactly threw the error message.
Reed Copsey
A: 

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.

ChrisW