Reopening serial port fails if not closed properly with CloseHandle

Question

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 m

Answer 1

Maybe you can add a Try catch close around your main code, and call CloseHandle in the catch close. Then even if the program craches, CloseHandle will be called.

try
{
   HANDLE hPort = NULL;
   hPort = CreateFile(...);
   // You code...

}
catch (...)
{
   if (hPort != NULL)
       CloseHandle(hPort);
}

Answer 2

One other thing that you don't want to happen is to have an open usb serial port and the user pull the usb to serial adapter. That bug has (is?) been around for a long time. Here was an answer to the bug

"Posted by Microsoft on 3/27/2009 at 4:03 PM Hi, Thank you for reporting this issue. We are aware of this problem and have fixed it for the next major release of the .NET framework.

If you have any concerns, please reactivate this issue and I'll respond asap. Thanks, Kim Hamilton Base Class Libraries"

Don't know if the problems are related. Microsoft Connect has more than a few USB Serial bugs reported.

Answer 3

Try unplugging the device and plugging it back in. Sometimes Windows needs to be reminded that nobody's connected to that port anymore.

Answer 4

Is there any possibility that some threads or child processes of your crashed program are still running and holding a copy of the file handle? Perhaps a debugger process is still open? If so, those might be keeping the device open. I'd check Task Manager just to be sure; if so, force-killing the leftover processes might fix the problem.

Answer 5

This is certainly not normal. Windows automatically closes any handles that are left open after the process terminates. This must be a flaw in your USB device driver, although it is hard to see how it could mess this up. The ones that emulate serial ports are however notoriously lousy. Well, nothing much you can do but hope for a driver update from the manufacturer. Or a device from another manufacturer.

Answer 6

I agree with both previous posts.

1. This is not a normal situation.
2. Unplugging the USB device usually helps.

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 there're several other known problems with some FTDI drivers:

• 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).

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