Blog

Now that doesn't look right

Now that doesn't look right

Oct 04 2015

I've been upgrading and reconfiguring my main development workstation this past week and I stumbled into a situation that has had me pretty confused for the last couple of days. The issue was around connecting applications (in particular IIS) to my local instance of SQL Server. I had several previously working websties that all of a sudden started answering with two cryptic stack straces (the first on waking the site, the second on further requests once the site was loaded in IIS):

Server Error in '/' Application.


Arithmetic operation resulted in an overflow.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.OverflowException: Arithmetic operation resulted in an overflow.

Source Error: 

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.


Stack Trace: 
 



   SNIOpenSyncExWrapper(SNI_CLIENT_CONSUMER_INFO* , SNI_ConnWrapper** ) +0
   SNINativeMethodWrapper.SNIOpenSyncEx(ConsumerInfo consumerInfo, String constring, IntPtr& pConn, Byte[] spnBuffer, Byte[] instanceName, Boolean fOverrideCache, Boolean fSync, Int32 timeout, Boolean fParallel) +275
   System.Data.SqlClient.SNIHandle..ctor(ConsumerInfo myInfo, String serverName, Byte[] spnBuffer, Boolean ignoreSniOpenTimeout, Int32 timeout, Byte[]& instanceName, Boolean flushCache, Boolean fSync, Boolean fParallel) +273
   System.Data.SqlClient.TdsParserStateObject.CreatePhysicalSNIHandle(String serverName, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Byte[]& instanceName, Byte[] spnBuffer, Boolean flushCache, Boolean async, Boolean fParallel) +311
   System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean withFailover, SqlAuthenticationMethod authType) +372
   System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover) +247
   System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout) +384
   System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance) +518
   System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, String accessToken) +767
   System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) +1117
   System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) +70
   System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) +973
   System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) +114
   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) +1631
   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) +117
   System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) +267
   System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) +318
   System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) +132
   System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) +345
   System.Data.SqlClient.SqlConnection.Open() +122
   PetaPoco.Database.OpenSharedConnection() +318
   DotNetNuke.Data.PetaPoco.PetaPocoExt.ExecuteReader(Database database, String sql, Object[] args) +253
   DotNetNuke.Data.SqlDataProvider.CanConnect(String connectionString, String owner, String qualifier) +101
   DotNetNuke.Data.DataProvider.GetProviderPath() +102
   DotNetNuke.Common.Globals.get_Status() +125
   DotNetNuke.Entities.Urls.RewriterUtils.OmitFromRewriteProcessing(String localPath) +58
   DotNetNuke.Common.Initialize.ProcessHttpModule(HttpRequest request, Boolean allowUnknownExtensions, Boolean checkOmitFromRewriteProcessing) +455
   DotNetNuke.HttpModules.RequestFilter.RequestFilterModule.FilterRequest(Object sender, EventArgs e) +246
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +142
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +92

 


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.6.106.0

And on further requests...

Server Error in '/' Application.


Arithmetic operation resulted in an overflow.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.OverflowException: Arithmetic operation resulted in an overflow.

Source Error: 

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.


Stack Trace: 
 



   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) +356
   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) +117
   System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) +267
   System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) +318
   System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) +132
   System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) +345
   System.Data.SqlClient.SqlConnection.Open() +122
   PetaPoco.Database.OpenSharedConnection() +318
   DotNetNuke.Data.PetaPoco.PetaPocoExt.ExecuteReader(Database database, String sql, Object[] args) +253
   DotNetNuke.Data.SqlDataProvider.CanConnect(String connectionString, String owner, String qualifier) +101
   DotNetNuke.Data.DataProvider.GetProviderPath() +102
   DotNetNuke.Common.Globals.get_Status() +125
   DotNetNuke.Entities.Urls.RewriterUtils.OmitFromRewriteProcessing(String localPath) +58
   DotNetNuke.Common.Initialize.ProcessHttpModule(HttpRequest request, Boolean allowUnknownExtensions, Boolean checkOmitFromRewriteProcessing) +455
   DotNetNuke.HttpModules.RequestFilter.RequestFilterModule.FilterRequest(Object sender, EventArgs e) +246
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +142
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +92

 


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.6.106.0

I had very little luck finding anything helpful on these errors so I am posting this in the hopes that it might benefit someone else.

Now to provide some background, I probably had this problem coming. I was cramming too many changes into too short of a time without fully regression testing all the environemental changes. But as I am not unlike most developers, I am pretty confident in my ability to debug and I figued if anything got hooped, I could find and fix it. That's generally true, but it usually means winding up writing blogs like this one. So I digress...

I recently upgraded to Windows 10. I also had finished cleaning up a bunch of remnants on my machine from prior dev environments. Specifically, I had cleaned off every prior version of SQL (2005,2008R2,2012 and any Office 2010 and Sharepoint 2010 SQL remnants) several Visual Studio SKU's, etc. and cleanly installed and configured SQL 2014 and VS 2013. Everything was flawless and all my websites were working properly, etc. Life was good. Then, I provided a working backup to some collegues, only to be reminded that the rest of the world is not necessarily using SQL 2014 yet. Fine. So I installed a separate instance of SQL 2012, and again all things seemed to be working correctly but ulitmately decided to downshift yet again and go back to SQL 2012 as my main DB plaform.

So once I cleaned everything up again and reinstalled just SQL 2012... then, seemingly all of a sudden, I start having the aforementioned IIS problem. What a head scratcher. I'd been through the cleanup process and wound up with a perfect 2014 installation... but now, having gone through the same process and sitting on (what I thought was) a perfectly clean 2012 installation, and it didn't work?

There wasn't much to go on in the error message I was receiving from IIS. And both SQL Enterprise Manager and Visual Studio 2013 were working just fine. I had no interuptions working with my development teams. I just couldn't get IIS to server the local websites I had been working on.

Clearly this was somehow related to the SQL connection to IIS. But how? Searching Google nor Bing provided much help. And I wasn't sure if the problem lay in SQL, IIS, .Net, Windows 10 or what? I went through lots of "repair" scenarios for all those components, thinking that perhaps in my earlier cleanups I had removed something important. I reinstalled the windows components for IIS; I did multiple repairs with sfc (system file checker); I removed and recreated all my site users (app pool identities) and permissions, I did the same with SQL logins, all to no avail. 

Now some of you are probably thinking, "duh, check the default SQL connection protocols". Well that would be a good call, and in fact I had done that... more than once. And I also started going through every conceivable connection string option I could find (though mind you, everything had previously worked "as is" on the clean 2014 install).

So my original (working) connection string looked like this:

<add name="SiteSqlServer" 
    connectionString="Server=myServer; Database=myDatabase; Integrated Security=true" 
    providerName="System.Data.SqlClient"/>

And this was generating the error above. So I decided to try working with different providers to see if I could get some different results. I switched the providerName to the SQL Server Native Client 11.0 OLE DB Provider (SQLNCLI11) and low and behold I started getting a different result. I can't seem to reproduce it, but I knew I was now on the right track.

Then I stumbled on this SQL 2008 article about connections strings which told me something that I had not previously realized you could do:

"At the time of connection, the SQL Server Native Client component reads the server, protocol, and port values from the registry for the specified alias name, and creates a connection string in the format tcp:<servername>[\<instancename>],<port> or tcp:<IPAddress>[\<instancename>],<port>."

Interesting, so you can force the protocol in the Data Source attribute? And I gave that a shot:

<add name="SiteSqlServer" 
    connectionString="Server=TCP:myServer; Database=myDatabase; Integrated Security=true" 
    providerName="SQLNCLI11"/>

And wouldn't you know it, that worked? Now I am really confused (because I don't want to use the Native Client). But now I KNOW I am on the right track. Why isn't it connecting with TCP without forcing this?

Ultimately, the answer was very simple and everything looks and seems to work correctly now. But I am 99% certain that something in the UI was not synching with something that was in the registry. Several earlier examinations of the Sql Server Configuration Manager showed the protocol setup to be as I expected (see below). But the only way I can now reproduce this error is to turn -ON- the Shared Memory protocol.

So if you run into the error message above in IIS, the most effective debugging step you can do is to add the "tcp:" protocol specification to your "Data Source" attribute, forcing use of the protocol you're expecting to use. If that fixes your problem, then head for Sql Server Configuration Manager and CHANGE and SAVE all the Enabled status of the available protocols. Once you have done that, REMOVE the "tcp:" protocol spec from your connection string and see if it behaves properly.

Because everything LOOKED right, this was very hard to track down. But after changing and then resetting all the properties (once again making everything LOOK right), things did, in fact WORK right.

Good luck!

 

Scott is a Software Delivery Program Director for a boutique consulting firm and owner of 11•2 Labs. Ever the entrepreneur, Scott is also co-founder of the DNN open source project and DNN Corp. A published author (DNN for Dummies, Professional DNN 7), Microsoft MVP and avid sea kayaker, Scott is a regular contributor to the Alki Homes blog and responsible for all of dnnHomes technical programs and social marketing.