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
}
}
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:Basically it means that code that attempts to catch AV would not work:
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.