Apparently random access violation in connection pool RRS feed

  • Question

  • Hi all,

    I'm getting an apparently random access violation from deep in the bowels of the SqlClient, and I was hoping that someone here might have seen it before and know what's wrong.

    The basic setup is
    • .NET 2.0 service written in C#
    • MSDE 2000 database
    • Windows Server 2003
    The service itself chugs along nicely for a while - anywhere between hours and days - and then a database client dies. From then on all attempts to access the database fail similarly.

    The exception stack trace is as follows:

    System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.   

      at SNIOpenEx(SNI_CONSUMER_INFO* , UInt16* , SNI_Conn** , Int32 , UInt32 , Byte* , Byte*  , Int32 , Int32 )
      at SNINativeMethodWrapper.SNIOpenEx(ConsumerInfo consumerInfo, String constring, IntPtr& pConn, Boolean fInitSec, Byte[] sspiBuffer, Byte[] instanceName, Boolean fOverrideCache, Boolean fSync)
      at System.Data.SqlClient.SNIHandle..ctor(ConsumerInfo myInfo, String serverName, Boolean integratedSecurity, Byte[] serverUserName, Boolean ignoreSniOpenTimeout, Int32 timeout, Byte[]& instanceName, Boolean flushCache, Boolean fSync)
      at System.Data.SqlClient.TdsParserStateObject.CreatePhysicalSNIHandle(String serverName, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Byte[]& instanceName, Boolean integratedSecurity, Byte[] serverUserName, Boolean flushCache, Boolean async)
      at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject)
      at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
      at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
      at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
      at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
      at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
      at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
      at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
      at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)

      at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
      at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
      at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
      at System.Data.SqlClient.SqlConnection.Open()
      at Momentum.mView.Server.AccountManager.LoadAccount(String accountPath)
      at Momentum.mView.Server.AccountManager.Momentum.mView.Server.IHostAccountManager.GetAccountByPath(String accountPath)  
      at Momentum.mView.Server.mViewServer.RtspServer_Announce(Object sender, RtspRequestEventArgs e)
      at Momentum.mView.Rtsp.Server.RtspServer.DispatchAnnounce(RtspRequest request, RtspSession session)
      at Momentum.mView.Rtsp.Server.RtspServer.DispatchInboundRequest(Object stateInfo)

    The actual code that causes this exception (somewhat simplified) is this:

    Code Snippet

    void LoadAccount(string accountPath)
      using(SqlConnection conn = new SqlConnection("conn string"))


        conn.Open(); // <---<< Dying here, apparently

        using(SqlCommand cmd = new SqlCommand("StoredProc_Name"))


          cmd.Connection  = conn;

          cmd.CommandType = CommandType.StoredProcedure;

          cmd.Parameters.Add("@path", SdlDbType.NVarChar, 16).Value = accountPath;

          using(SqlDataReader reader = command.ExecuteReader(CommandBehavior.SingleRow))


            // do useful stuff here





    This particular crash only seems to happen on two of the four machines that the service is running on, but there are subtle differences in the builds between all four machines meaning that I can't entirely rule out a simple programming error. None of these subtle changes are in the areas that touch the database, though, and I can't think of any programming error on my part that would cause the SqlClient to fail so spectacularly.

    It may also be worth noting that the two machines that the connection dies on are both dual-core AMD64s (runing in 32-bit mode, btw), while the two machines it works on are single core P4s. The dual-core part makes me think that there is a nasty race condition somewhere.

    Does anyone have any thoughts or suggestions?


    Monday, June 30, 2008 2:02 AM

All replies

  • Have you tried to check how many opened connections you have from your services? Does it grow with time?


    Tuesday, July 1, 2008 2:24 AM
  • Hi there,

    I can't check with the server that's having the most problems - at least not in the same scenario that it has been failing in.

    This morning I disabled connection pooling via the connection string to see if that would help help, and the service has been behaving itself thus far. That's 5 hours or so under the same load that caused it to die three times yesterday. It's not a definitive answer, but promising - at least in terms of a diagnosis. I certainly want to get connection pooling back so I don't have to do a lot of re-architecting, though.

    With connection pooling turned off, though, the service has no open connections when it isn't handling a request.

    The other server having the issue has been running for days - although it seems less prone to crashing - and has two sleeping connections to the database. Another server - one not exhibiting the issue - has four, and has been up for weeks.

    So... as far as I can see things are pointing towards the connection pool.

    Any more suggestions?
    Tuesday, July 1, 2008 4:59 AM
  • One more suggestion is to remove "using" blocks and try to close all the connections explicitely and then call Dispose() method of them. It might help release connections properly to the pool


    Tuesday, July 1, 2008 10:41 AM