Topics from the Microsoft SQL Server Protocols team - Netlibs, TDS, SQL Browser, etc.
In this post, I want to talk about a special cause of this specific error message when you try to start SQL 2005 instance.
The symptom here is: The NP and TCP protocol were disabled in your SQL 2005 default instance, and you tried to start it but failed. you went to Server ERRORLOG, and found following error message:
Server local connection provider failed to listen on [ \\.\pipe\sql\query ]. Error: 0x50Error: 17182, Severity: 16, State: 1.TDSSNIClient initialization failed with error 0x50, status code 0x50Error: 17182, Severity: 16, State: 1.TDSSNIClient initialization failed with error 0x50, status code 0x1.
0x50 stands for "The file has already exists". And the problem here is SQL 2005 was trying to listening on the default pipe name for legacy client locally connecting to the default instance under situation that server named pipe was disabled by default after fresh installation, however, the pipe name was occupied by another bogus server. In this case, I want to point out you might need to check whether there is a SQL 2K named instance on the same box, and it is running. You can verify that by running "osql.exe /Snp:. /E /Q"select @@version" " or "osql.exe /S\\.\pipe\sql\query /E /Q"select @@version" " to see whether it is the SQL 2K instance took over the pipe.
If so, you need to go to "SQL Server Network Utility", click the properties of Named Pipe, and check whether the pipe name was gone, or double check registry key "PipeName" under "\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<2kinstancename>", make sure there is correct value, then restart the 2K named instance, and restart the 2K5 default instance.
Note: You might hit another problem "0x5, ACCESS_DENIED" if you retry starting SQL 2k5 default instance after fixing the pipe name, which might due to if you shutdown the 2K instance and the handle of the pipe is still hold by kernel file system. Follow up the solution in the below blog:http://blogs.msdn.com/sql_protocols/archive/2006/03/09/546655.aspx.
Great article, saved me a lot of time
I don't understand a word of this...
I'm stuggling to bring the MSSQL with domain account with the same problem being discussed above.
I've tried with options suggested but no luck. No MSSQL 2K Instance on my server. Its only one MSSQL (2008 R2)
Is there a way to find out what is that Bogus named pipe connections/server? how to validate whether O/S kernal memory cleaned properly after server reboot.