We have started seeing the following errors appearing intermittently (between 1 and 5 a day on average) in the error logs on one of our SQL 2016 servers:

Error: 26050, Severity: 17, State: 1. Server local connection provider has stopped listening on [ \.\pipe\SQLLocal\SQL16 ] due to a failure. Error: 0xe8, state: 4. The server will automatically attempt to re-establish listening.

These are followed a few seconds later by:

Server local connection provider has successfully re-established listening on [ \.\pipe\SQLLocal\SQL16 ].

(SQL16 is the instance name of this server).

We do not appear to be getting any errors from the applications that use this server at the same time and as far as I am aware "\.\pipe\SQLLocal\SQL16" is used by the Shared Memory protocol, which would indicate this was something that would only affect connections coming from the local server.

This server is part of an Availability Group and is the primary replica. The databases are also log-shipped to a third server. I have tried to look at any errors from Agent jobs etc. but cannot see anything obvious that ties in with the times we see these errors logged.

I am just curious as to what might cause these messages, as I have never seen them on any other servers.

This question has an open bounty worth +50 reputation from aasim.abdullah ending in 7 days.

Looking for an answer drawing from credible and/or official sources.

We have faced same error on one of our production server and we are looking for a reason and strategies to avoid in future. On our side Named pipes and VIA are disabled while TCPIP and Shared memory are enabled. (SQL Server 2008R2)

  • Did you notice if the errors coincide with the running of logship copy/restore jobs on the 3rd server? Just because I found this similar bug reported. feedback.azure.com/forums/908035-sql-server/suggestions/… – gareth 1 hour ago
  • Here's a similar question but it has no answers. There is a suggestion to try TCP connections as a workaround. This blog post also shows the same issue with a few suggestions. – KevH 1 hour ago
  • Do you have any way of monitoring the connections to see if it's a transport layer problem? Try leaving a ping running between the servers to see if anything odd shows up at the corresponding times ping -t server1. – KevH 1 hour ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.