.NET5下NamedPipeServerStream与NamedPipeClientStream连接异常问题

最初写法的问题 #

你的代码问题本质出在两个逻辑的冲突：

• 程序启动时先做「管道存在性检测」的操作，会向系统发起打开目标管道句柄的请求，这个请求会直接占用空闲的管道实例
• 默认只创建了1个管道服务端实例，检测请求占住唯一实例后，客户端正式的Connect()调用就没有可用实例了

另外你对MaxNumberOfServerInstances参数的理解有误：这个参数仅限制同一个管道名称最多允许创建多少个并行服务端实例，不会自动生成新实例。你只实例化了1个NamedPipeServerStream对象，哪怕把该参数设为-1，同一时间也只有1个可用实例，所以修改该参数没有效果。

调整后方案的性质 #

你当前的「等待→断开→再等待」逻辑是针对你现有检测逻辑的可行 workaround，但不属于标准实现。
标准实现推荐两种方案：

• 取消提前检测管道存在性的逻辑，客户端直接调用带超时的Connect(2000)方法，如果抛出超时异常则说明无服务端运行，当前进程直接升级为服务端即可，避免无效的预连接请求占用实例
• 服务端启动后根据预期并发量创建多个管道实例，每个实例单独跑等待连接、处理请求的逻辑，避免单实例被预连接占满后无法处理正常请求

背后的运行逻辑 #

这是Windows命名管道的底层设计导致的：
Windows的命名管道服务端实例调用WaitForConnection()后，只要收到任何进程发来的打开管道句柄的请求，就会立即返回，IsConnected属性也会置为true，不会校验这个请求后续是否会完成完整的连接握手、是否有后续的读写操作。
你之前的管道存在性检测操作就是发起了这个打开句柄的请求，触发服务端WaitForConnection()返回，但检测逻辑没有完成后续的连接流程，也没有主动释放句柄，就形成了半开的无效连接：服务端认为连接已建立，客户端正式Connect()请求拿不到空闲实例就会无限等待，WinObjEx64提示「所有管道实例繁忙」也是这个原因。
你加的Disconnect()操作就是主动释放了这个被检测逻辑占住的无效实例，第二次WaitForConnection()等待到的就是客户端正式的连接请求，所以能正常通信。

内容的提问来源于stack exchange，提问作者Alex xelA