Cause #1: A Service or Process Crashed Mid-Transfer
The most common trigger for ERROR_NO_DATA (0x000000E8) is a service or process that dies while holding the pipe. I've seen this a hundred times with print spoolers on Windows 10 and Server 2016. You send a print job, the spooler service hiccups, and instead of a clean failure you get this cryptic pipe error.
The fix is simple: restart the service that owns the pipe. If you don't know which one, look at the error context. If it's from a program like SQL Server, it's the SQL service. If it's from printing, it's the Print Spooler.
Restart the Print Spooler (most common)
- Open an admin Command Prompt.
- Run:
net stop spooler - Then:
net start spooler
That clears the pipe and the error usually goes away. Had a client last month whose entire print queue died because of this—one spooler restart and they were back to printing invoices.
If the spooler keeps crashing, check the Event Viewer for a crash log. The culprit is often a bad printer driver. Update or remove it.
Cause #2: Antivirus or Firewall Interference
Second on my list is security software. I've seen McAfee and Bitdefender kill named pipes between applications for no good reason. The error pops up when an antivirus hooking the Windows API decides to terminate a pipe that's still in use.
You'll notice this with custom line-of-business apps that talk to each other over \\.\pipe\ paths. The app opens a pipe, the AV scans it, and the pipe gets closed with 0xE8.
How to confirm and fix it
Test by temporarily disabling real-time protection. If the error stops, you've found your culprit. Don't leave it disabled—add an exclusion for the app's executable or the pipe path.
- Add exclusions for your app's
.exefiles. - If possible, exclude the pipe namespace (
\\.\pipe\) in the AV's network protection settings.
I've also seen Windows Defender Firewall do this if you've got a rule blocking loopback traffic. If the app runs on the same machine, make sure the firewall allows local connections.
Cause #3: Application Bug or Resource Leak
Third, and less common, is a bug in the app itself. Sometimes the app closes the pipe handle prematurely or doesn't handle ERROR_NO_DATA gracefully. This shows up when you're using a named pipe server that has a race condition—the client connects, the server closes the pipe before writing the response, and boom.
I worked with a small logistics company whose barcode scanning app threw this error every time they scanned a package faster than 2 seconds. Turned out the app's pipe server was single-threaded and would close the pipe if a new connection came in while it was still processing the previous one.
What to do
- Check if the error happens at a specific action or timing. If yes, report it to the vendor.
- Try running the app as administrator. Sometimes pipe access rights cause the error.
- Check for patch updates. The vendor may have fixed it.
If you're a developer, look at your pipe server code. Make sure you're not calling DisconnectNamedPipe before all data is read. Also handle ERROR_NO_DATA as a normal end-of-stream condition.
Quick Reference Summary
| Cause | Fix |
|---|---|
| Service crashed (print spooler, SQL, etc.) | Restart the service that owns the pipe. |
| Antivirus/firewall interference | Test with AV disabled, then add exclusions. |
| Application bug/resource leak | Update app, run as admin, or contact vendor. |
That's it. Start with the first fix, you'll solve most cases. If you're still stuck after all three, the pipe is likely coming from a driver issue—check for Windows updates and driver updates.