как анализировать информацию о стеке вызовов приложения C#, где моя база данных говорит об исключении доступа, попытка чтения или записи памяти повреждена

Question

My C# WPF-приложение работает на регулярной основе, и время от времени я продолжаю эту попытку попытки читать или писать защищенная память, это часто указывает на повреждение другой памяти. C#

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

Я отправляю стек вызовов, и я вижу, что в строке 17 есть некоторые факты о том, как возникла проблема. не

Ссылка на мой диск, где я поделился весь DumpFile пожалуйста, проверьте нить нет 17 [https://drive.google.com/open?id=0BzWisplLq-PqMlhzaVdFNTJiZjg]

, пожалуйста, помогите мне найти проблему? Я новичок в этом.

using (var context = Context.Create("C:\\XSR_BIB_V2\\XSR_BIB_V2_DATABASE.sdf", "", 4091)) 
{ 
    if (DbUpdateLoop.context.Database.Connection.State == System.Data.ConnectionState.Closed) 
               DbUpdateLoop.context.Database.Connection.Open(); 

      try 
       { 
      var data = DbUpdateLoop.context.EnergyPeakInfo_Tbl.Where(x => (my_startTime >= x.StartTime) && (my_stopTime <= x.StopTime)).FirstOrDefault(); 
       } 
      catch (AccessViolationException aV) 
      { 
      //exception is not caught here 
      } 
      } 

Answer 1

AccessViolationException почти всегда указывает на неуправляемый код пытается читать или писать неотображённые памяти в процессе. Единственный способ, которым управляемый код мог бы выкинуть это исключение, - это целенаправленный вызов throw new AccessViolationException(), который никогда не должен выполняться. В вашем конкретном случае исключение инициируется некоторой библиотекой БД, видимо, в неуправляемом контексте. Когда это произойдет, вы не сможете поймать исключение. Вот раздел из MSDN, что объясняет это:

AccessViolationException и попытаться/поймать блоки

Начиная с .NET Framework 4, AccessViolationException исключений брошенных общим выполнением языка не обрабатывается catch в обработчике структурированных исключений , если исключение происходит за пределами памяти , зарезервированной для среды общего языка. Чтобы обработать такое исключение AccessViolationException, вы должны применить атрибут к способу , в котором выбрано исключение. Это изменение не влияет на AccessViolationException Исключения, сделанные кодом пользователя, которые могут по-прежнему улавливаться выпиской. Для кода, написанного для предыдущих версий .NET Framework, которые вы хотите перекомпилировать, и выполняется без изменений на платформе .NET Framework 4, вы можете добавить элемент <legacyCorruptedStateExceptionsPolicy> в конфигурационный файл вашего приложения . Обратите внимание, что вы также можете получать уведомление об исключениях , если вы определили обработчик для события AppDomain.FirstChanceException или AppDomain.UnhandledException.

В основном это означает, что код, который пытается поймать AV не будет работать:

try 
{ 
    ... code that throws AV exception 
} 
catch (AccessViolationException ex) 
{ 
    ... this will never be executed, exception will propagate to top level process handler 
} 

Я не рекомендую ловить AV исключение или применения HandleProcessCorruptedStateExceptionsAttribute к сборке, если вы не знаете, как восстановить из исключение, которое у вас нет в вашем случае, поскольку вы не знаете, какая именно операция вызвала это.

Теперь, чтобы ответить на ваш первоначальный вопрос: как анализировать стек вызовов для этого исключения.Поскольку исключение неуправляемо, вам необходимо включить неуправляемую отладку в VS и собрать неуправляемый стек вызовов, когда это исключение инициируется.