views:

777

answers:

1

We are having nondeterministic System.AccessViolationException thrown from native code. It's hard to reproduce it, but sometimes it happens. I'm not sure if I can "just debug it" since the time needed for access violation is about 2 hours and there is no guarantees that access violation will happen.

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

I have sources for everything, but (if possible) I want to avoid making large number of changes.

I believe native call stack will provide enough information about reason of this access violation.

Is there any effective ways of determining the reason of this access violation?

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

+1  A: 

If you can afford waiting for the exception to occur, attach the managed and native debugger (mixed debugging session), and set the managed debugger to break when an AccessViolationException is thrown. The managed debugger will break the process when it detects the unhandled exception, and you should then be able to see the native call stack.

Steve Guidi
Hm.. I changed my native code so it surely have access violation and recompiled it with debug symbols. When I started the process normally and attached Visual Studio debugger. I've added a breakpoint for throwing of AccessViolationException, but it wasn't catched. Any suggestions?
Dmitriy Matveev
OK, I'm found that breakpoint should be Win32 access violation.
Dmitriy Matveev