ExecutionEngineException or AccessViolationException (CLR 2.0) when debugging a program that uses System.Data.OleDb

[siegfriedpammer]

the following program throws an ExecutionEngineException (CLR 4) or AccessViolationException or TypeInitializationException(CLR 2), while debugging:

using System;
using System.Data.OleDb;
using System.IO;

namespace Test
{
    class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");

            OleDbConnection connection = null;
            string path = Path.Combine( Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location),  "Datenbank1.accdb");
            try {
                connection = new OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Mode=16;Data Source=" + path + ";Persist Security Info=False");
                connection.Open(); // Exception thrown here
            } finally {
                if ( connection != null )
                    connection.Close();
            }

            Console.Write("Press any key to continue . . . ");
            Console.ReadKey(true);
        }
    }
}

Please ensure that there's an empty .accdb or mdb (with one table) in your bin folder.

Compiling the program for .NET 4.0 and C# 5 leads to the following exception when executed with the debugger:

System.ExecutionEngineException

Cannot intercept exception. Debugged program can not be continued and properties can not be evaluated.

   at System.Data.Common.ADP.IsSysTxEqualSysEsTransaction
   at System.Data.Common.ADP.NeedManualEnlistment
   at System.Data.OleDb.OleDbConnection.Open
   at Test.Program.Main in b:\Projects\Test\Test\Program.cs:line 35

Not this does not happen VS or SD 4.x.

[siegfriedpammer]

As far as I could debug the problem so far:
It disappears when disabling Suppress NGEN optimization in the options and it was introduced in

4798dae is the first bad commit
Author: David Srbecký [email protected]
Date: Tue Feb 12 13:54:52 2013 +0000

Refactored the stepping logic to be more friendly with multiple symbol source;
JIT and NGEN optimization are explicit options now

see 4798dae#diff-7434f932b82173e59e505309e2eb2424R332

Could it be that SetDesiredNGENCompilerFlags was never called for any process in SD 4.x, thus the problem never appeared? Is that call really necessary for debugging (especially without source debugging)?