Using SerialPort with USB and removing USB cable while port is open

If I open a com port and then remove the USB cable from PC before closing the com port then there is now way I can dispose the com port after that. Not even Environment.Exit(o) works, i.e. I can not exit my program properly.

The following code describes the problem:

SerialPort port = new SerialPort("COM94");
port.Open();

int n=0;
while (n < 10)
{
n++;
Thread.Sleep(1000);
}

// (Remove USB cable before the while loop has finished)

port.Close(); // <-- won't work
port.Dispose(); // <-- neither will this

Environment.Exit(0); // < ---and not even this one will work

How can I work around this

Btw the same scenario will appear if the USB device crash

I have exactly the same problem....Have you been able to solve the problem yet

Strange there are so few threads about this matter....

I have exactly the same problem as described.

When the USB port is disconnected it appears to dispose of the underlying stream that is internal to the serial port object. As soon as an attempt is made to use the serial port object an exception is then thrown. (Including an attempt to close the port). Unfortunately this exception can not be captured by application code because it is not passed out of the serial port object. The first the application knows about a problem is the CLR insisting on shutting your application down and claiming that it is your application that has caused the problem by not handling an exception. I have an unsolicited data logging application and it may be something to do with an outstanding read with an infinite timeout which is still placed on the now disconnected port.

Bizarrely enough I do not observe any problems when running in the debugger, only when run as an executable and then not every single time.

If I ignore the close down request from the CLR and continue running the application appears to be fine. If you open up the details you get

Unhandled Exception: System.ObjectDisposedException: Safe handle has been closed at Microsoft.Win32.UnsafeNativeMethods.WaitCommEvent

This error is very inconvienient for us as there appears to be no way of handling it programmatically unless we create our own version of the serialObject, which appears to be what other people are doing. What a shame otherwise a very useful object.

Hi,

I am having the problems you have been talking about, but am also seeing problems with CPU usage and memory leaking.

If I am running a task manager, and run my program below, when i remove the USB port at the MessageBox (don't hit the 'OK' button)the CPU usage goes to near 100% and stays there and memory usage is in a continual ramp up. Left it running until it hit 500MB at which my 512Mb machine was running quite poorly. When I close the message box, I get the error dialog similar to what you are seeing.

I have tried 2 different vendors USB-Serial adapters - with different drivers and the problem as epected exists with both.

Peter,

Thanks for your speedy reply regarding possible driver problems. I had run a test before posting my msg.

I tested each USB serial adapter with Hyperterm, opened the port, then unplugged the USB cable side.

I found that with Hyperterm, neither of my 2 vendor's USB serial port adapters maxed out CPU usage (stayed at zero) nor did they start ramping up memory usage.

thanks,

dave

Thanks for the Hyperterm testing info. BTW we are testing on WInXP Pro SP2 and use pretty std serial settings - Xon/Xoff, 9600 baud, 8bits, 1 stop.

Here's the cables we have tried:

BAFO USB-Serial - Prolific 2303 chip, driver is ser2pl.sys, v2.0.2.1, 07/25/2005, MWHC signed

The second USB-Serial adapter is a custom cable by Ositech Communications Inc. OsiUsb.sys, v1.00.021.8, 07/08/2004, not signed

Re: Prolific chip. Thanks for the feedback on your experiences - I'm now out looking for USB cables with a different chip and driver..

I spent the afternoon pestering everyone around for USB serial adapters to try. Got a handfull of big old adapters for which I could locate no drivers and an IOGEAR GUC232A. Turns out the IOGEAR is using a Prolific 2303 chip, and driver by the same ser2pl.sys name.

BTW - For the record I checked Prolific's website http://www.prolific.com.tw/eng/support.asp and drivers I am using are up to date.

dave

Another way to solve this problem is to handle PinChanged event. IMHO this will work if your device uses hardware flow control, like most modems do. In PinChanged I'm checking if EventType is DsrChanged and my SerialPort object's DsrHolding is false, when I try to Close port and swallow any exceptions.