Windows命名管道ReadFile失败（错误码232）：32/64位IPC通信问题

错误码232对应ERROR_BROKEN_PIPE，表示管道的另一端已关闭或连接中断。结合32位转64位后出现问题的场景，以下是具体排查方向：

1. 管道模式不匹配问题 #

你的管道创建时使用了PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE的混合模式（消息类型管道+字节读模式），虽在32位环境下兼容，但64位环境中这种混合模式可能导致消息边界识别异常，进而触发管道连接中断。

修复建议：
统一管道的类型与读模式，二选一：

• 改为字节模式：

  tempHandle = CreateNamedPipe(PipeNameStart,
  PIPE_ACCESS_INBOUND,
  PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_NOWAIT,
  1,
  node->GetPipeSize(),
  node->GetPipeSize(),
  0,
  NULL);
  

• 改为消息模式：

  tempHandle = CreateNamedPipe(PipeNameStart,
  PIPE_ACCESS_INBOUND,
  PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_NOWAIT,
  1,
  node->GetPipeSize(),
  node->GetPipeSize(),
  0,
  NULL);
  

2. 写端管道句柄过早关闭 #

WriteFile返回成功仅代表数据已写入管道缓存，但如果32位程序在写入后立即关闭了管道句柄，64位程序执行ReadFile时管道已断开，就会返回ERROR_BROKEN_PIPE。

排查步骤：

• 在32位程序的WriteFile后，延迟关闭管道句柄，确保64位程序有足够时间读取数据；
• 检查32位程序中是否存在句柄泄漏或意外释放的逻辑。

3. 32/64位数据编码/长度不兼容 #

• 若两端CString编码不一致（32位为ANSI、64位为Unicode，反之亦然），会导致数据解析异常，间接引发管道错误；
• 确认amountToSend是否为实际要传输的字节数（如字符串需包含终止符，应为strlen(message)+1或wcslen(message)+1，需匹配编码）。

修复建议：

• 统一两端编码，或直接以字节流形式传输数据，避免字符串编码差异；
• 打印WriteFile返回的amount值，确认实际写入字节数，确保64位程序的bufferSize不小于该值。

4. 非阻塞模式的异常触发 #

你使用了PIPE_NOWAIT非阻塞模式，这种模式下管道操作对时序要求更高，若64位程序在管道未就绪时发起读取，可能触发连接中断。

排查步骤：
暂时去掉PIPE_NOWAIT参数，改用默认阻塞模式测试，若问题消失，则需调整非阻塞模式下的时序逻辑（比如通过WaitNamedPipe等待管道就绪后再读取）。

5. 管道句柄有效性验证 #

在64位程序执行ReadFile前，验证管道句柄是否有效：

if (node->GetPipeHandle() == INVALID_HANDLE_VALUE) {
    // 句柄无效，排查管道连接逻辑
    return FALSE;
}

内容的提问来源于stack exchange，提问作者Tej Ravi