Попытка чтения или записи в защищенную память. Это часто указывает на то, что другая память повреждена

Я только что столкнулся с этой проблемой в VS 2013 .NET 4.5 с DLL MapInfo. Оказывается, проблема заключалась в том, что я изменил платформу для сборки с x86 на любой процессор, и этого было достаточно, чтобы вызвать эту ошибку. Изменение его обратно на x86 сделал трюк. Может помочь кому-нибудь.

попробуйте выполнить эту команду

netsh winsock reset

Источник:https://stackoverflow.com/a/20492181/1057791

Я также столкнулся с этой проблемой с Visual Studio 2010. Более интересно, что у меня было несколько проектов в моем решении (консольное приложение, приложение WPF, приложение Windows Forms), но это не удавалось только тогда, когда я устанавливал проект, который имел тип "консольное приложение", как проект запуска (даже для тех, у которых буквально не было кода или каких-либо дополнительных сборок, упомянутых помимо стандартных, которые поставляются с самим шаблоном проекта).

после изменения, наконец помог мне решить эту проблему: перейдите к свойствам проекта консольного приложения project - > Go to Debug tab - > перейти к в правой панели -> Регистрация Enable unmanaged code debugging флажок, как показано на снимке ниже. Первопричина того, почему это произошло, мне до сих пор не известна. Единственное, что я заметил, было то, что было много обновлений windows, которые были установлены на моей машине предыдущей ночью, которые в основном состояли из обновлений office и обновлений ОС (более десятка КБ статьи.)

эта ошибка не должна возникать в управляемом коде. Это может решить проблему:

перейдите в отладчик Visual Studio, чтобы обойти это исключение:

Tools menu ->Options -> Debugging -> General -> Uncheck this option "Suppress JIT optimization on module load"

надеюсь, что это поможет.

проблема может быть связана со смешанными платформами сборки DLL в проекте. т. е. вы создаете свой проект на любом процессоре, но у вас есть некоторые DLL в проекте, уже построенном для платформы x86. Это приведет к случайным сбоям из-за различного отображения памяти 32-битной и 64-битной архитектуры. Если все библиотеки DLL построены для одной платформы, проблема может быть решена.

У меня была эта проблема недавно, когда я изменил сервер разработки для проекта. Я получал эту ошибку в строке кода, где я объявил новую переменную OracleConnection.

после многих попыток, включая установку исправлений, я попытался изменить ссылки Oracle.DataAccess и система.Данные.OracleClient в проекте и это сработало!

когда проект перемещается на новую машину, я предлагаю вам обновить все ссылки, добавленные в этот проект.

Я столкнулся, и нашел решение для этого исключения сегодня. Это происходило, когда я пытался отладить модульный тест (NUnit), который вызывал виртуальный метод в абстрактном классе.

проблема, как представляется, с установкой .NET 4.5.1.

Я загрузил .NET 4.5.2 и установил (мои проекты по-прежнему ссылаются на .NET 4.5.1), и проблема решена.

источник решение:

https://connect.microsoft.com/VisualStudio/feedback/details/819552/visual-studio-debugger-throws-accessviolationexception

вы пробовали выключить DEP (Предотвращение Выполнения Данных) для вашего приложения ?

Это может быть оборудование. Это может быть что-то сложное...но я бы сделал попытку предположить, что где-то ваш потоковый код не защищает некоторую коллекцию (например, словарь) с соответствующей блокировкой.

какую ОС и пакет обновления вы используете?

Я столкнулся с той же проблемой. Мой код был .NET dll (расширение AutoCAD), работающий внутри AutoCAD 2012. Я также использую Oracle.DataAccess и мой код бросали одно и то же исключение во время ExecuteNonQuery(). Я, к счастью, решил эту проблему, изменив .net-версию ODP, которую я использовал (то есть 2.x Оракула.Доступа к данным)

хорошо, это может быть довольно бесполезно и просто анекдотически, но...

это исключение было последовательно вызвано некоторыми библиотеками Twain32, которые мы использовали в моем проекте, но это произойдет только на моей машине.

Я пробовал много предложенных решений по всему интернету, но безрезультатно... Пока я не отключил свой мобильный телефон (он был подключен через USB).

и это сработало.

оказывается, библиотеки Twain32 пытались перечислить мой телефон как Twain совместимое устройство, и что-то, что он сделал в этом процессе, вызвало это исключение.

идите на фиг...

этот вопрос почти всегда проста. Код плохой. Это редко инструменты, просто из статистического анализа. Неисчислимые миллионы людей используют Visual Studio каждый день, и, возможно, некоторые из них используют ваш код - какой бит кода получает лучшее тестирование? Я гарантирую, что, если бы это была проблема с VS, мы, вероятно, уже нашли бы ее.

Это утверждение означает, что, когда вы пытаетесь получить доступ к памяти, которая не ваша, это обычно потому, что вы делая это с поврежденным указателем, который пришел откуда-то еще. Вот почему он указывает на это.

при повреждении памяти перехват ошибки редко находится рядом с основной причиной ошибки. И эффекты именно то, что вы описываете, кажутся случайными. Вы просто должны смотреть на обычных виновников, такие вещи, как:

• неинициализированные указатели или другие значения.
• запись в буфер больше, чем его размер.
• общие ресурсы потоками, которые не защищены мьютексами.

работа в обратном направлении от такой проблемы, чтобы найти первопричину невероятно трудно, учитывая, что так много могло произойти между созданием проблемы и обнаружением проблемы.

Я в основном считаю, что легче посмотреть на то, что и поврежден (скажем, конкретный указатель), а затем выполните ручной статический анализ кода, чтобы увидеть, что могло его повредить, проверка на обычных виновников, как показано выше. Однако даже это не будет ловить длинные цепочки проблем.

Я недостаточно знаком с VS, чтобы знать, но вы также можете изучить возможность использования инструмента отслеживания памяти (например, valgrind для Linux), чтобы увидеть, может ли он обнаружить какие-либо очевидные проблемы.

проверяемый код не должен быть в состоянии повредить память, поэтому происходит что-то небезопасное. Вы используете какой-либо небезопасный код в любом месте, например, при обработке буфера? Кроме того, материал о PInvoke может быть неуместным, поскольку PInvoke включает переход к неуправляемому коду и связанному маршалингу.

моя лучшая рекомендация-прикрепить к разбитому экземпляру и использовать WinDBG и SOS копать глубже в то, что происходит во время аварии. Это не для слабонервный, но в этот момент вам, возможно, потребуется вырваться из более мощных инструментов, чтобы определить, что именно идет не так.

в моем случае файл был открыт, и поэтому заблокирована.

Я получал его при попытке загрузить файл Excel с помощью LinqToExcel, который также был открыт в Excel.

это все, что мне нужно

    var maps = from f in book.Worksheet<NavMapping>()
                select f;
    try {
        foreach (var m in maps)
            if (!string.IsNullOrEmpty(m.SSS_ID) && _mappings.ContainsKey(m.SSS_ID))
                _mappings.Add(m.SSS_ID, m.CDS_ID);
    } catch (AccessViolationException ex) {
        _logger.Error("mapping file error. most likely this file is locked or open. " + ex);
    }

У меня тоже эта проблема . я запускал разные решения одновременно с помощью visual studio , когда закрывал другие решения и запускал только целевое решение, он отлично работал без этой ошибки .

Я получил ту же ошибку в проекте, с которым я работал VB.NET. проверка "Enable Application framework" на странице свойств решила это для меня.

мой ответ очень сильно зависит от вашего сценария, но у нас была проблема, пытаясь обновить приложение .NET для клиента, который был > 10 лет, чтобы они могли заставить его работать на Windows 8.1. ответ @alhazen был своего рода в правильном поле для меня. Приложение полагалось на стороннюю DLL, которую клиент не хотел платить за обновление (Pegasus/Accusoft ImagXpress). Мы переориентировали приложение на .NET 4.5, но каждый раз, когда выполнялась следующая строка, мы получали AccessViolationException was unhandled сообщение:

UnlockPICImagXpress.PS_Unlock (1908228217,373714400,1341834561,28447);

чтобы исправить это, нам пришлось добавить в проект следующее событие после сборки:

call "$(DevEnvDir)..\tools\vsvars32.bat"
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\editbin.exe" /NXCOMPAT:NO "$(TargetPath)"

это явно указывает исполняемый файл как несовместимый с предотвращением выполнения данных. Для получения более подробной информации см. здесь.