Question

I have received from user that my application has crashed and that he saw this in event viewer:

Framework Version: v4.0.30319    
Description: The process was terminated due to an unhandled exception.
    Exception Info: System.AccessViolationException
    Stack:
       at System.Drawing.SafeNativeMethods+Gdip.GdipDrawRectangleI(System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, Int32, Int32, Int32, Int32)
       at System.Drawing.Graphics.DrawRectangle(System.Drawing.Pen, Int32, Int32, Int32, Int32)
       at System.Windows.Forms.ToolStripTextBox+ToolStripTextBoxControl.WmNCPaint(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.ToolStripTextBox+ToolStripTextBoxControl.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
       at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
       at System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Form.DefWndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.ScrollableControl.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Form.WndProc(System.Windows.Forms.Message ByRef)
       at DeskandArchive.MainWindow.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
       at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
       at System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32, Int32)
       at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
       at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
       at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
       at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
       at A.cc1462b28845fccfe3634174d36bc619a.ce1b648a1c328cbefe2529fb98bf21b8c()

As far as I have searched through the internet, and as I can read from this, also including the fact that if my code crashes it should show dialog to report bug which user did not see, I came to conclusion that this is a bug in .NET framework in drawing of Toolstrip.

Am I right on this? Is there some way that this can be fixed? I have read suggestions to reinstall .NET framework, but most people reported that it didn’t help?

Answer 1

It is not ToolStrip that crashed, it is GDI+. GDI+ is a chunk of unmanaged code that existed long before .NET ever came around, System.Drawing is the namespace with wrapper classes for it. Like the Graphics class, used in this stack trace.

Getting GDI+ to crash is quite rare, the .NET wrapper classes are very good at preventing bad arguments from getting passed to GDI+’s functions. Getting an AccessViolation like this requires corrupting the heap that GDI+ uses. The heap gets corrupted by pointer bugs in unmanaged code. That could be your code, notable is that you are overriding WndProc(). But more typically it is some app that injects itself into your process. Either intentionally, like a virus scanner, or accidentally like a shell extension handler that gets loaded when you use OpenFileDialog. Such extensions can use GDI+ as well, it is common, or just have a bad pointer that sprays garbage anywhere.

You will never find out from a managed stack trace, the damage is done long before GDI+ falls over. This makes diagnosing heap corruption bugs incredibly difficult and a large reason for Java and .NET to become very popular platforms. It becomes impossible when you cannot exactly duplicate the user’s runtime environment. Bugs like these are almost always closed with “no repro”, like it would be if you submit it to Microsoft with only the stack trace as evidence. It is up to you to pursue a repro scenario but beware you’ll have a very hard time with it. Best thing to tell the user is to use another machine or otherwise get her machine stable again by uninstalling unnecessary or risky programs. Especially shell extensions.