Attempted to Read or Write Protected Memory

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

Finally tracked this down with the help of WinDBG and SOS. Access violation was being thrown by some unknown DLL. Turns out a piece of software called "Nvidia Network Manager" was causing the problems. I'd read countless times how this issue can be caused by firewalls or antivirus, neither of which I am using so I dismissed this idea. Also, I was under the assumption that it was not environmental because it occurs on more than 1 server using different hardware. Turns out all the machines I tested this on were running "NVidia Network Manager". I believe it installs with the rest of the motherboard drivers.

Hopefully this helps someone as this issue was plaguing my application for a very long time.

VB.Net in Visual Studio 2015 - Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I succeeded with a brute force workaround. I discovered that the problem happened if I selected the troublesome item from the ListView without first having selected any other items from the ListView which didn't cause the problem. So, the solution was somehow to select an item which didn't cause the problem before selecting one that did. How would I know which one I could select that wouldn't cause the problem? Also, if there were only one item in the list, what could I do then?

The solution was to create a dummy document and always load it first.

As before, the user selects a category that populates the ListView (lvwDocuments), which displays the coversheets that represent the scan sets. Now, however, before those coversheets are loaded into the list, an item is loaded that represents the dummy coversheet. (The first item in the list is the dummy coversheet and the rest are valid items for the category selected.) Based on that dummy item as the first item in the list, I load the dummy document onto a tab in the tabControl (tcDocumentScanInstances). I delete the dummy coversheet item from the ListView (lvwDocuments) and hide the dummy document on the tab with a panel that displays a message telling the user that scan instances will appear in tabs when a coversheet item is selected. (Surprisingly, it actually looks better than the interface I had before and the message does not seem unnecessary or out of place!) The user never sees dummy item in the list as it is loaded and deleted so quickly.

There you have it. From what I found when searching for a solution, there seem to be so many different situations in which this error occurs. I wish I knew a better way to prevent this, a way that could be applied to other situations, as well. This solution works for me in this instance. I hope it helps someone somehow.

VB.NET Access - Attempted to read or write protected memory

I change Provider from:

"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\DbTest\Test.accdb;Persist Security Info=False;"

to:

 "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\DbTest\Test.accdb; OLE DB Services=-1"

only added: "OLE DB Services=-1" and all working good now :-).

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

You are using a lambda as a thread function. This lambda is called on a new thread. At the
moment the thread is actually created, it will look for the argument you supply, which is a local variable srUrl, but by the time this happens your function (dispatcherTimer_Tick) has already exited, so srUrl will be in a part of the stack that is no longer properly defined (hence the access violation). The easy fix is to define a variable in the class and stuff the srLoc there quickly. A more proper solution is to actually pass the srLoc as argument:

() =>
{
    startNewWindow(srUrl);
}

becomes

(Action<string>){x => {startNewWindow(x);},
            new object[] {srUrl}

Now the function reference and a proper copy of the string are saved for the function call, and it doesn't matter that the original srUrl is out of scope by the time the thread kicks in. I'm not sure whether the task factory allows the argument array to be passed. dispatchers normally have an overload for this, so maybe you want to let your window take care of this.

Now you actually do this a few times, so you may need to wrap the arguments each time they are passed.

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

This is usually caused by an incorrect Private Declare Function statement. The types listed in the Windows API are different to those used in VB or C# code. This is a great list of data type conversions between the Windows API and .Net: Win32 API C++ to .NET

The PInvoke site often has the correct VB code listed.

For RegEnumValue, fix the data types, and lpcValueName is a ByRef, not a ByVal:

Declare Auto Function RegEnumValue Lib "Advapi32" ( _
    ByVal hKey As IntPtr, _
    ByVal dwIndex As Integer, _
    ByVal lpValueName As StringBuilder, _
    ByRef lpcValueName As Integer, _
    ByVal lpReserved As IntPtr, _
    ByVal lpType As IntPtr, _
    ByVal lpData As IntPtr, _
    ByVal lpcbData As IntPtr _
) As Integer

For RegCloseKey, just fix the data types:

Declare Function RegCloseKey Lib "advapi32.dll" ( _
    ByVal hKey As UIntPtr _
) As Integer

For RegOpenKey, fix the data types and change phkResult to a ByRef:

Private Declare Function RegOpenKey Lib "advapi32.dll" Alias "RegOpenKeyA" ( _
    ByVal hKey As Integer, _
    ByVal lpSubKey As String, _
    ByRef phkResult As IntPtr _
) As Integer

So your function should look more like this. Unfortunately, I'm not sure what to write for strData or RetvalData. I added in a Try/Finally block which will make sure RegCloseKey is called even if an error occurs. You want to make sure you always close things, especially if something goes wrong.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Const Buffer As Long = 255
    Dim hKey As IntPtr = IntPtr.Zero
    Dim num As Integer = 0
    Dim strName As New StringBuilder
    Dim strData As IntPtr = ' I'm not surte what goes here.
    Dim Retval As Integer = Buffer
    Dim RetvalData As IntPtr = ' I'm not surte what goes here.
    If RegOpenKey(HKEY_CURRENT_USER, "Control Panel\Desktop", hKey) = 0 Then 'error
        Try
            While RegEnumValue(hKey, num, strName, Retval, IntPtr.Zero, IntPtr.Zero, strData, RetvalData) <> ERROR_NO_MORE_ITEMS
                If RetvalData > 0 Then
                    ListBox1.Items.Add(strName.ToString + Retval + "  =  " + strData + RetvalData - 1)
                End If
                num = num + 1
                strName = New StringBuilder(Buffer)
                strData = ' I'm not sure what goes here.
                Retval = Buffer
                RetvalData = ' I'm not surte what goes here.
            End While
        Finally
            RegCloseKey(hKey)
        End Try
    Else
        ListBox1.Items.Add("Error")
    End If
End Sub

Random error: Attempted to read or write protected memory

In my experience, that message was a result of a memory leak. This is what I'd do if I am in your situation especially since you are working on a third-party DLL.

1) Monitor your WCF server and see what is going on with the DLLHost.exe and the aspnet services in the task manager. I have a feeling that your third-party DLL has a memory leak that causes these 2 services to bloat and reach the limit of your servers memory. This is the reason why it works for a while and then suddenly just stopped working.

2) Identify a good schedule on when you can recycle your servers memory and application pool. Since the issue is rampant, you might want to do this every midnight or when no one is actively using it.

3) Write a good error logging code to know exactly what is happening during the time it bogged down. I would put the following information on the error logs: The parameters that you are passing, the user who encountered that problem etc. This is so you will know exactly what is happening.

4) Check the Event Viewer as maybe there is some information in there that can pinpoint the problem.

4) After doing 1, 2, and 3 and I will call your third-party DLL vendor and see what they can do to help you. You might need to provide the information that you collected from 1, 2, 3 and 4 items from above.

Good luck and I hope this will help.

Attempted to read or write protected memory

I had the same problem.
2.0 worked fine. after installing up to 3.5 sp1, application gets Access Violation.

installed http://support.microsoft.com/kb/971030 and my problem is solved, even though I am not using LCG.

OpenGL / OpenTK Drawing with Indices : Attempted to Read or Write Protected Memory Issue

EnableClientState and VertexAttribPointer do not interact together. If you want to use the client side capabilities, then you have to use VertexPointer (see glVertexPointer):

GL.VertexAttribPointer(0, 3, VertexAttribPointerType.Float, false, Vector3.SizeInBytes, 0);

GL.VertexPointer(3, VertexAttribPointerType.Float, Vector3.SizeInBytes, 0);

GL.EnableClientState(ArrayCap.IndexArray); does not do what you expect. ArrayCap.IndexArray is meant for color index attributes.

The index buffer is bound to the target BufferTarget.ElementArrayBuffer. It is not an attribute and has not to be enabled.

Further more the index buffer is stated in the vertex array object. The instruction GL.BindBuffer(BufferTarget.ElementArrayBuffer, 0); would break the binding:

private void LoadIndices()
{
    int ibo = GL.GenBuffer();
    GL.BindBuffer(BufferTarget.ElementArrayBuffer, ibo);
    GL.BufferData(BufferTarget.ElementArrayBuffer, sizeof(int) * indices.Length, indices, BufferUsageHint.StaticDraw);
    // GL.VertexAttribPointer(...) <--- REMOVE
    // GL.BindBuffer(BufferTarget.ElementArrayBuffer, 0); // <--- REMOVE
    RenderLoop.VBOs.Add(ibo);
}

The client side capability is stated in the Vertex Array Object. So it can be stated in LoadVerts():

private void LoadVerts()
{
    int vbo = GL.GenBuffer();
    GL.BindBuffer(BufferTarget.ArrayBuffer, vbo);
    GL.BufferData(BufferTarget.ArrayBuffer, Vector3.SizeInBytes * verts.Length, verts, BufferUsageHint.StaticDraw);
    // GL.VertexAttribPointer(...); <---- REMOVE
    GL.VertexPointer(3, VertexAttribPointerType.Float, Vector3.SizeInBytes, 0); // <--- ADD
    GL.EnableClientState(ArrayCap.VertexArray); // <--- ADD
    GL.BindBuffer(BufferTarget.ArrayBuffer, 0);
    RenderLoop.VBOs.Add(vbo);
}

All the necessary specification is stated in the Vertex Array Object, so it is sufficient to bind the VAO, before the draw call:

public void Render()
{
    GL.BindVertexArray(this.GetVAO());
    GL.DrawElements(PrimitiveType.Triangles, this.Indices.Length, DrawElementsType.UnsignedInt, 0);
    GL.BindVertexArray(0);
}

private void Render(object sender, FrameEventArgs e)
{
    GL.Color3(Color.Green);
    foreach (Mesh mesh in SceneMeshes)
        mesh.Render();
}

---

Related Topics