What are the challenges you face when working across database platforms? Take the survey

Error Reporting Not Working With AccessViolationException

martincostellomartincostello Posts: 21
edited September 13, 2011 11:59AM in SmartAssembly

As a proof-of-concept, I have created a sandbox WinForms application, that when a button is pressed, the event handler code is thus:
Marshal.StructureToPtr(new Point(), new IntPtr(-1), false);

This is to force an AccessViolationException to see whether the exception report would show the memory address and instruction address from the exception.

After SmartAssembly processes the application instead of a SmartAssembly dialog, the application immediately terminates (or shows the default Windows error reporting dialog).

I've also tried explicitly catching the AccessViolationException and using
the ExceptionReporting.Report(Exception) method to report it manually, to no avail.

It only seems to report the exception if I throw the AccessViolationException manually (which doesn't let me see the private fields containing the memory address and the instruction address), but that's obviously no good in practice.

Is there a reason why this isn't working? I want to be able to generate exception reports for AccessViolationExceptions so that if a crash occurs in a native component called via Inteop we can diagnose the issue in the native code to some degree via the managed exception reports.

Even without the detailed information about the AccessViolationException, even the fact that one happens appears to be completely missed by the SmartAssembly error handling.



  • Options
    As far as I know, AccessViolation exceptions are so critical they termainate the runtime. You can't really trash memory and expect the runtime to continue on to process the exception.

    You may want to have a look at this thread here as there may be an app config setting you can try: http://stackoverflow.com/questions/3312 ... ion-in-net
  • Options
    From MSDN regarding the UnhandledExceptionHandler (SA uses this):
    Starting with the .NET Framework version 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.
  • Options
    Thanks Brian. I wasn't aware of the change made in .NET 4.0 for the handling of AccessViolationException. I should have maybe done a bit more digging around on MSDN first. I compiled my sandbox app to test this out in VS2010, so it defaulted to .NET 4.0.

    Either changing the .NET Framework version, adding the configuration setting it behave as expected.

    With .NET 4.0 and without a process-wide change however, the only way I can get SmartAssembly to catch the AccessViolationException is to add the [HandleProcessCorruptedStateExceptions] attribute and then re-throw the exception.

    Maybe SmartAssembly could be changed at some point to allow an option for .NET 4.0 assemblies with error reporting added to get the code injected into the assembly to decorate your error handler with the appropriate attribute to allow it to catch such problems if wanted in the .saproj file?

    We would certainly find this beneficial as we could report exceptions caused by our native components, and then prevent the user from continuing, giving us enough leeway to report the error, but not allowing the process to continue longer than neccessary with potentially corrupted memory.

  • Options
    Hi Martin,

    I have created an issue with development ( SA-1096 ) to see if they can add the attributes to SmartAssembly's UnhandledExceptionHandler so that it will report access violations.

    Thanks for your feedback!
  • Options
    Thanks Brian.

Sign In or Register to comment.