我正在使用Windows上的USB设备，将其视为虚拟串行端口。 我可以使用CreateFile和ReadFile函数与设备进行通信，但在某些情况下，我的应用程序不会调用CloseHandle（当我的应用程序在开发中崩溃时）。 之后，所有的CreateFile调用失败（ERROR_ACCESS_DENIED），唯一的解决办法是再次login到我的电脑。 有什么办法强制closures打开句柄（或重新打开）以编程方式？
这当然不正常。 Windows会自动关闭进程终止后保持打开状态的任何句柄。 这一定是你的USB设备驱动程序中的一个缺陷，尽管很难看出它是如何搞砸的。 模拟串口的不过是臭名昭着的。 那么，没有什么可以做的，但希望从制造商更新驱动程序。 或来自其他制造商的设备。
我同意以前的帖子。
此问题与FTDI驱动程序中的故障有关，该驱动程序负责实现虚拟COM端口。 另一方面，这些“毛刺”与USB设备的各种故障有关。 （当然这不能证明FTDI驱动程序是正确的）。
顺便说一句，还有一些FTDI驱动程序已知的其他问题：
CloseHandle只是挂起调用线程。 通常拔出USB设备立即有助于在这些情况下。 FTDI的司机，似乎在“等待着什么”醒来。
有没有可能你的崩溃的程序的一些线程或子进程仍在运行，并持有文件句柄的副本？ 也许一个调试程序仍然是开放的？ 如果是这样，那么可能会使设备保持打开状态。 我会检查任务管理器只是为了确保; 如果是这样，强行杀死剩余的进程可能会解决这个问题。
另一件你不想发生的事情是有一个开放的USB串行端口，用户将USB拉到串行适配器。 那个bug已经存在了很长时间了。 这是一个错误的答案
“Microsoft发表于2009年3月27日下午4:03嗨，感谢您报告此问题。我们意识到这个问题，并已修复它的.NET框架的下一个主要版本。
如果您有任何疑问，请重新激活此问题，我会尽快回复。 谢谢，金汉密尔顿基地级图书馆“
不知道问题是否相关。 Microsoft Connect有多个USB串行错误报告。
也许你可以在你的主代码附近添加一个Try catch，并且在close catch中调用CloseHandle。 那么即使程序破裂，CloseHandle也会被调用。
尝试{HANDLE hPort = NULL; hPort = CreateFile（…）; //你的代码…
catch（…）{if（hPort！= NULL）CloseHandle（hPort）; }
尝试拔下设备并重新插入。有时Windows需要提醒没有人连接到该端口了。