Skip to content
This repository was archived by the owner on Oct 16, 2020. It is now read-only.
This repository was archived by the owner on Oct 16, 2020. It is now read-only.

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

Closed

Description

@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.

Activity

  1. added this to the 5.0 RC milestone on Aug 28, 2014
  2. siegfriedpammer commented on Aug 28, 2014

    @siegfriedpammer
    MemberAuthor

    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ý dsrbecky@gmail.com
    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)?

  3. added a commit that references this issue on Jul 7, 2024
    02493cf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions