how to analyse call stack info of c# app where my database say access exception, attempt to read or write memory is corrupt

Question

My C# WPF app runs on regular basis and every now and then i keep getting this error attempt to read or write protected memory, this is often indication that other memory is corrupted c#

this is my code. Initially I thought some external app is interfering with my database so i added a code for checking if DB is closed or open. but error seem to somthing else this is driving me crazy.

I am posting the call stack and i see thread 17 has some facts on how the issue was caused.

Link for my drive where i have shared the entire dumpfile please check out thread no 17 [ https://drive.google.com/open?id=0BzWisplLq-PqMlhzaVdFNTJiZjg ]

please help me finding the issue ? i am new to this.

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 almost always indicates an unmanaged code was trying to read or write unmapped memory in the process. The only way managed code would throw this exception is by deliberately calling throw new AccessViolationException(), which managed code should never do. In your specific case, the exception is triggered by some DB library, apparently in unmanaged context. When this happens, you won't be able to catch the exception. Here is a section from MSDN that explains this:

AccessViolationException and try/catch blocks

Starting with the .NET Framework 4, AccessViolationException exceptions thrown by the common language runtime are not handled by the catch statement in a structured exception handler if the exception occurs outside of the memory reserved by the common language runtime. To handle such an AccessViolationException exception, you should apply the HandleProcessCorruptedStateExceptionsAttribute attribute to the method in which the exception is thrown. This change does not affect AccessViolationException exceptions thrown by user code, which can continue to be caught by a catch statement. For code written for previous versions of the .NET Framework that you want to recompile and run without modification on the .NET Framework 4, you can add the <legacyCorruptedStateExceptionsPolicy> element to your app's configuration file. Note that you can also receive notification of the exceptions if you have defined a handler for the AppDomain.FirstChanceException or AppDomain.UnhandledException event.

Basically it means that code that attempts to catch AV would not work:

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

I don't recommend catching AV exception or applying HandleProcessCorruptedStateExceptionsAttribute to your assembly, unless you know how to recover from the exception, which you don't in your case, since you don't know what exact operation triggered this.

Now, to answer your original question: how to analyse the call stack for this exception. Since exception is unmanaged, you need to enable unmanaged debugging in VS, and collect unmanaged call stack when this exception is triggered.