如果未使用CloseHandle正确关闭，重新打开串行端口将失败 [英] Reopening serial port fails if not closed properly with CloseHandle

问题描述

我正在使用在Windows上被视为虚拟串行端口的USB设备。我可以使用CreateFile和ReadFile函数与设备通信，但在某些情况下，我的应用程序不调用CloseHandle（当我的应用程序在开发崩溃）。之后，对CreateFile的所有调用失败（ERROR_ACCESS_DENIED），唯一的解决方案是再次登录到我的计算机。

I am working with USB device on Windows that is seen as a virtual serial port. I can communicate with the device using CreateFile and ReadFile functions, but in some cases my application does not call CloseHandle (when my application in development crashes). After that all calls to CreateFile fail (ERROR_ACCESS_DENIED), and the only solution is to log in to my computer again. Is there any way to force closing the open handle (or reopening) programmatically?

推荐答案

我同意以前的帖子。

1. 这不是正常情况。


2. 拔下USB设备通常有帮助。

这个问题与FTDI驱动程序中的毛刺有关，后者负责实现虚拟COM端口。
另一方面，这些毛刺与USB设备的各种故障相关。 （当然，这不是FTDI驱动程序的理由。）

This problem is related to the glitches in the FTDI driver, which is responsible for implementing a virtual COM port. On the other hand those "glitches" are related to various malfunctions of the USB devices. (Of course this doesn't justify the FTDI driver).

BTW有一些FTDI驱动程序的其他已知问题：

BTW there're several other known problems with some FTDI drivers:

• 有时调用 CloseHandle 只是挂起调用线程。


• 应用程序仍然在任务管理器中可见，即使在它关闭后。任务管理器不能终止应用程序，并且调试器不能附加到它。

• Sometimes call to CloseHandle just hangs the calling thread.
• Sometimes also the application is still "visible" in the task manager, even after it's closed. Task manager can't terminate the application, and the debugger can't be attached to it. Its EXE file is locked (can't be erased).

通常，立即拔掉USB设备有助于解决这些问题。 FTDI驱动程序，似乎是等待的东西醒来。

Usually unplugging the USB device immediately helps in those situations. The FTDI driver, which seems to be "waiting for something" awakes.

这篇关于如果未使用CloseHandle正确关闭，重新打开串行端口将失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！