System.AccessViolationException

Posted by jmls on 03-Nov-2009 09:01

Running on 10.2A02, we seem to be getting a reasonable load of these messages: Any idea why ?
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
************** Exception Text **************
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Progress.ClrBridge.BrgClrToPro.WindowStateChanged(Int32 , Int32 )
   at Progress.ClrBridge.ClrApi.b(Object A_0, EventArgs A_1)
   at System.EventHandler.Invoke(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnSizeChanged(EventArgs e)
   at System.Windows.Forms.Control.UpdateBounds(Int32 x, Int32 y, Int32 width, Int32 height, Int32 clientWidth, Int32 clientHeight)
   at System.Windows.Forms.Control.UpdateBounds()
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at Progress.Windows.Form.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)

All Replies

Posted by Shelley Chase on 03-Nov-2009 12:31

Hi Julian,

That's not supposed to happen!

Any chance you have a reproducible case that you can report to tech support?

Thanks

-Shelley

Posted by jmls on 03-Nov-2009 13:32

Not yet - working on it

Posted by Peter Judge on 04-Nov-2009 11:26

This looks similar to something I've seen when a .NET object calls back into the AVM on the wrong (non-UI) thread. It might be related to the controls you're using.

-- peter

Posted by jmls on 04-Nov-2009 12:17

Heh. If you must know, Infragistics

Oh, and a web browser control (MS)

Crap, and ipworks .net controls.

I do, however, use the invokethrough methods on the ipworks to  bind the UI to the control.

Posted by jquerijero on 23-Apr-2010 10:58

Do you have any update on this issue? We are also experiencing a spike on customers reporting this error. Unfortunately, most of the time it doesn't even get to the point where it can generate a protrace file.

- We are on 10.2A0201

- Only the Main Form is using the ABL Form, all the rest of the windows are still .w's

- Error happens randomly

Posted by dlauzon on 29-Apr-2010 08:18

I had similar errors ~ once a day for several users, installing 10.2A03 got rid of the problem.

It seemed to be related to the user switching from one Window to another and occured from the WINDOW-CLOSE event.

Note that prior to having a .NET compatible WAIT-FOR statement, the error also occured, but instead of having a System.AccessViolationException, I had a standard prowin32.exe crash generating a procore file.

Posted by jquerijero on 29-Apr-2010 08:54

Did you open a Progress support case for this? Also, were you using the new GUI for .NET or just plain ABL code?

Thanks

Posted by dlauzon on 29-Apr-2010 09:30

I opened a support call for it.

The error occured in another form when not using GUI for .NET and in the form specified in this thread when I began using the .NET WAIT-FOR statement.

When I switched to the .NET WAIT-FOR statement, all my access violation  exceptions (Exception code: C0000005 ACCESS_VIOLATION) that previously  caused my prowin32.exe to crash and generate a protrace and a procore  file now ended up generating the .NET exception.   I hoped that I could  CATCH those .NET exceptions, but unfortunately I couldn't: the  application still crashed, but without the protrace and procore file.

The most frequent points of failure I had in the protrace file for prow32.dll:

0x00272be1 = pam_get_item + 6EDB1
0x0025908f = pam_get_item + 5525F
0x00295bd8 = pam_get_item + 91DA8 ++ this one was 9 out of 10 crashes
0x002d8417 = pam_get_item + D45E7
0x003266d0 = pam_get_item + 1228A0
0x004555ee = _wwProxInterfaceReadIcon@16 + 1547E
0x0047e293 = _wwProxInterfaceReadIcon@16 + 3E123

Posted by dlauzon on 29-Apr-2010 09:40

Note that although, according to the protrace line number info, the crash consistently occured on the "END." line of the WINDOW-CLOSE statement, the crash could occur when the user was not closing the window, but just switching to another window or a couple of seconds after closing a window or switching to a new window.

And as I said, when I switched to the .NET WAIT-FOR while that bug was still occuring, the error kept occuring at the same timing, but without the protrace and procore files.

Posted by dlauzon on 29-Apr-2010 09:42

And note also that the crash (access violation) did not occur in 10.1A03 but began to occur when we migrated to 10.2A02.

Posted by Garry Hall on 04-May-2010 12:31

Depending on the specific circumstances, the System.AccessViolationException is most probably the result of an access violation happening within the AVM, when .NET calls back into it.
In some situations, such exceptions are caught, displaying an error message such as:
   SYSTEM ERROR when running event dispatcher
   Exception code: C0000005 ACCESS_VIOLATION
   Fault address:  10022A61 01:00021A61 c:\dlc\102a\bin\prow32.dll

In other situations, this exception in the AVM is not caught in a timely place, and instead is caught where there is less diagnostic information available.
This is what happens when you see the following message:
   System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Please note that these exceptions can occur for different reasons. There is not one single cause of this exception,
just as there is not one single cause of an access violation and protrace file when not using GUI for .NET.
Each case would need to be investigated individually for the root cause.

If you are suffering from a System.AccessViolationException message, please log a call with Progress Technical Support,
and provide the following information:
- the ABL and .NET stack traces from the -debugalert window (you need to run with -debugalert)
- ideally, a reproducible case, or a local environment available where you can reproduce the problem readily.

This thread is closed