SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified [closed]

If you are connecting from Windows machine A to Windows machine B (server with SQL Server installed), and are getting this error, you need to do the following:

On machine B:

1.) turn on the Windows service called "SQL Server Browser" and start the service

2.) in the Windows firewall, enable incoming port UDP 1434 (in case SQL Server Management Studio on machine A is connecting or a program on machine A is connecting)

3.) in the Windows firewall, enable incoming port TCP 1433 (in case there is a telnet connection)

4.) in SQL Server Configuration Manager, enable TCP/IP protocol for port 1433

enter image description here


For me the issue was that the DNS record was wrong...

The following, which proved very helpful, is largely taken from this blog post.

This error message is actually pretty specific and the solution quite simple.

You get this error message only if you are trying to connect to a SQL Server named instance. For a default instance, you never see this because even if we failed at this stage (i.e. error locating server/instance specified), we will continue to try connect using default values, e.g default TCP port 1433, default pipe name for Named Pipes.

Every time a client makes a connection to SQL Server named instance, we will send a SSRP UDP packet to the server machine UDP port 1434. We need this step to know configuration information of the SQL instance, e.g., protocols enabled, TCP port, pipe name etc. Without this information the client does not know how to connect and it fails with this error message.

In a word, the reason that we get this error message is the client stack could not receive SSRP response UDP packet from SQL Browser. In order to isolate the exact issue follow these steps:

  1. Make sure your server name is correct, e.g., no typo on the name.

  2. Make sure your instance name is correct and there is actually such an instance on your target machine. (Be aware that some applications convert \ to ).

  3. Make sure the server machine is reachable, e.g, DNS can be resolve correctly, you are able to ping the server (not always true).

  4. Make sure the SQL Browser service is running on the server.

  5. If the firewall is enabled on the server, you need to put sqlbrowser.exe and/or UDP port 1434 into exception.

There is one corner case where you may still fail after you checked steps 1 to 4. It also may happen when:

  1. your server is a named instance on cluster or on a multi-homed machine
  2. your client is a Vista machine with Firewall on.

A tool which could prove useful (it did for me) is PortQry. If this command returns information and it contains your target instance, then you can rule out possiblity 4) and 5) above, meaning you do have a SQL Browser running and your firewall does not block SQL Browser UDP packet. In this case, you can check other possible issues such as an incorrect connection string.

As a final note, the error message for the same issue when you use SNAC is: [SQL Native Client]SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

Microsoft recently released a guided walk through that can serve as a one stop shop to troubleshoot a majority of connectivity issues to SQL Server: Solving Connectivity errors to SQL Server


Goto window+R and type services.msc and press enter.

Then start SQL server manually if not automatically started.

Then you try to login, it must be works.


I had been experiencing the same problem, in my ASP.NET MVC 4 application.

The way I solved it, was in the DatabaseContext. By passing down the name of the connection string I wanted to use through the base constructor.

public class DatabaseContext : DbContext
{ 
    public DatabaseContext()
        : base("DefaultConnection") // <-- this is what i added.
    {
    }

    public DbSet<SomeModel> SomeModels { get; set; }
}