AccessViolationException thrown in strange situation
Asked Answered
A

2

9

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:

  1. Run it on IIS (Express and not-Express) 8.5 (no project edit needed).
  2. Set Optimize code = false; and Output/Advanced/Debug info = false;
  3. Wrapp the method inside to try/catch block (tried also log the exception using log4net in catch block - empty log)
  4. Replace inner of the method with some different code.

Things to note:

  • The exception had to be catched using win debugger on the server (no regular .NET exception handler was called)
  • Application crashes after the exception.
  • This code block was functioning several months ago (no release for a long time). The error started probably with some update.
  • Tested on two different servers with IIS 7.5 and one machine having IIS 8.5 and IIS Express (VS2012). Same results.
  • I have tried a lot of different combinations of projects settings. Basicaly if I don't set the settings like in point 2., it throws the exception on IIS 7.5.
  • My working (and build) machine is running Windows 8.1 with latest updates.
  • The code block is situated in separate project (class library).

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.

Agustin answered 3/12, 2014 at 21:7 Comment(7)
I wonder if the crash occurs when the method is inlined.. try marking it [MethodImpl(MethodImplOptions.NoInlining)]?Ingalls
just out of curiosity can you show the signature / structure of your Enum..?Pheidippides
I think we're going to need to see the context in which the function is called!Reprisal
Why am I inclined to say that the mere nature of this method is pointless. I don't mean that in a demeaning way, but you create a local scope variable set to zero, you do a switch that will inline to always set the local variable to zero, and then return a value that starts as zero, gets set as zero, and will return as zero. I'm not too sure how the compiler will inline that function, but am Inclined to say it will optimize it to "return 0;" and ignore the rest of your code. Is this the actual function and you actually use it? I just don't understand the point of it since it does nothing.Sharkskin
@TylerHarden I was assigned to an old project with a lot of bad code. This is one example. I don't know why this method was created. It was just there. And despite the fact I did not touch it, it started throwing this error. But maybe you have a point with the optimalization. Maybe the optimalization of code has some bug in itself.Agustin
I'm sorry Martin I hadn't noticed the date on your question. I was just looking for unanswered c# and ASP.NET questions to try and offer help and the title caught my eye. Did you ever find a solution?Sharkskin
@TylerHarden No problem, thanks anyway :-) No, I did not find a solution for this.. But given the number of upvotes it looks like I'm probably not the only one. So maybe this is some compiler optimalization bug..Agustin
L
4

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!

Lazy answered 10/6, 2015 at 23:1 Comment(0)
C
1

I am not sure whether that is still relevant to you but I managed to generate this AccessViolation error by simply changing a very small and insignificant bool in a completely managed code section. The best part however, if I disable code optimization in the compiler for that sub-project, everything runs fine. It seems to be an error introduced by the compiler in a very specific kind of situation that does not need to make any logical sense.

Clerissa answered 31/5, 2017 at 11:49 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.