Finding the cause of System.AccessViolationException

Question

Our application experiences the odd fatal System.AccessViolationException. We see these as we've configured the AppDomain.CurrentDomain.UnhandledException event to log the exception.

Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.    at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)    at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)    at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)    at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)    at System.Windows.Forms.Application.Run(Form mainForm)    at Bootstrap.Run() in e:\build-dir\src\Bootstrap.cs:line 25 

The exception itself doesn't seem to contain any more information than the message "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

• What steps can we now take to get to the cause of the problem?
• Is there any way to determine the illegal address or pointer value that caused the crash?
• Can we find out what native library code was causing the problem?
• Is there more debugging/tracing we can enable?

UPDATE

• Could this be caused by earlier non-threadsafe use of the WinForms API?

Answer 1

What you are experiencing is the exact equivalent to "The program has experienced a problem and will now close", except it's being caught by the .NET runtime, rather than the OS.

Looking at the stack trace, it's not being triggered by your code, which makes me think that it's coming from a worker thread spawned by a library you're using or a custom control.

The only way to track something like this would be to run the native libraries under a debugger, which should trap the access violation before it bubbles up to the CLR layer. This can be easy or hard.

If the native code is your own project, then the easiest way to set this up is to put both the .NET project and the C++ project in the same solution, and ensure that the .NET project is referencing the C++ project. If you post more details about your environment, I may be able to give more specific advice.

Answer 2

The stack trace points to bad data in the MSG parameter of the native dispatch messenger. Have you tried loading the symbols from Microsoft and checking the parameters of that stack trace.

Without knowing the controls on your ui and whatever events you have connected to, it will be difficult to determine what exactly is the problem.