C++ WriteFile返回错误代码995

我已经搜索了stackoverflow，并在谷歌上彻底搜索了这个问题，但没有找到导致这个问题发生的线索

我正在编写一个C++程序，它与通过USB连接的测量设备通信。程序是多线程的，多个线程将与设备通信。互斥锁用于确保没有两个线程同时尝试从设备读取或写入数据

使用将命令发送到设备，并使用读取响应和测量值-两个操作同步完成

有时，在从设备读取测量值时，由于测量设备本身内部的同步错误，测量会因超时而失败（GetLastError（）返回错误代码121），这是正常的，也是预期的

当我尝试继续测量时，通过发送一个新命令，WriteFile有时（大约50%的时间）会失败，GetLastError（）返回错误代码995，在MSDN中描述为：

错误\u操作\u中止

995 (0x3E3)

The I/O operation has been aborted because of either a thread exit or an application request.

超时发生后没有线程退出，也没有取消任何读写操作。我只能通过使用CloseHandle和CreateFile关闭和重新打开与设备的通信来恢复通信。然而，这将需要一段时间的测量，并不是一个理想的解决方案

---

我的问题是，在这种情况下，WriteFile为什么返回错误代码995？我可以做些什么来避免关闭和重新打开与设备的通信？

请与USB串行设备的OEM联系——我们无法进一步帮助您，因为我们无法访问驱动程序的管道。如果设备OEM无法帮助您，请联系USB串行芯片组的制造商；如果他们拒绝提供帮助，将USB-to-serial适配器扔进垃圾桶，购买一个具有制造商支持的芯片组（如FTDI或Silicon Labs USB串行芯片），而不是一些廉价的克隆垃圾。

当通信失败时，您是否尝试完全关闭通信通道从零开始重建它们？也就是说，先关闭然后再打开一个新窗口？是的，完全关闭并重新建立沟通是我发现唯一有效的方法。我的问题是，这会占用测量时间，并降低程序的性能。USB驱动程序是臭名昭著的麻烦制造者。如果出现任意的超时错误，不要期望有好的结果。寻找驱动程序更新，请联系供应商寻求帮助。我同意Hans的观点-您可能需要联系USB串行供应商。作为一名在这类技术上做了大量工作的开发人员，我可以保证很难让事情看起来像一个真正的串行端口。当我看到这样的情况时，我们会为这种行为添加一个回归测试并修复它——希望你能和你的供应商有同样的运气。@HansPassant似乎对这篇文章有一些共识，作为一个答案将是一件好事。