STATUS_PIPE_BROKEN (0XC000014B) – Quick Fix Guide

1. Docker Container or WSL Instance Crashed (Most Common)

This is the number one reason you’ll see 0XC000014B. You're running a Docker container or a WSL distribution, and the process inside it dies unexpectedly. Your client (like Docker Desktop, VS Code's Remote - WSL, or a terminal) tries to read or write to the pipe connecting it to the container, but the container’s end of the pipe is already gone. The result? STATUS_PIPE_BROKEN.

Here’s the trigger: say you have a container running a Flask app. The app hits an unhandled exception (maybe a missing config file), crashes, and exits. Docker doesn’t restart it by default. Your terminal or VS Code is still attached to that pipe, so when it tries to send a command, you get 0XC000014B.

How to verify it’s Docker or WSL

Open a Command Prompt or PowerShell as Administrator.
Run the command:
```
docker ps -a
```
Look for containers with status Exited (1), Exited (137), or Created. Any container that’s not Running is suspect.
If you don’t see any containers, check WSL:
```
wsl -l -v
```
You should see your distros with a status of Running. If a distro shows Stopped, that’s your problem.

Fix: Restart the container or WSL instance

If it’s a container, stop and restart it:
```
docker stop container_name_or_id
docker start container_name_or_id
```
After running docker start, check the status again with docker ps. It should show Up.
If the container keeps dying after restart, check its logs:
```
docker logs container_name_or_id --tail 50
```
Look for exception messages, missing file errors, or “exited with code 1”. That’s your real bug. Fix the app, rebuild the image, and redeploy.
For WSL, restart the distro:
```
wsl --terminate distro_name
wsl --distribution distro_name
```
After the second command, you should see the WSL prompt appear. If it errors out again, try restarting the LxssManager service:
```
net stop LxssManager
net start LxssManager
```

Pro tip: If you’re using Docker Desktop, try restarting it from the system tray (right-click Docker icon → Restart). This kills all containers, then starts Docker Engine fresh. It’s a sledgehammer, but it works when you’re in a hurry.

2. SSH Session Closed Abruptly

Another common cause: you’re connected to a remote server via SSH, and the connection drops—maybe the server rebooted, your VPN disconnected, or your laptop went to sleep. Your SSH client (like PuTTY, OpenSSH, or Terminal) still holds an open handle to a named pipe on Windows. When the network timeout kicks in, the pipe breaks, and 0XC000014B shows up in your terminal or in an application log.

How to verify it’s an SSH issue

Check if you had an SSH session open when the error occurred. Look for messages like “Connection closed by remote host” or “packet_write_wait: Connection to X.X.X.X port 22: Broken pipe”. If you see those, the pipe error is just a side effect.

Fix: Restart or reconfigure your SSH client

Close the affected terminal session. Then open a new one and reconnect to the server. If the reconnect works, you’re good.
To prevent this in the future, edit your SSH config (or PuTTY settings) to send keep-alive packets. For OpenSSH, add these lines to ~/.ssh/config (or C:\Users\YourName\.ssh\config on Windows):
```
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
```
This sends a keep-alive packet every 60 seconds. If the server doesn’t respond after 3 tries (3 minutes total), the client closes the connection cleanly instead of leaving a dead pipe.
For PuTTY, go to Connection → Seconds between keepalives (0 to turn off) and set it to 60.

3. Application or Service That Uses Named Pipes Crashed

Less common, but I see it with custom .NET apps, SQL Server named instances, or even backup software that uses inter-process communication via named pipes. Your app (say a C# service) creates a named pipe server. A client connects. The server crashes or gets terminated by Task Manager. The client tries to send data, and boom: 0XC000014B.

How to track it down

Open Event Viewer: eventvwr.exe.
Go to Windows Logs → Application.
Look for Error-level events around the time the pipe error appeared. Filter by source “.NET Runtime” or “Application Error”.
Check the System log for unexpected service stops (Event ID 7031 or 7034).

Fix: Restart the service or app

If you found a service that crashed, restart it from Services.msc:
Press Win + R, type services.msc, press Enter.
Find the service, right-click it, and choose Restart.
After the restart, try your client app again. If the error goes away, you’ve confirmed the service is the cause.
If the service keeps crashing, look in its own logs (often in C:\ProgramData\AppName\Logs or C:\Users\Public\Documents\AppName). Fix the bug in the app code, or reinstall the software.

One more thing: If you’re a developer, and you wrote the pipe server, make sure you’re handling PipeException or IOException with the ErrorCode 0xC000014B (or ERROR_BROKEN_PIPE, which is 109 in Win32). Wrap your read/write calls in a try-catch and gracefully close the pipe. Don’t let it bubble up as an unhandled exception.

Quick-Reference Summary Table

Cause	Symptoms (besides error code)	Quick Fix
Docker container crashed	Container shows `Exited` status; logs show crash	`docker start container_id` or restart Docker Desktop
WSL instance stopped	`wsl -l -v` shows `Stopped`	`wsl --terminate distro_name` then restart WSL
SSH connection dropped	Terminal shows “Broken pipe” message	Close terminal, reconnect; enable keep-alive in SSH config
Local app/service using named pipe crashed	Event Viewer shows Application Error or service stopped	Restart the service from Services.msc; fix the app bug

That’s it. Nine times out of ten, 0XC000014B is your container or WSL distro dropping dead. Check those first, and you’ll save yourself an hour of digging through pipe internals. If you’re still stuck after trying all three fixes, post the full error context (what you were running, what logs show) to a tech forum—someone’s seen that exact combo before.