SerialPort Crashes after disconnect of USB COM port

[Guest]

We have an application talking to a phone via a USB-cable, using
System.IO.Ports.SerialPort.

If the user unplugs the USB cable from the PC before the application has
called SerialPort.Close(), we (nearly always) get an unhandled exception
window (<application> has encountered an error and needs to close. Please
inform Microsoft about the error. Etc. etc.) about a
System.ObjectDisposedException.

Calling close after the USB cable has been unplugged does not help - it
throws an exception that we can catch (UnauthorizedAccessException), but the
error report comes anyway.

We believe this happens when the CLR disposes the serial stream. It does not
happen on "our" thread - we can't catch it.

When the USB cable is unplugged the COM port will disappear from the system
- it is not returned from SerialPort.GetPortNames().

We have the same behaviour with both SonyEricsson phones (T610, T630) and
Siemens (S55).

The phone does not appear in Safely Remove Hardware - neither when attached
or removed.

The problem does not arise when running in the debugger.

Here is sample code that exposes the problem. Attach a (turned on) cell
phone via a USB cable before running the sample - change the COM-port to
match the one you are using.

====
using System;
using System.IO.Ports;

namespace SerialPortUsbCrash {
class Program {
static void Main(string[] args) {
SerialPort serialPort = null;
serialPort = new SerialPort("COM12", 19200, Parity.None, 8,
StopBits.One);
serialPort.Open();
Console.Write("Pull out the USB cable, and push return");
Console.ReadLine();
try {
serialPort.Close();
} catch (Exception ex) {
Console.WriteLine("Got exception closing SerialPort: " + ex);
}
Console.WriteLine("- THE END -");
Console.ReadLine();
}
}
}
====

Any advice? Fix? Patch?

Best regards,
Speakanet

 

[Dick Grier]

Hi Jens,

This does not happen "universally." I just tried it with two different USB
serial adapters, and I didn't get an exception.

My thought is that there is something funny going on with the USB virtual
serial port driver for your device. In the past (before the days of
VS2005), I've had trouble with several different USB adapters, and updating
the driver from the manufacturer has fixed those problems. Have you tried
your device with other serial programs (non-VS2005)?

Also, MS does not monitor these newsgroups. So, you have to report bugs
directly (Product Feedback Center:
http://msdn.microsoft.com/vstudio/support/).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Guest]

Hi Dick,

Thank you for the answer, but unfurtunally we do not regard this as a driver
problem.

We have a .NET 1.1 version where we use native Win32 calls, and that works
fine - using the same device, cable, port and driver.

Bonus information:
When we get the unhandled exception (after the program has stopped) we get
the following stack trace:
Unhandled Exception: System.ObjectDisposedException: Safe handle has been
closed
at Microsoft.Win32.UnsafeNativeMethods.WaitCommEvent(SafeFileHandle
hFile, Int32& lpEvtMask, NativeOverlapped* lpOverlapped)
at System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

To us, this looks like SerialStream.WaitForCommEvent fails when the thread
is aborted and the port has disappeared.

(Thank you for the tip about Feedback Center - we realized that too after
posting in this news group, so we have already reported it there, too.)

Best regards
Speakanet

 

[Dick Grier]

Hi Jens,
To us, this looks like SerialStream.WaitForCommEvent fails when the thread
is aborted and the port has disappeared.
<<

I haven't duplicated this, but I can imagine how it might happen. In fact,
I used a different approach in my DesktopSerialIO class -- just because I
was uncertain how to handle the problem of the CreateFile handle becomming
invalid after having been passed to WaitCommEvent.

You can download DesktopSerialIO from my homepage, and give it a try. This
may provide a work around for you. Let me know the results with your
hardware (BTW, I do not provide the equivalent PortNames method, and the
overall API that DesktopSerialIO furnishes is simpler than that of
System.IO.Ports -- however, it is sufficient to handle everything that might
be needed, IMO).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.