A connection was successfully established with the server, but then an error occurred
during the login process. (provider: Named Pipes Provider, error: 0 - No process is on the
other end of the pipe.) (error 233) on LocalDB with User ID=sa is a
failed login in disguise: sa is disabled on LocalDB. Connect with
Integrated Security=true instead.
LocalDB starts on demand under your own Windows account, so Windows authentication is the
intended way in. Drop User ID and
Password from the connection string and add
Integrated Security=true.
The error
PS> .\FixLab.exe 'Server=(localdb)\MSSQLLocalDB;Database=Fix4Lab;User ID=sa;Password=Fix4Lab-Test-Only!;TrustServerCertificate=true' 'SELECT DB_NAME()'
ex.Number = 233
Microsoft.Data.SqlClient.SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.)Why it happens
The client message says nothing about the login, but the LocalDB error log does. It sits under your local application data folder, and it recorded the real failure, error 18456:
2026-10-09 13:59:32.94 Logon Error: 18456, Severity: 14, State: 7.
2026-10-09 13:59:32.94 Logon Login failed for user 'sa'. Reason: An error occurred while evaluating the password. [CLIENT: <named pipe>]
A query over Windows authentication showed why: the sa login exists but is
disabled on this LocalDB instance (is_disabled is true). The instance itself is
not Windows-only; SERVERPROPERTY('IsIntegratedSecurityOnly') returned 0, so SQL
logins are allowed in principle, just not this one. LocalDB talks to clients over a named
pipe, and the client saw that pipe close during the login handshake rather than receiving
the 18456 message, so it reported error 233.
The fix
PS> .\FixLab.exe 'Server=(localdb)\MSSQLLocalDB;Database=Fix4Lab;Integrated Security=true;TrustServerCertificate=true' 'SELECT DB_NAME(), SUSER_SNAME()'
Fix4Lab | MACHINE\user
OK (-1 row(s) affected)
The Windows account name is replaced with MACHINE\user; nothing else changed.
With Windows authentication the same database opened as the signed-in user. If your app
really needs a SQL login, for example to match production, create a dedicated login and user
for it rather than enabling sa, and keep its password out of source control.
The general lesson: when a LocalDB connection fails during login with a vague pipe message,
read error.log before changing anything. The 18456 line and its reason name the
login and the cause, which the client message hides. To check a login yourself, connect with
Windows authentication and query sys.server_principals for its
is_disabled flag.
How it was reproduced
A console app from dotnet new console -n FixLab -f net10.0 (.NET SDK 10.0.401)
with Microsoft.Data.SqlClient 7.1.1, which prints ex.Number and the message on
failure, connected to SQL Server 2022 LocalDB 16.0.1200.5 on Windows 11 with
User ID=sa and a test password. The 18456 lines came from the instance's
error.log; the sa status from sys.server_principals.
Frequently asked
- Why does LocalDB say No process is on the other end of the pipe?
- In this case the login failed. With User ID=sa the server logged error 18456 because sa is disabled on LocalDB, and the client only saw the named pipe close, which it reports as error 233.
- Can I log in to LocalDB with sa?
- Not by default: the sa login exists on LocalDB but is disabled. Use Integrated Security=true, which signs you in as your Windows account, the account your LocalDB instance runs under.
- Where is the LocalDB error log?
- Under your local application data folder: Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\error.log. Failed logins appear there as error 18456 with a reason line.
More decoded errors in the Fixes category.