What does this mean when a .NET application crashes due to a System.AccessViolation exception?

Question

The application itself is 2000 lines long, so it makes no sense to embed code here, especially since the exception that one of the users received does not give any hints as to what part of my code is causing the problem.

An application, by the way, is simply a Windows form with a datagridview, which usually displays no more than a few hundred lines of data and some other controls. Before it crashed, it slowly loaded the cells of each data series. (But no other user has encountered the same problem.)

The text of the exception is given below. Can someone please review it and tell me if this is caused by something that my code is doing wrong or maybe something is incompatible with the specific setting of the user who experienced this exception?

I notice that the description below indicates that the memory is corrupt. Does this mean that the user computer has bad RAM ???

************** Exception Text ************** System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.Drawing.SafeNativeMethods.Gdip.GdipDrawRectangleI(HandleRef graphics, HandleRef pen, Int32 x, Int32 y, Int32 width, Int32 height) at System.Drawing.Graphics.DrawRectangle(Pen pen, Int32 x, Int32 y, Int32 width, Int32 height) at System.Windows.Forms.ControlPaint.DrawFlatCheckBox(Graphics graphics, Rectangle rectangle, Color foreground, Brush background, ButtonState state) at System.Windows.Forms.ControlPaint.DrawFlatCheckBox(Graphics graphics, Rectangle rectangle, ButtonState state) at System.Windows.Forms.ControlPaint.DrawCheckBox(Graphics graphics, Int32 x, Int32 y, Int32 width, Int32 height, ButtonState state) at System.Windows.Forms.ControlPaint.DrawCheckBox(Graphics graphics, Rectangle rectangle, ButtonState state) at System.Windows.Forms.CheckedListBox.OnDrawItem(DrawItemEventArgs e) at System.Windows.Forms.ListBox.WmReflectDrawItem(Message& m) at System.Windows.Forms.ListBox.WndProc(Message& m) at System.Windows.Forms.CheckedListBox.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) 

Answer 1

Without extra code, it's hard to say for sure. Here are some things to note.

.NET is a managed environment, and one of the fundamental principles is the ability to verify code at compile time. In particular, this means that some guarantees can be made regarding a unit of code, for example:

• Inability to read outside the array
• Inability to change function pointers
• Inability to read / change memory code segments
• Inability to confuse the type of object reference

Attempting to do this will either fail at compile time or at runtime with an exception.

The exception you see is due to "unsafe" code. Unsafe - this is a little wrong, it is better to call it "unverifiable". Sometimes, for performance reasons, it is necessary to abandon code verifiability in exchange for raw speed through such things as pointer arithmetic.

There is no unsafe code in this application.

WinForms makes extensive use of "unsafe" code. Rather, your assembly does not contain any unsafe code, but it depends on the unsafe library code.

I notice that the description below indicates that the memory is corrupt. Does this mean that the user's computer has poor RAM?

Bad RAM is an opportunity, but very unlikely. The memory is corrupted when the expected values ​​are actually missing there. This may be due to hardware malfunction, as well as software errors. This exception usually occurs in response to software errors in my experience. The message also says that the memory may be damaged.

The stack trace may not really be very insightful, as the memory was most likely corrupted at an earlier time and was only detected during the stack frame that you see here.

there is 1 platform call for the user32.dll function ShowWindow (ShowWindow (p.MainWindowHandle, SW_SHOWDEFAULT);), but this call is made before the message loop is started.

It could be a criminal. Have you tried using managed Window.Show instead? Perhaps your window does not yet have a handle, or that it is changing, or that because of this, several errors have occurred because of this. In fact, try to avoid PInvoke when using managed shells on top of your own files.

Unfortunately, without seeing more of your code, it is impossible to provide a more useful answer, but I hope the above provides some context for exclusion and can help you find out what your application is doing to get WinForms in this state.

Answer 2

I want to mention this because this exception has appeared for me, and it took me a couple of days to figure it out. I have no idea if the problem is related above, but maybe this will help someone who comes looking for the indicated exception.

I tested some registration code, and as soon as the tests were checked, we will see that the exception appeared on the build server. We could not recreate it locally on our dev machines.

I decided to move the logic from the constructor to the method, and suddenly the exception changed to System.EntryPointNotFoundException!

In our test harness, we organized objects using System.WebAPI, which the registrar did not refer to. A link to the correct libraries fixed the problem.

TL DR; Do not put your business logic in Ctor and check your links when you see this exception.