Weird Access Violation Exception

Question

I'm puzzled with an occurance of AccessViolationException. It's quite impossible (see answer) to have a clean reproduction but here goes the general idea:

class MyClass 
{
  public List<SomeType> MyMethod(List<string> arg)
  {
     // BREAKPOINT here
     // Simple stuff here, nothing fancy, no external libs used
  }
}

delegate List<SomeType> MyDelegate(List<string> arg);

... 

var myObject = new MyClass();

Func<List<string>, List<SomeType>> myFunc = myObject.MyMethod;
MyDelegate myDelegate = myObject.MyMethod;

myFunc(null)            // works fine
myDelegate(null)        // works fine
myObject.MyMethod(null) // throws AccessViolationException

The weird part is I'm not using any unsafe code. I don't have any dependencies on external libraries anywhere close (and anywhere in the whole program execution AFAIK).

The weirdest part is this is 100% reproducable and even after refactoring the code slightly, moving the method invocation elsewhere, putting extra code before it etc. - in all cases AccessViolationException is still thrown on that particular method invocation. The method is never entered when invoked directly (breakpoint is not hit). Invoking it through delegate or Func<> works fine.

Any clues as to what could cause it or how to debug it?

UPDATE

Following antiduh's question: There is no call to a virtual method from a constructor anywhere close. The actual stack trace when this happens is very simple, just two static methods and a simple instance one.

The only clue seems to be threading. There is Parallel.ForEach() and Thread.Sleep() invoked before this in program execution (not in call stack). Any clues as to how mishandled threading (with regular, managed classes) could cause AVE?

UPDATE

Narrowed it down to a VS bug, see my answer.

Runstadler

What's the smallest version of the code that still demonstrates the problem? I would keep removing code until the AV stops occurring and hope that this provides some clues. – Feleciafeledy

By chance, are you calling any of this from inside the constructor of a subclass? Are you calling virtual methods that perhaps don't exist yet because the constructors haven't been completed? – Gramps

@Ryan Removing that single method invocation that throws stops AV from happening – Commonable

@Gramps Really interesting idea, I'll investigate and update – Commonable

Not properly using locking to protect objects that are not thread-safe can cause internal object corruption that can cause an AV. The List<> class is not thread-safe. – Dive

Have you tried to reorder the calls, i.e. the direct call first, then the delegate? – Electioneer

Yes, as stated I refactored the code a bit, placed the invocation elsewhere and it sill happened. I do have another lead though, which I'll explain in a while. – Commonable

Read update for actual answer... – Commonable

Answer 1

This seems to be a VS bug. Have a look at this full solution. Code is simple:

using System;
using System.Collections.Generic;

namespace Foo
{
    public class MyClass
    {
        public virtual object Foo(object o1, object o2, object o3, object o4)
        {
            return new object();
        }
    }

    public sealed class Program
    {
        public static void Main(string[] args)
        {
            var myClass = new MyClass();
            object x = new object();
            myClass.Foo(null, null, null, new object()); // put a breakpoint here and once it stops, step over (F10) - AccessViolationException should be thrown in VS
        }
    }
}

The important fact I have missed before is that the code actually works fine when ran normally. Only when that particular line is being stepped over in VS (F10), the Access Violation occurs and it actually occurs in VS hosting process (even though the final stack frame is my code). It's possible to continue execution fine.

The issue happens for me on VS 2013, version 12.0.21005.1 REL. It also happens on 3 other machines I tested this on.

UPDATE

Installing .NET Framework 4.5.2 solves this.

Runstadler

Copy/pasted your code to VS2013.2 (12.0.30501.00) and verified the bug in x64 only. It looks a lot like this question though, which has a reference to a Microsoft Connect bug report. – Triplicity

Confirmed, only happens in x64. I have filed my own bug through Connect unknowingly: connect.microsoft.com/VisualStudio/feedback/details/911564/…. – Commonable

@JacekGorgoń running into the same issue --> #28233793 any workaround? thanks – Snips