[c#] Attempted to read or write protected memory

I've started seeing an AccessViolationException being thrown in my application a several different spots. It never occured on my development pc, our test server. It also only manifested itself on 1 of our 2 production servers. Because it only seemed to happen on one of our production servers, I started looking at the installed .net framework versions on the servers.


I found that (for some strange reason), the production server that was having problems had 2.0 sp2, 3.0 sp2, and 3.5 sp1, while the other production server and the test server had 2.0 sp1.


My app only targets the 2.0 framework, decided to uninstall all the framework versions from the production server and install only 2.0 sp1. So far I have not been able to reproduce the problem. Very interesting.

Development pc: compact 2.0 sp2, compact 3.5, 2.0 sp2, 3.0 sp2, 3.5 sp1 Test server: 2.0 sp1 Production server1: 2.0 sp1 Production server2: 2.0 sp2, 3.0 sp2, 3.5 sp1

Now, why I can't reproduce the problem on my development pc which has 2.0 sp2 on it, I can't figure out. I heard rumors that this access violation may happen on some software that utilizes remoting, which mine does, but the access violation never happends when remoting is actually occuring. I'm ok with using only 2.0 sp1 for now, but I'm really interested to know if anyone has had this issue, and if they found a workaround for newer versions of the frameowork.

Here's a couple of the exceptions and their stack traces:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at ICSharpCode.TextEditor.TextArea.HandleKeyPress(Char ch)
   at ICSharpCode.TextEditor.TextArea.SimulateKeyPress(Char ch)
   at ICSharpCode.TextEditor.TextArea.OnKeyPress(KeyPressEventArgs e)
   at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
   at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
   at System.Windows.Forms.Control.WmKeyChar(Message& m)
   at System.Windows.Forms.Control.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)

System.AccessViolationException: 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.Control.DefWndProc(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.TextBoxBase.WndProc(Message& m)
   at System.Windows.Forms.RichTextBox.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)

In my case I had trouble with the "Environment variables" while adding reference to my COM DLL.

When I added the reference to my project, I was looking for P:\Core path, whereas I had added the c:\core path in past into path environment varaible.

So my code was attempting wrong path first. I removed that and un-registered the DLL reference and re-registered my DLL reference using (regsvr32). Hope this helps.

I had the same problem after upgrading from .NET 4.5 to .NET 4.5.1. What fixed it for me was running this command:

netsh winsock reset

The problem may be due to mixed build platforms DLLs in the project. i.e You build your project to Any CPU but have some DLLs in the project already built for x86 platform. These will cause random crashes because of different memory mapping of 32bit and 64bit architecture. If all the DLLs are built for one platform the problem can be solved. For safety try bulinding for 32bit x86 architecture because it is the most compatible.

I was using OLEDB and I switched to SQL Client and it solved my problem with this error.

Check to make sure you don't have threads within threads. That's what caused this error for me. See this link: Attempted to read or write protected memory. This is often an indication that other memory is corrupt

Microsoft also released a hotfix (July 2nd, 2007) to prevent the error "Attempted to read or write protected memory" that has been plaguing the .NET 2.0 platform for some time now. Look at http://support.microsoft.com/kb/923028 - not sure if it applies to you, but thought you might like to check it out.

In my case this was fixed when I set up 'Enable 32 Bit applications'=True for Application pool in IIS server.

In some cases adding "Option Strict On" in VB.NET and resolving all issues it finds by proper casting has solved this problem for me.

Hi There are two possible reasons.

1. We have un-managed code and we are calling it from managed code. that is preventing to run this code. try running these commands and restart your pc

   cmd: netsh winsock reset

open cmd.exe and run command "netsh winsock reset catalog"

2. Anti-virus is considering un-managed code as harmful and restricting to run this code disable anti-virus and then check

In my case fonts used in one of the shared library was not installed in the system.

For VS 2013, .NET Framework 4.5.1 also has a AccessViolationException bug (KB2915689) when dealing with SQL Server / TCP Sockets. Upgrading to .NET Framework 4.5.2 corrects this problem.

Reported VS.NET AccessViolationException

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I usually get "Attempted to read or write protected memory" when calling the "Show" method on some WinForms. I checked and there doesn't appear anything special about those forms. I don't know why this works (maybe someone can tell me) but usually moving the code that gets executed in the "Load" event of the form to the "Shown" event fixes it for me and I never see it again.