31

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?
Liam
  • 27,717
  • 28
  • 128
  • 190
chillitom
  • 24,888
  • 17
  • 83
  • 118
  • 1
    Have you tried running this with a debugger attached, also with enough symbols loaded to give a useful callstack? – Chris O Apr 20 '12 at 01:52

5 Answers5

7

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.

Mike Caron
  • 14,351
  • 4
  • 49
  • 77
  • 1
    It's not a worker thread, this dies on the main UI thread. Note Application.Run() – Hans Passant Feb 27 '11 at 15:49
  • 1
    Agree with Hans comment. We get reports of this very occasionally on users' machines in .NET Reflector: Application.Run() throws an AccessViolationException, but we have no idea why. It's very uncommon and we've never seen it in house, so we've never been able to debug it. I'd love some tangible idea of what's going wrong so we could at least point users in the direction of some useful information but, alas, so far I am denied. – Bart Read Aug 05 '11 at 20:08
3

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.

Steve Mitcham
  • 5,268
  • 1
  • 28
  • 56
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!

David
  • 437
  • 4
  • 12
2

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)
Apex ND
  • 440
  • 5
  • 12
2

The stacktrace tells you nothing :-(. Can you update your packages to see, if the exception is gone? I've seen System.AccessViolationException with None-Threadsafe Com-Objects when accessing Properties from a workerthread. So yes, I can imagine the exception is caused by using an earlier non-threadsafe version from some API.

I dealed with the situation by adding Attributes

[HandleProcessCorruptedStateExceptions]
[SecurityCritical]

to the Method, in which I access these conflicting Properties from the COM-Object. Also I had to add the 

<legacyCorruptedStateExceptionsPolicy enabled="true" />

Setting to my app.config, and was than able to catch these Exceptions, and handle wisely.

More Information Corrupted State Exceptions MS Docs By handling Corrupted State Exceptions and don't shut down the process, you leaving the way, where "CLR offers some pretty strong guarantees about program correctness and memory safety".

Credits to https://stackoverflow.com/a/4759831/1196586

gReX
  • 1,060
  • 1
  • 20
  • 35