I'm in c# for quite a long time, but I never got this kind of error. First of all, do you see anything wrong(possibly wrong) about this single code block (except it's logic of course, I know it always return 0)?
public static int GetDecimals(MySimpleEnum val)
{
int result = 0;
switch (val)
{
case MySimpleEnum.Base:
case MySimpleEnum.Slow:
case MySimpleEnum.Normal:
case MySimpleEnum.Quick:
case MySimpleEnum.Fastest:
result = 0;
break;
}
return result;
}
Release project settings: DEBUG constant = false; TRACE constant = true; Optimize Code = true; Output/Advanced/Debug info = none;
IIS = version 7.5
This method, having specified release settings throws "System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
And here is the funny part. These are cases, when it does not throw this exception:
Things to note:
I know how to fix this. But I don't like closing issues, while not knowing the cause. Also, I want to avoid this in future. Do you think you could help me with that? If it is some null reference exception, why is this happening? And why it is debug/release specific or IIS version specific?
*Note2:
Recently I had problem with missing dll's (System.Net.Http.Formatting.dll, System.Web.Http.dll, System.Web.Http.WebHost.dll) while publishing. It was because of some Microsoft security update. Maybe this is something similiar.*
Edit 1 Adding structure of the enum declaration.
public enum MySimpleEnum
{
Base = 0,
Slow = 1,
Normal = 2,
Quick = 3,
Fastest = 4
}
Also, I just tried adding [MethodImpl(MethodImplOptions.NoInlining)], but no help.
It is atypical to have these types of access violation errors from managed code. They come from memory corruption which can indicate faulty hardware - in extremely rare cases this indicates a bug in the CLR itself.
The most likely cause of this type of error comes from elsewhere, e.g. if this code is using native code somehow - either calling into native code in an unsafe context or being called from native code.
To quote MSDN AccessViolationException:
In programs consisting entirely of verifiable managed code, all references are either valid or null, and access violations are impossible. An AccessViolationException occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.
In any case, you typically need to look elsewhere in the code to find the bad code that corrupts the memory. Unfortunately this is a pretty tough problem to solve. Good luck!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With