Introduction

System.IO.Exception: The pipe is being closed during BeginWaitForConnection usually means the server-side pipe instance changed state before the asynchronous wait completed. In practice, that often comes from disposing the NamedPipeServerStream too early, reusing the same instance incorrectly, or letting shutdown logic race against an outstanding async accept. The error is usually about object lifetime and pipe state, not about the client doing something mysterious.

Understand the lifecycle of one server pipe instance

A NamedPipeServerStream instance represents one server-side pipe endpoint. You begin waiting for a client, complete that wait, communicate, then dispose that instance. If you need to accept another client, you usually create another server instance.

That lifecycle matters because BeginWaitForConnection is not something you keep calling on one already-closing or already-used object.

A common failure pattern

This kind of code is fragile:

1var pipe = new NamedPipeServerStream("demo", PipeDirection.InOut, 1);
2pipe.BeginWaitForConnection(OnConnected, pipe);
3
4// somewhere else, before the callback completes:
5pipe.Dispose();

If the pipe is closed while the asynchronous wait is still pending, the callback path may observe "the pipe is being closed." That is expected from the object's state, even if it is inconvenient.

Complete the async wait correctly

If you use the old APM pattern, the callback must call EndWaitForConnection, and the pipe should remain alive until that completes.

1using System;
2using System.IO.Pipes;
3
4public static class PipeServer
5{
6    public static void StartListening()
7    {
8        var server = new NamedPipeServerStream("demo", PipeDirection.InOut, 1);
9        server.BeginWaitForConnection(OnClientConnected, server);
10    }
11
12    private static void OnClientConnected(IAsyncResult ar)
13    {
14        var server = (NamedPipeServerStream)ar.AsyncState!;
15
16        try
17        {
18            server.EndWaitForConnection(ar);
19            Console.WriteLine("Client connected");
20        }
21        catch (ObjectDisposedException)
22        {
23            Console.WriteLine("Server pipe was disposed before connection completed");
24        }
25        catch (Exception ex)
26        {
27            Console.WriteLine(ex.Message);
28        }
29    }
30}

Two rules matter here:

• keep the pipe alive until EndWaitForConnection
• do not treat one server instance as a permanent reusable listener for every future client

Create a new server pipe for the next client

Once a client connects, a common server pattern is to immediately spin up the next listening instance while the current one handles the connected client.

1private static void OnClientConnected(IAsyncResult ar)
2{
3    var server = (NamedPipeServerStream)ar.AsyncState!;
4
5    try
6    {
7        server.EndWaitForConnection(ar);
8
9        // Start the next listener with a fresh instance.
10        StartListening();
11
12        // Handle the connected client on this instance.
13        using var writer = new StreamWriter(server) { AutoFlush = true };
14        writer.WriteLine("hello");
15    }
16    catch (Exception ex)
17    {
18        Console.WriteLine(ex.Message);
19        server.Dispose();
20    }
21}

This avoids the common misconception that the same NamedPipeServerStream instance should go back into a fresh BeginWaitForConnection cycle after connection and teardown.

Prefer modern async APIs when possible

If you are writing new code on modern .NET, WaitForConnectionAsync is usually easier to reason about than the older Begin... and End... pattern.

1using System;
2using System.IO.Pipes;
3using System.Threading.Tasks;
4
5public static async Task RunAsync()
6{
7    while (true)
8    {
9        using var server = new NamedPipeServerStream("demo", PipeDirection.InOut, 1);
10        await server.WaitForConnectionAsync();
11        Console.WriteLine("Client connected");
12    }
13}

This does not remove lifecycle concerns, but it makes them easier to express.

Common Pitfalls

The biggest mistake is disposing the server pipe while an asynchronous wait is still in progress.

Another issue is trying to reuse one NamedPipeServerStream instance across multiple connection lifecycles as if it were a permanent listening socket object.

Developers also forget to call EndWaitForConnection in the callback. In the old APM model, beginning the operation is only half the pattern.

Finally, shutdown logic often races with outstanding accepts. If the server is stopping, make that path explicit and expect pending waits to be canceled or faulted cleanly.

Summary

• "The pipe is being closed" during BeginWaitForConnection usually points to a pipe lifecycle problem.
• Keep the NamedPipeServerStream alive until EndWaitForConnection completes.
• Use a fresh server pipe instance for the next client connection.
• Be careful about disposal and shutdown races with pending async accepts.
• On modern .NET, prefer WaitForConnectionAsync for clearer connection-handling code.