Options
Error Reporting Not Working With AccessViolationException
martincostello
Posts: 21
Hi,
As a proof-of-concept, I have created a sandbox WinForms application, that when a button is pressed, the event handler code is thus:
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.
Regards,
Martin
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.
Regards,
Martin
Comments
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
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.
Thanks,
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!
Martin