SQL Server Error 233: No Process Is on the Other End of the Pipe

What the message actually says

The full text in SSMS looks like this:

A connection was successfully established with the server, but then an error
occurred during the login process. (provider: Shared Memory Provider,
error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)

The first sentence is the important one. The client found the server and opened a channel to it. The server side then closed that channel before the login finished. This is different from error 40, 53 or 26, where the client never reaches an instance at all. With error 233, the name resolution, the port and the firewall are usually fine, and the problem sits in the login handshake or in the state of the instance itself.

The text in brackets after provider: tells you which protocol was used. Shared Memory Provider means a local connection, Named Pipes Provider and TCP Provider mean what they say. Write that name down, because it decides where you look first.

Diagnose in this order

The order below goes from cheap and likely to expensive. Do not change several settings at once, otherwise you will not know which one mattered.

1. Read the SQL Server error log first

The client message is generic. The server usually records the real reason at the same minute. Look at the current ERRORLOG on the server, or from any working connection:

EXEC sys.sp_readerrorlog 0, 1, N'Login';
EXEC sys.sp_readerrorlog 0, 1, N'Error';

If the instance does not accept any connection, open the file directly. The default location is MSSQL\Log\ERRORLOG below the instance folder. Also check the Windows Application log for the same time window. Entries about startup, recovery, TLS or the SQL Server service account explain a large share of 233 cases.

2. Is the instance really ready?

A service in state "Running" is not necessarily ready for logins. During startup, database recovery or after a crash, connections can be dropped. In the ERRORLOG look for the line SQL Server is now ready for client connections. If it is missing, or recent, the cause is the startup, not SSMS.

A second variant is an instance that is up but starved, for example because of worker thread exhaustion or memory pressure. The Dedicated Admin Connection (DAC) bypasses the normal scheduler and is the way in when normal logins fail:

sqlcmd -S admin:ServerName -E

On a remote server the DAC must be enabled first (remote admin connections option). If the DAC works while normal logins fail, you are looking at resource starvation, and the next step is to find what holds the workers.

3. Force one protocol and compare

SSMS lets you pin the protocol with a prefix in the server name field. Run the same login three times:

lpc:ServerName          -- Shared Memory, local only
np:\\ServerName\pipe\sql\query   -- Named Pipes (default instance)
tcp:ServerName,1433     -- TCP/IP with explicit port

For a named instance use the matching pipe name and the instance port. The result is a clear fork:

TCP works, Named Pipes or Shared Memory fails: the client tries the other protocol first and that path is broken. Either fix the protocol order on the client (SQL Server Configuration Manager, SQL Native Client Configuration) or connect with the tcp: prefix as a workaround.
All three fail: the protocol is not the issue. Go back to the ERRORLOG and to step 2.
Only the remote attempt fails: compare the server protocol settings, the firewall and the TLS settings below.

4. Check the server protocols

In SQL Server Configuration Manager, under SQL Server Network Configuration, check which protocols are enabled for the instance. After any change, restart the SQL Server service, because the protocol list is read at startup. For named instances the SQL Server Browser service must run, unless you connect with an explicit port. This is the classic fix that forum answers mention, and it does help when the client and server cannot agree on a common protocol. It is not the cause every time, so treat it as one step in the ladder.

5. TLS and encryption

Current SSMS versions encrypt connections by default and validate the server certificate. A failed TLS handshake can surface as a login-phase error. Typical triggers are an old client against a server that only allows TLS 1.2 or higher, a certificate the client does not trust, and a certificate whose private key the SQL Server service account cannot read. As a quick test, tick Trust server certificate under Options, Connection Properties. If that makes the error go away, fix the certificate chain properly instead of leaving the checkbox on.

6. Logon triggers and login-related objects

A server-level logon trigger that raises an error or rolls back the logon ends the session before it starts. Check for them:

SELECT name, is_disabled, create_date
FROM sys.server_triggers;

If one is a suspect, disable it from the DAC or from a working sysadmin session, then retest. Be precise about the symptom: a disabled login or a wrong password normally returns error 18456 or 18470 with a state number, not error 233. If you see those, you are on a different problem.

7. Network path for remote connections

Because the connection was established, a plain "port closed" is unlikely. Still, inspection devices between client and server can open the TCP connection and then drop the traffic. A firewall or proxy that does deep packet inspection on port 1433 is a known source of this behavior. Test from a second client in the same network segment as the server. If that client works, the difference is in the path, not in SQL Server.

A quick decision table

Observation	Likely direction
ERRORLOG shows no "ready for client connections"	Startup or recovery still running, or failing
DAC works, normal login fails	Worker or memory starvation
`tcp:` works, `np:` or `lpc:` fails	Client protocol order or pipe configuration
Works with Trust server certificate	Certificate chain or TLS version
Fails only through the network, works locally	Firewall, proxy or inspection device
Fails for every login, starts exactly at one time	Logon trigger, patch or configuration change at that time

What I would not do

Do not reinstall SSMS as the first step. The same login from sqlcmd shows within a minute whether the client tool matters.
Do not change the authentication mode or enable sa as a guess. Both need a service restart and neither produces error 233 by itself.
Do not conclude from one working connection that the problem is gone. Intermittent 233 errors that appear under load point to starvation, not to a configuration setting.

What to collect before asking for help

If you post the problem in a forum or open a ticket, these facts shorten the answer from days to minutes:

The provider name from the error text and the exact error number
SQL Server version and build, SSMS version, Windows version
Local or remote, default or named instance
The result of the three forced-protocol attempts
The ERRORLOG lines from the minute of the failed login

← Back to Blog