Determine the cause of a System.AccessViolationException exception

Question

We have a non-determinate System.AccessViolationException thrown from native code. It is difficult to reproduce it, but sometimes it happens. I’m not sure if I can “just debug it”, since the time required for violation of access rights is about 2 hours, and there are no guarantees that violation of access rights will occur.

A proprietary library is used by managed wrappers. It was used from java through the JNI, and it was used with .NET through the IKVM'ed JNI. The problem was reproduced only from the IKVM code, but the data sets are different and there is no way to test the Java application with the data used by the IKVM application.

I have sources for everything, but (if possible) I want to avoid a lot of changes.

I believe that the built-in call stack will provide enough information about the cause of this access violation.

Are there any effective ways to determine the cause of this access violation?

I think that the ideal solution for me is some changes in the code or working environment, so it will crash with a memory dump in case of this access violation, so I can make changes and just wait.

Answer 1

If you can afford to wait for an exception to occur, attach a managed and native debugger (mixed debugging session) and set up a managed debugger to break when an AccessViolationException . A managed debugger will abort the process when it detects an unhandled exception, and then you can see your own call stack.