Applications crash and "AccessViolationException" exception occurs when you use System.Data.SqlClient after you install Visual Studio 2013 or .NET Framework 4.5.1

After you install Microsoft Visual Studio 2013 or the Microsoft .NET Framework 4.5.1 on your computer, applications crash if they connect to Microsoft SQL Server through a TCP port by using the Microsoft .NET Framework Data Provider for SQL Server. Additionally, the applications throw a System.AccessViolationException exception.

Note When an application encounters this problem, various call stacks are created. The following examples show typical call stack patterns in this situation.

Example 1

<Module>.SNIAddProvider(SNI_Conn*, ProviderNum, Void*)SNINativeMethodWrapper.SNIAddProvider(System.Runtime.InteropServices.SafeHandle, ProviderEnum, UInt32 ByRef)System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean, Boolean, Boolean ByRef)System.Data.SqlClient.TdsParser.Connect(System.Data.SqlClient.ServerInfo, System.Data.SqlClient.SqlInternalConnectionTds, Boolean, Int64, Boolean, Boolean, Boolean)System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(System.Data.SqlClient.ServerInfo, System.String, Boolean, System.Data.ProviderBase.TimeoutTimer, System.Data.SqlClient.SqlConnection)System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(System.Data.SqlClient.ServerInfo, System.String, Boolean, System.Data.SqlClient.SqlConnection

Example 2


Example 3


Example 4

System.Data.SqlClient.SqlInternalConnection.OnErrorSystem.Data.SqlClient.TdsParser.ThrowExceptionAndWarningSystem.Data.SqlClient.TdsParserStateObject.SNIWritePacketSystem.Data.SqlClient.TdsParserStateObject.WriteSniSystem.Data.SqlClient.TdsParserStateObject.WritePacketSystem.Data.SqlClient.TdsParser.TdsLoginSystem.Data.SqlClient.SqlInternalConnectionTds.LoginSystem.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlistSystem.Data.SqlClient.SqlInternalConnectionTds..ctorSystem.Data.SqlClient.SqlConnectionFactory.CreateConnection System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection System.Data.ProviderBase.DbConnectionFactory.TryGetConnection System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal System.Data.ProviderBase.DbConnectionClosed.TryOpenConnectionSystem.Data.SqlClient.SqlConnection.TryOpenInner System.Data.SqlClient.SqlConnection.TryOpenSystem.Data.SqlClient.SqlConnection.Open
This problem occurs because some non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) that are installed on the system intercept and change the incoming and outgoing network traffic. Therefore, when the application connects to SQL Server, these BSPs or LSPs interfere with the calls to Winsock.

To determine whether this is the cause of the problem, go to the "More Information" section.
To resolve this issue, upgrade the .NET Framework 4.5.1 to the Microsoft .NET Framework 4.5.2.
To work around this problem, try the following methods:
  • Uninstall the Non-IFS BSPs or LSPs. To do this, use one of the following methods:
    • Uninstall the application that installed the Non-IFS BSP or LSP on the system.
    • Run the following command at a command prompt:

      netsh winsock remove provider <id>

      Note In this command, <id> represents the "Catalog Entry Id" value for the non-IFS LSP that is shown when you run the following command:

      netsh winsock show catalog
  • Uninstall the .NET Framework 4.5.1.

    Note This option is not applicable if Visual Studio 2013 is installed on the system.
More information
To determine whether a non-IFS BSP or LSP is installed, use the netsh WinSock Show Catalog command. Then, verify that the following conditions are true for every Winsock Catalog Provider Entry item that is returned:
  • If the Service Flags value has the 0x20000 bit set, this indicates that the provider uses IFS handles and works correctly.
  • If the 0x20000 bit is clear (not set), this indicates that the provider is a non-IFS BSP or LSP.

To programmatically determine whether a non-IFS BSP or LSP is installed, enumerate the available protocols by using the WSCEnumProtocols function. Check the dwServiceFlag1 member in each returned WSAPROTOCOL_INFOW structure to determine whether the XP1_IFS_HANDLES flag (or 0x20000) is set. The Windows SDK documentation for the WSCEnumProtocols function includes source code for an example program that shows how you can do this.

  • The Service Flags value was introduced in the netsh command in Windows 7 and Windows Server 2008 R2. Therefore, using the netsh command to check this value does not work in Windows Vista or Windows Server 2008.
  • The WSCEnumProtocols function can be used to retrieve WSAPROTOCOL_INFOW structures and the dwServiceFlag1 member to discover whether IFS/non-IFS BSPs or LSPs are installed. The WSCEnumProtocols function is supported on Windows 2000 and later versions. For code examples of how to use the WSCEnumProtocols function, see WSCEnumProtocols function.
  • For more information about non-IFS BSPs/LSPs issues, see SetFileCompletionNotificationModes API causes an I/O completion port not to work correctly if a non-IFS LSP is installed.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

Artikelnummer: 2915689 – Letzte Überarbeitung: 05/14/2014 08:38:00 – Revision: 4.0

Microsoft .NET Framework 4.5.1

  • kbsurveynew kbtshoot kbexpertiseadvanced KB2915689