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