CODEWITHSUNDEEP
c#.netexceptionaccess-violation
chillitom
chillitom

Reputation: 25676

Finding the cause of System.AccessViolationException

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."

UPDATE

Upvotes: 33

Views: 43082

Answers (5)

gReX
gReX

Reputation: 1080

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

Upvotes: 2

Apex ND
Apex ND

Reputation: 450

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)

Upvotes: 2

David
David

Reputation: 437

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!

Upvotes: 3

Steve Mitcham
Steve Mitcham

Reputation: 5313

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.

Upvotes: 3

Mike Caron
Mike Caron

Reputation: 14561

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.

Upvotes: 7

Related Questions