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 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?

Homespun

Has something changed with this? The same problem with Win7 + .NET 4.5 Only USB replugging helps =( – React

Answer 1

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.

Quadrate

Thanks for all the answers. Looks like I am not the only one having USB to serial issues. My current workaround is to try calling CreateFile in a loop with delay until it succeeds. Seems to work for now, probably it won't work on any other computer. – Homespun

I've noticed that sometimes I have to close the IDE I was debugging with before windows and/or the device driver realizes that the device is no longer in use. That doesn't seem like it should be the case but it is. – Enamour

Answer 2

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.

Bolden

After some further testing I noticed that CreateFile can fail even after closing the connection with CloseHandle. Fortunately calling CreateFile in a loop with delay seems to do the trick. Usually it takes less than 10 tries to reopen the device. – Homespun

Answer 3

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.

Hartzog

Task manager shows my application process exits properly. Looks like this is a device driver bug. – Homespun

Answer 4

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.

Winner

Answer 5

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);
}

Crossness

Answer 6

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

Jaddan

This has nothing to do with Windows. As valdo and Hans point out it is the device driver that is causing the problem. – Blare