Winapi 关闭并立即重新打开COM端口失败：为什么？

我试图通过测试COM端口的“可打开性”来进行“飞行前检查”，然后启动一个对话框窗口，允许用户进行COM端口操作

以下是代码顺序，大致如下：

handle = CreateFile("\\\\.\\COM4:", GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);

if (handle != INVALID_HANDLE_VALUE)
{
  CloseHandle(handle);
  DoTheWork("\\\\.\\COM4:");
}
else
{ 
  ShowMessage("I'm sorry Dave, I can't do that"); 
} 

...

void DoTheWork(char * port)
{
  handle = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0,NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,NULL);
  /// do lots of stuff
  CloseHandle(port);
}

问题是：“DoTheWork”是一个经过测试的函数，它自己可以正确执行。只有在前面的CreateFile/CloseHandle调用之后立即调用时，当第二个CreateFile返回E_ACCESSDENIED时，它才会失败

更糟糕的是，如果我在调试器中缓慢地遍历代码，它就可以正常工作

---

在第一个closeHandle之后，我似乎需要一个Sleep（），但这感觉像是一次黑客攻击——我无法知道它需要多长时间。

系统需要一点时间来关闭资源。可能有一些神秘的方法来测试它是否被释放，但我不知道那是什么。我所知道的是，如果您检查注册表项：

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

---

您将看到哪些串行端口是可用的，而无需打开它们，这将解决您的问题。

好吧，在进行了更多的调查之后，这与Windows CE而不是Win32有关

之后有两秒钟的延迟 在端口之前调用CloseHandle 已关闭，资源已释放

---

我想Win32也是如此，但我还没有找到任何书面证据。

在关闭句柄之前尝试调用PurgeComm（）或FlushFileBuffers（）。

为什么不打开句柄并将其传递给DoTheWork？@David，我不想接触系统的工作部分-但是，我现在没有选择；-）这会告诉我安装了哪些端口，但不会告诉我哪些端口实际上是可打开的（即，尚未被其他代码打开），这可能与此相关——但ce下延迟的部分原因是某些平台上缺少FlushFileBuffers（）。