System.ExecutionEngineException thrown at DbConnectionStringBuilder.GetProperties() while debugging x64/Native Debugging enabled - by 2coder

Status : 

 


6
0
Sign in
to vote
ID 787041 Comments
Status Active Workarounds
Type Bug Repros 6
Opened 5/16/2013 3:13:41 AM
Access Restriction Public

Description


A System.ExecutionEngineException is thrown when trying to debug a .NET 4.5 x64 program under Visual Studio 2012 Professional with native debugging enabled.

The code is thrown during the execution of System.Data.Common.DbConnectionStringBuilder.GetProperties(), that is called by a class inheriting from DbConnectionStringBuilder.

Sourcecode to the small example application is stored at http://db.tt/AwNnxGh5 and also attached to this report.

Callstack from inside Visual Studio 2012 during debugging

 	System.Data.dll!Bid.Bid() + 0x49 bytes	
 	[Native to Managed Transition]	
 	System.Data.dll!System.Data.Common.DbConnectionStringBuilder.GetProperties(System.Collections.Hashtable propertyDescriptors) + 0x7c bytes	
>	FEEE.exe!FEEE.TestDbStringBuilder.TestDbStringBuilder() Line 14	C#
 	FEEE.exe!FEEE.Program.Main(string[] args) Line 21 + 0x25 bytes	C#
 	mscoreei.dll!_CorExeMain()  + 0x5d bytes	
 	mscoree.dll!_CorExeMain_Exported()  + 0x69 bytes	
 	kernel32.dll!BaseThreadInitThunk()  + 0x1a bytes	
 	ntdll.dll!RtlUserThreadStart()  + 0x21 bytes	
Sign in to post a comment.
Posted by Andrew [MSFT] on 9/25/2013 at 10:57 AM
Thank you for taking the time to report this issue. This is a bug that only occurs with managed C++ (System.Data.dll is written in managed C++). In Visual Studio 2012 we began the process of re-architecting the debugger, and in Visual Studio 2013 managed C++ is the last remaining language that still relies on the old debug engine. As such we will not be able to fix this particular issue in either 2012 or in 2013 since there is a workaround of disabling the System.Data.pdb from loading, and we will be replacing the problematic debug engine in the next version of Visual Studio which will fix this issue.

Best Regards,
Visual Studio Debugger
Posted by Truls on 6/26/2013 at 7:42 AM
We also see this. If you exclude System.Data.ni.dll from symbol loading the problem disappears.
Posted by Ståle L. Hansen on 6/26/2013 at 6:30 AM
It also seems to be related to the symbols for System.Data.ni.dll, which needs to be loaded for this crash to happen.
Posted by Alexander Steffens on 5/23/2013 at 2:04 AM
I also hit into this issue and reduced it on my Windows 7 x64 to the following lines of code:

using System.Data;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            var ds = new DataSet("Test");
        }
    }
}

The issue is active on explicit x64 build with native code debugging enabled.

Callstack:
    System.Data.dll!Bid.Bid() + 0x49 bytes    
    [Native to Managed Transition]    
    System.Data.dll!System.Data.DataSet.DataSet() + 0xd1 bytes    
    System.Data.dll!System.Data.DataSet.DataSet(string dataSetName) + 0x14 bytes    
>    ConsoleApplication1.exe!ConsoleApplication1.Program.Main(string[] args) Line 9 + 0x35 bytes    C#
    mscoreei.dll!_CorExeMain() + 0x5d bytes    
    mscoree.dll!_CorExeMain_Exported() + 0x69 bytes    
    kernel32.dll!BaseThreadInitThunk() + 0xd bytes    
    ntdll.dll!RtlUserThreadStart() + 0x21 bytes    
Posted by Microsoft on 5/16/2013 at 11:27 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 5/16/2013 at 3:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)