Accessing the base stream

Oct 13, 2014 at 1:34 PM
I have written a library that is able to read and decode packets from a stream (mainly because I would like the communications to be agnostic. I have been using .nets System.IO.Ports.SerialPort basestream, however I am finding the dataReceived event to be problematic so I thought I would give your library a go...

Is there any way to access the base stream from your library?!


Oct 13, 2014 at 2:10 PM
Hi, there is no base stream as in the .NET implementation. The SerialPortStream is already implementing the Stream abstract class. So just use it direct where you would use the base stream.
Marked as answer by jmcurl on 12/14/2014 at 3:48 AM
Oct 13, 2014 at 2:17 PM
Thanks, I will give that a go.
Oct 13, 2014 at 7:24 PM
Ok, so when I open the com port, why would I be getting an exception saying "Unable to clear the serial break state"? this is a virtual serial port over USB...
Oct 13, 2014 at 9:25 PM
You'll have to be much more specific. Please provide the version you're using (the compiles, or from SVN?) and please paste the complete exception stack. In particular, that should provide the Win32 code on what's going wrong, that we can look in MSDN. The code snippet affecting you is probably:

        public sealed class CommModemStatus
            public void ClearCommBreak()
                if (!UnsafeNativeMethods.ClearCommBreak(m_ComPortHandle)) {
                    throw new IOException("Unable to clear the serial break state", Marshal.GetLastWin32Error());

Depending on that code, and information about the serial chipset and the driver, we might be able to determine what the cause is. Incidentally, have you got your serial port connected to a device or not? You could also try a native serial port, and my favourite USB-SER device is FTDI because they have less bugs.
Oct 13, 2014 at 9:53 PM
I used version to start, then because of the error, I downloaded the latest version from SVN and integrated that. The device I am talking to is a Hornby Elink which uses the driver "CDC RS-232 Emulation Demo" (I believe more information can be found here:

I have also made a post on here with possibly relevant information: posts #19 and #22 provide details on the devices internal chipset.

I will post the stack trace in a few moments (after I have reintegrated the code back from!!!
Oct 13, 2014 at 10:01 PM
Edited Oct 13, 2014 at 10:04 PM
the stack trace is:
System.IO.IOException was caught
  Message=Unable to clear the serial break state
       at RJCP.IO.Ports.SerialPortStream.NativeSerialPort.CommModemStatus.ClearCommBreak() in c:\Users\Robin\Source\Repos\RailMasterSharp\src\SerialPortStream\NativeSerialPort_CommModemStatus.cs:line 58
And yes, it was from the code snippet you posted...
Oct 14, 2014 at 7:53 PM
Hi, The error code is 31 = ERROR_GEN_FAILURE. The only documentation for this error is "A device attached to the system is not functioning". Therefore, I'd try a different chipset.

Alternatively, it could just be a bad driver and this feature is not implemented. Then as you're working with the sources, comment out the lines in SerialPortStream.cs method:
 public partial class SerialPortStream : Stream
    public void Open() { ... }
As your stack is cut short, I assume you're getting this in the Open() method. If not, there are three other instances, where the following two instances might also be interesting.
     private void GetPortSettings(string port)
Let me know how that goes, and I might have to put a try/catch around it for future releases, although I would consider this a bug in the driver itself.
Oct 15, 2014 at 9:26 AM
Yes, it is received in the open method. I am not sure which lines do you mean to comment out?
Oct 15, 2014 at 9:37 AM
ok, I have commented out
        public void Open()
            //m_SerialPort.SerialPortModemStatus.ClearCommBreak(); //removed to stop io exception

            // Set the state of the RTS line if handshaking is disabled
            if (!m_SerialPort.SerialPortCommState.OutCtsFlow) {
and the serial port now connects correctly.

I will wrap that line in a try catch block so it will work if it is able to, but I haven't seen any adverse effects yet.

Thanks for your help.
Nov 11, 2014 at 7:58 PM
Thanks for updating your library, I will be able to use the compiled version now :-)

Is there any chance of putting your library on NuGet??? This would make updating much easier...
Nov 11, 2014 at 8:33 PM
It hasn't been compiled yet, although there are three fixes (including the capture). I'll investigate NuGet and I'll add something to the issues list so I don't forget.

The next version will be to indicate a bugfix.