finding the cause of System.AccessViolationExcepti

问题:

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?

回答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.

回答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.

回答3:

I had a similar problem and unlike @BartRead, consistently. For me, some CLI code was working fine in a simple windows forms app, but when i put it in a larager plugin ecosystem (multithreaded) the messages needed pumping with Application.Run or Application.DoEvents. If you have access to the code being pumped, the best bet (what worked for me) was to comment out more and more pieces of the code while still maintaining functionality. It turned out I had not GC::Alloc'd a callback/delegate and while pinned and still referenced had been moved around in memory or straight up flagged for collection.

if you use GC Alloc be sure to clean up after yourself!

回答4:

i had this problem when executing a stored procedure using ADO. this error had two causes:

1. bad connection string.
2. parameter type miss-match (passing in a long for db-int32 or long to nvarchar(10) which is shorter)