VS2017移植Boost::asio TCP程序到x64时async_send报WSAEFAULT(10014)

刚帮同行排查过几乎一模一样的32位转x64的Boost::asio TCP程序问题，你遇到的WSAEFAULT（错误码10014）本质是系统调用WSASend时收到了无效的内存地址参数，结合32位到64位的迁移场景，给你几个核心排查方向和解决方法：

1. 优先检查缓冲区的生命周期 #

这是最常见的坑！32位下有时候栈内存释放后地址还没被覆盖，系统可能没检测到，但64位下内存管理更严格，一旦async_send用的buffer（比如栈上的std::string、临时数组）在异步操作完成前被销毁，传递给WSASend的就是无效地址，直接触发10014错误。

• 确保所有传给async_send的boost::asio::buffer或者原生缓冲区，在回调触发前都保持有效（比如用堆分配、智能指针管理，或者把buffer绑定到回调的lambda捕获里）。
• 举个反例：如果在函数里创建栈上buffer，发起async_send后直接return，buffer被销毁，64位下必踩这个坑。

2. 排查数据类型的64位兼容性 #

Windows的WSASend参数里藏着不少32位/64位差异：

• 别用int代替DWORD或者size_t：32位下int和DWORD都是4字节没问题，但64位下size_t是8字节，如果你的代码里把buffer长度存在int里，传给WSASend时可能被截断，或者指针被错误转换。
• 禁止把64位指针转成32位类型存储：比如用int存char*指针，64位下地址是8字节，转成int会直接截断，导致传递给WSASend的是无效的32位地址，这绝对会触发WSAEFAULT。
• 检查自定义的buffer结构体：如果自己封装了类似WSABUF的结构，要确保它的内存布局在64位下和系统的WSABUF一致，别因为对齐或者成员类型错误导致参数传递混乱。

3. 确认Boost版本的兼容性 #

有些旧版本的Boost::asio（比如1.60之前）在VS2017的x64环境下存在IOCP相关的bug，特别是处理WSASend的参数时没有考虑64位的内存对齐。建议升级到Boost 1.66及以上版本，这些版本已经针对VS2017和x64环境做了适配。

4. 检查VS2017的编译选项 #

• 确保x64项目的_WIN32_WINNT宏定义正确：至少设为0x0600（对应Windows Vista），确保调用的是64位兼容的Win32 API版本。
• 不要强制32位内存对齐：有些32位项目会设置/Zp4（4字节对齐），迁到x64后如果没改成默认的8字节对齐，可能导致WSABUF这类结构体的内存布局错误，传递给系统调用时参数错位。

调试小技巧 #

直接在Boost源码的win_iocp_socket_service_base.ipp里的WSASend调用处打断点，查看这几个关键参数：

• lpBuffers：WSABUF数组的地址，64位下应该是8字节的有效地址。
• 每个WSABUF的buf指针：同样要是8字节的有效内存地址，指向你的发送数据。
• 每个WSABUF的len：确保是正确的发送长度，没有被截断成负数或者无效值。

只要把这几个点排查一遍，基本就能定位到问题所在。

内容的提问来源于stack exchange，提问作者Gert Corthout