Problem with SerialPort

Question

I\'m working with SerialPort to communicate (read only) with barcode reader.

I\'ve installed driver to operate with the reader as if it was connected via Com-port,

Answer 1

I solved this problem by creating a separate process which handles the serial port. When the serial port is unplugged I restart the process. Now I can reconnect to a unplugged serial port device without restarting the main application.

TLDR; Create a separate process.

Example code

Serial port process code

static void Main(string[] args)
{
    using (var output = Console.OpenStandardOutput())
    using (var serialPort = new SerialPort(args[0], int.Parse(args[1])))
    {
        serialPort.Open();
        while (serialPort.IsOpen)
        {
            serialPort.BaseStream.CopyTo(output);
        }
    }
}

Main application

var options = new ProcessStartInfo()
{
    FileName = "Serial Port Process name here",
    UseShellExecute = false,
    RedirectStandardOutput = true,
};

using(var process = Process.Start(options))
{
    using (StreamReader reader = process.StandardOutput)
    {
        while (!process.HasExited)
        {
            string result = reader.ReadLine();
            Console.WriteLine(result);
        }
    }
}

Answer 2

I've had the same experience. Although it is not advised, you can unplug and plugin a serial device to an actual serial port and the communication will begin again. A USB serial port doesn't work this way. I've also had the problem of the USB serial port not appearing as an available port by the SerialPort.GetPortNames() method until after the virtual serial port is instantiated by the software.

Answer 3

Sigh, this an age old problem with USB serial port emulators. Serial ports are devices that date from the stone age. They used to be screwed into the bus, no way to remove them while a program is using it without drawing sparks and billowing smoke. Stone age also includes the lack for any kind of plug-and-play support so that a program could detect that the device is suddenly gonzo.

Unfortunately, the majority of the crummy device drivers that emulate them just make them disappear, even though a program has the port opened. This works just about as well as jerking a flash drive out of the socket when Windows is writing files to it. There's a background worker thread that waits for notifications from the device driver so that it can generate the DataReceived, ErrorReceived and PinChanged events. That thread suffers a heart attack when the device suddenly disappears. You can't catch that, it is a thread that was started by the SerialPort class, you can't wrap it with try/catch.

By popular demand, Microsoft did something about it in .NET 4.0. Not actually sure what happens in that release. If you're stuck on an earlier release, the only reasonable thing you can do is tape a sign next to the USB slot: "Don't remove while in use!" Which inevitably makes somebody unplug the device at least twice to see what happens. After which they get bored with that and leave you in peace.

The very unreasonable workaround is an app.exe.config file with this content:

<?xml version ="1.0"?>
<configuration>
  <runtime>
    <legacyUnhandledExceptionPolicy enabled="1"/>
  </runtime>
</configuration>

Don't use it.

Answer 4

You can inherit from SerialPort and override the Dispose() method to handle such exceptions. You can just gobble the exception (Dispose shouldn't be throwing anyway).

If you want to log the exception or handle it in some other way, you will have to check the disposing flag first. If it is false it means that Dispose was called by SerialPort's destructor and the object is already orphaned.

E.g.

    public class MySerialPort:SerialPort
    {
        protected override void Dispose(bool disposing)
        {
            try
            {
                base.Dispose(disposing);
            }
            catch (Exception exc )
            {                    
                if (disposing)
                {
                    //Log the error
                }
            }

        }
    }

Answer 5

Well, bad news.

Solution by Panagiotis Kanavos does not help. The problem is still here.

.Net 4.0 doesn't help either. I've installed VS2010 - nothing changed. The unhadled exception is still thrown. Unfortunately, "tape a sign next to the USB slot: "Don't remove while in use!" seems to be the only decision...

Answer 6

In my code, this happens as part of the Finalize() method on the BaseStream, which is called by the garbage collector.

As such, if one inherits the .NET SerialPort class and overrides the Open / Close, you can do the following:

During the Open, just call GC.SuppressFinalize(Me.BaseStream)

During the close, try to call GC.ReRegisterForFinalize(Me.BaseStream)

If the USB has been pulled out, this will throw an exception, moaning about access to the BaseStream. Either check the .IsOpen property before calling the GC, or wrap it in a Try Catch if you don't trust .IsOpen to return False every time...

That'll sort it out, your application will handle the fact that it's been pulled out, and it won't crash when you close.

I'm currently unable to make it then re-open the port if it's plugged back in, but at least there's some progress beyond a label saying don't touch...