The USB driver does not close serial port on device unplug on Windows

[honguyenminh]

I have two Arduino Uno R3. A fake (CH340G) one and a real one.
I made an app to interact with it by the SerialPort object from System.IO.Ports library in C#

By adding a check on IsOpen every time I read or write data, there should be no problem.

Just realized that with the real Arduino when I unplug the device, the system does not know that the port is closed, so the port appear as still open, which causes a lot of problems.

But with the same sketch and app on the fake, CH340G one, everything works fine. On unplug, the system knows that and the port is closed.

The driver should tell the OS that the serial port is closed after USB unplug.

[honguyenminh]

Same thing happen on Arduino IDE Serial Monitor. With the CH340G when I unplug the device it will blank out. But nothing happen with the real Arduino

[matthijskooijman]

Hm, I'm afraid this is beyond Arduino's reach to fix. The official Uno r3 uses a 16u2 microcontroller for USB-to-serial, which just poses as a "CDC ACM" serial modem device, which uses standard Windows drivers. The only Arduino-specific "driver install" that you need is a simple .inf file that associates the Arduino USB ids with the standard CDC driver, so there is no driver behavior defined in there (unless the CDC driver exposes some relevant options that could be set from the .inf file, but I doubt that). On Windows 10, this .inf file is not even used anymore, and Windows associates the driver based on the USB device class (or something like that). Note that I'm assuming you use Windows here, but situation is similar on Linux (though there we could submit patches for kernel drivers, of course).

So I don't think there's anything Arduino can really do on the PC side of the link. Obviously, from the Arduino/16u2 side, there's also nothing we can do to influence how things look on the PC after unplugging (unless you could somehow set up some flags before unplugging that influence how the unplug is handled by Windows later).

It is interesting that the CH340G handles this differently, though, so it might be interesting to investigate what causes this difference. If it is just a difference in how these two drivers are implemented, then there's not much to do, but maybe there is some configuration or some error condition involved.

I won't have any opportunity to investigate this myself and I suspect this is also not a priority for the Arduino core devs, but maybe you want to investigate this more closely yourself, or maybe someone else in the community? If so, a good start might be to make a tiny C# program that can be used to reproduce the problem, and check if it happens across multiple machines and Windows versions?

[PaulStoffregen]

Any chance you're using Windows 7?

You didn't say which version (or even if this is Windows), but I can tell you all Windows before version 10 have a known bug in USBSER.SYS. Microsoft fixed it in Windows 10, but they never backported the fix to Windows 7 or 8.

[honguyenminh]

I am using windows 8.1

Will try again with windows 10 to see if that is still present

[hanen1234]

Who's have package ares isis of arduino mega 2560

[dsyleixa]

Who's have package ares isis of arduino mega 2560

what? perhaps try Google Translate!

[hanen1234]

Library arduino mega 2560 in PCB layout (proteus 8 - - >application)

[dsyleixa]

Library arduino mega 2560 in PCB layout (proteus 8 - - >application)

hmmh - what has that to do with the topic to USBSER.SYS Windows drivers?
(I'm observing the same issues like the OP using Windows 7)

[hanen1234]

Windows 7

[honguyenminh]

Tried on Windows 10
A different, but still not the correct, behavior. Now the port appears to be half-closed, the IsOpen property is now false, but it also throw an exception. I didn't have the chance to install VS to see the exception details, but will do that next.

[PaulStoffregen]

I'm curious about "also throw an exception". Maybe that's a C# specific thing?

[honguyenminh]

Then it should have done the same thing with the CH304G one, but the clone's working just fine

[PaulStoffregen]

I'm still curious about the exception. Like, could you say more specific info about it, or give a screenshot? I'm also curious if that sort of exception is rooted in C#, or if it can also happen with other languages? If you're bringing it up here on a github issue conversation, the least you could do is be more specific, rather than saying "also throw an exception" with zero specific info about this exception you're seeing!

[honguyenminh]

I did some research, and can somewhat pin point the issue.
All the test was done on Windows 10.
Windows 8.1 still has broken driver, so no progress there.

First of all, my code was using SerialPort.GetPortNames() method to list the COM port to try connecting to. What this method does is checking the Registry key at HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM for the list of ports. Normally, it works. But not when you unplug the device when the port's still open.

What I was doing is periodically checking for the IsOpen property, if false then call the Close() and Dispose() method. Both of these method is the exact same, and in this case is also wasteful, since the port object will be closed anyway on unplug.

The exception that was raised on Windows 10 is not in the Close method, but in the Open method that I tried to use to open new port from the SerialPort.GetPortNames().

Turns out the registry key isn't updated since the worker thread that was used by serial object crashed, thus didn't release it from the registry. The red text in screenshot below just means "Disconnected".

After the device is unplugged, device manager doesn't list Arduino under COM ports anymore, but the key remains in the registry.

Close the application, and the key will be gone.

What still drives me mad is the CH340G don't have any of the above problems. Unplug it and the key will be gone. Weird.

I'm trying this on Python to see if the problem persist. If it does, then there's some problem with USBSER.sys. Else, maybe it's the way SerialStream is implemented on C#.

TL;DR this is not a problem with the Arduino, but with the Windows driver. I'll close this issue on here, it's not the core dev's problem.