Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Determine reason of System.AccessViolationException

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.

like image 298
okutane Avatar asked Jul 01 '09 06:07

okutane


People also ask

What causes AccessViolationException?

An AccessViolationException exception is always thrown by an attempt to access protected memory -- that is, to access memory that is not allocated or that is not owned by a process. Automatic memory management is one of the services that the common language runtime provides.

What is exited with code 0xC0000005 access violation?

It is stated that 0xC0000005 error usually occurs when a particular application is trying to access memory, which is no longer available or can't be accessed for some reason.

What is read access violation?

A Read or Write Access Violation occurs when the application attempts to read or write memory from a memory address that is invalid. To be valid, the memory page must have a valid state, protection and type. The memory must be in the MEM_COMMIT state.


1 Answers

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.

like image 79
Steve Guidi Avatar answered Oct 07 '22 17:10

Steve Guidi