Access Violation: Attempted to read or write protected memory

Question

I have a c# (.net 4.0) winforms application that runs pretty much every week day, 8 hours a day, on an XP SP 3. It works fine most of the time, sometimes for months. Then it seems to get in a bad spell, and once a day, for a few days in a row, at various times, an access violation exception comes up. I've tried looking at the dump file, and catching the access violation exception to look at the stack; either way, I get pretty much the same stack:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.ToolTip.WndProc(Message& msg)
   at System.Windows.Forms.ToolTip.ToolTipNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   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)

I'm having a very hard time fixing this because the stack trace isn't very useful. First, I'm not even sure if I can trust the stack trace: does the program get there (looks like it's trying to display some tooltip, which is certainly possible) because memory is already corrupted, or if the program really should legitimately be there, but some data memory is corrupted. Second, assuming the stack trace is correct and trustworthy, I don't see a way to figure out what is corrupting the memory... We are not doing anything consistent to trigger the access violation... the application log does not show any other caught exceptions before then... the event logs don't show any entries at the same time as the access violation... Any hints on how to further diagnose this?

Update 2011-10-11: I'm already catching the exception, but around the Application.Run() method. At that point it seems it's too late to do much. Just in case this exception is happening due to faulty hardware/driver and does not indicate that the application's memory is corrupt -- would there be any place else that I could catch the exception (and display it, but then let the application continue)?

Update 2012-03-04: I got the exception again, this time after displaying a fairly trivial form (only contains a textbox and an ok button). I was using TextBox.AppendText(). I just so happened to be browsing this comment at the same time. Could AppendText() be causing the issue? When the 'original' access violations occur, they tend happend after displaying a form that contains a richtextbox on which I also call AppendText(). The plot thickens!

Update 2012-03-06: I removed AppendText and just used TextBox.Text = instead, but I got the access violation exception again today. Thus, AppendText does not seem to be the culprit. Furthermore, the exception happened once on a dev box, running Windows 7. Thus, it does not seem like the exception is specific to Windows XP, or to the other computer (like a memory issue).

Answer 1

I found that this problem occurs (crash) not only in WPF, but for WinForms. My problem was related to OpenFileDialog. It is hard to say what is the source of the problem, but still it appears that Microsoft dll related to OpenFileDialog has bugs (for me, it was ComDlg32.dll)

The only way I could call ShowDialog() function was to wrap it in the event and call with the help of

this.BeginInvoke(
        new Action<YourObject, EventArgs>(YourObject_FileDialogOpened), new object[] 
                                                        { YourObjectInstance, e });

where "this" is a Control (for example, Form).

BeginInvoke(...) grants that you call will be process in a proper way.

Problem will not appear if you use call of the OpenFileDialog under button click event or any other similar scenario.

Answer 2

I was able to duplicate the issue thanks to this post . So, one work-around appears to disable all tooltips in all datagridview using DataGridView.ShowCellToolTips = false; However, this is not ideal. A better work-around is to call

Application.EnableVisualStyles();

before any controls are created in the app.

I have confirmed that the issue occurs whether the DataGridView is displaying custom tooltips (with CellToolTipTextNeeded) or not.

Answer 3

I was suffering the same behavior as the OP. I had revised a piece of software and added two PInvoke methods (to improve the UI). Unfortunately, I started receiving the same messages as the OP. In looking over the answers, I found Raja Hindustani's. Upon commenting out the two PInvoke methods, the problem appears to have disappeared.

Answer 4

We recently also got an AccessViolationException when doing TextBox.AppendText(). After trying to reproduce the problem we realized that the TextBox wasn't the problem. In our case it was the drag-and-drop feature.

Here is a minimal project (a Form with a TextBox) that will reproduce the exception:

using System;
using System.Windows.Forms;

namespace TestTextBoxAccessViolation {
    public partial class Form1 : Form {


        public Form1() {
            InitializeComponent();
        }

        private void Form1_DragEnter(object sender, DragEventArgs e) {
            e.Effect = DragDropEffects.Copy;
        }

        private void Form1_DragDrop(object sender, DragEventArgs e) {
            e.Data.GetData("DragImageBits");
            Form1 f = new Form1();
            f.textBox1.Text = "Keep resizing this window and you'll get an AccessViolationException after a while";
            f.Show();
        }
    }
}

Conclusion: Don't use "DragImageBits".

Answer 5

I've observed this issue when calling into a third party C# wrapper for a C dll. I disabled DEP for the C# dll, using the utility editbin.exe /NXCOMPAT:NO {dll name} and that seems to have fixed the issue.

I CLR should be doing additional checks when DEP is turned on and the C dll might be doing something which the CLR deems as memory corruption and throws this error.

You can read more about this at, http://blogs.msdn.com/b/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx

Answer 6

That isn't easy to trace/fix since all information is rather "generic" so these are some general pointers:

• Does it always happen on the same machine ?
  IF yes, then it could be worth to check the machine (memory tests etc. run from a bootable linux CD or similar) and/or run it on a different machine to see if it changes...

• The exception seem to happen when displaying a tooltip... could indicate a problem with the graphic card driver... choose a different driver and/or different screen resolution etc. and see what happens

• Are you using some 3rd-party libraries ?
  IF so it could be worth it to check them for unmanaged memory issues (for example with a memory profiler...). Check with the vendor(s) whether there are newer versions etc.
  I had sometime ago something similar and it turned out to be an unmanaged memory leak inside some 3rd-party library (diagnosed via memory profiler)... I check with vendor and got a fixed version which runs smoothly ever since...

Answer 7

Not sure if this will be any help but this problem seem to be common in older versions of .Net and Microsoft even released some fixes for that.

One of the initial fix was as follows,

http://support.microsoft.com/kb/923028

Here is another one. http://support.microsoft.com/kb/975954