Fix STATUS_PIPE_DISCONNECTED (0XC00000B0) on Windows

Quick answer: Restart the service that owns the named pipe (e.g., SQL Server, a custom app). If that doesn't work, close any locked pipe handles using handle.exe or reboot.

I've seen this error pop up mostly with SQL Server and custom .NET apps that use named pipes for inter-process communication. The 0xC00000B0 code means the client tried to read or write to a pipe that's already been closed by the server. This happens when the server crashes, is restarted, or the pipe handle is cleaned up while a client still holds a reference. It's common in high-load scenarios where connections come and go fast. I had a client last month whose entire inventory system locked up because of this — their database connection pool was full of stale pipes.

Why This Happens

Named pipes are like virtual phone lines between processes. The server creates the pipe, waits for a client to connect, and then they talk. When the server disconnects (intentionally or not), any client still holding the pipe gets this error. Common triggers:

• Server application crashed or shut down while clients were connected
• Connection pooling holding onto old pipe handles
• Firewall or security software closing the pipe
• Network timeout on a remote named pipe

Fix Steps

1. Identify the owning service or process. Look in Event Viewer under Windows Logs > Application. The source will usually name the process. For SQL Server, it's sqlservr.exe. For custom apps, check Task Manager.
2. Restart the service. Open Services.msc, find the service, right-click and Restart. For SQL Server, run:
   net stop MSSQLSERVER && net start MSSQLSERVER
   (adjust for your instance name)
3. Clear stale pipe handles. If restarting doesn't work, use Sysinternals Handle to find and close orphaned handles. Run from an admin prompt:
   

   handle.exe -a -p <processname> | findstr "pipe"
   handle.exe -c <handle_number> -p <PID>

   Be careful — closing the wrong handle can crash the process.
4. Kill and restart the client app. Sometimes the client process is holding a broken pipe. End it in Task Manager and relaunch.
5. Reboot the machine. If you're in a hurry and can't trace the exact pipe, a reboot clears all named pipes. Not elegant, but it works.

Alternative Fixes

If the main steps don't cut it:

• Switch to TCP/IP — if you're using named pipes for SQL Server, change the connection string to use TCP instead. It avoids pipe issues entirely. In SQL Server Configuration Manager, enable TCP/IP and set the port.
• Check third-party security software — I've seen McAfee and Symantec block named pipes for unknown processes. Add exceptions for the app's executable.
• Increase pipe timeout — in the client code or config, set a longer wait time (e.g., Connection Timeout=30 in SQL). This doesn't fix the root cause but gives you time to see the error clearly.

Prevention Tips

• Set up proper connection retry logic in your app. If a pipe disconnects, the client should reconnect rather than crash.
• Monitor the pipe server's health. Use Performance Monitor to track Named Pipes\Bytes Read/Written and Instances.
• Keep your server app updated — many bugs around named pipe handling were fixed in recent Windows updates (especially KB5022842 for Windows Server 2019).
• If you're a developer, always check the return code of WaitNamedPipe and handle ERROR_PIPE_NOT_CONNECTED (231) gracefully.

Real talk: I've fixed this more times by rebooting than by any clever pipe tracing. It's a dirty fix, but when a client's checkout system is down, you don't have time to debug. Just reboot, then tighten up the prevention after.