Develop Reference

ArgumentException: The given port name does not start with COM/com or does not resolve to a valid serial port

I am trying to connect to a virtual com port provided by the drivers of a u-blox GPS device.
The device appears normally under the Sensors tab in Device Manager and I can really get the coordinate data using GeoCoordinateWatcher class from C#.
But I want to read the underlying NMEA data.
So in the process of doing that I installed the Virtual Com Port driver provided by U-BLOX and it generated a u-blox virta com port in devices manager.
Connecting to that using Putty is OK and I can see all the NMEA lines being dumped there.
but when I try to connect to the same port (after Putty is closed obviously) using C# I get the exception mentioned in the title
The given port name does not start with COM/com or does not resolve to
a valid serial port
My code is fairly simple (not the first time I use com ports) and everything is correctly defined (Port Name, Stop Bits, Parity, BaudRate etc). I even tried changing to a "wrong" com port name to see the exception I will get and it is completely different (Com Port does not a exit exception).
So what is happening with C# at this point? Am I doing something wrong? Is this a bug in the SerialPort class? Putty seems to work just fine in connecting and streaming the data.
My code is as simple as the following
m_port = new SerialPort
{
PortName = m_portName,
BaudRate = m_baudRate,
Parity = m_parityBit,
DataBits = m_dataBits,
StopBits = m_stopBit
};
m_port.Open();
I even tried hardcoding the values and I still get the same exception.
I tried many of the suggested solutions found here, none of them helped.
I also tried changing the COM port number from Device Manager advanced settings, that also did not help

As it turns out U-BLOX virtual COM port driver does not fully emulate a COM port which causes issues with .Net. Regardless if it is C# or C++ or any other language running on .Net
The only solution is to either, not use this device, or use an intermediary software.

If you don't have any particular reason for using the VCP driver, use the CDC driver instead. Available as "u-blox GNSS Standard Driver for Windows" at their website:
https://www.u-blox.com/en/product-resources/2673The/field_file_category/driver-221/field_file_products%253Afield_product_category/position-time-152
I had the same problem as you, but by changing the device driver, everything works as expected. It seems like their VCP driver is not fully compatible with the regular serial port driver structure.

I managed to resolve this issue, and thought I'd share my solution.
I wasn't able to use the CDC driver, as my device is a Rugged Windows Device with a dedicated GPS - the CDC solution may only work for removable gps devices via USB. The sensor driver must be installed, and the VCP driver can be installed alongside the sensor to provide a COM port.
Whilst the VCP driver does not fully emulate a COM port, you can use another piece of software to fully emulate the uBlox virtual com port and fill in the gaps. GPS Gate was that software for me - https://gpsgate.com/. The end result is uBlox Sensor -> uBlox VCP -> GPS Gate VCP. I was then able to successfully use the GPS Gate VCP in my C# app, and have GPS data coming down.
GPS Gate also offers a Location API plugin which could remove the uBlox VCP from the equation (uBlox Sensor -> GPS Gate VCP through Location API), but I didn't have much luck with it, plus I already had a working solution.

Bluetooth COM Port Exceptions in C#.Net

I am using Windows7 with 32feet.net libraries for the windows application development. I get the COM ports after I scan and pair the device. When I open the port and try to send the data in the COM port, I am getting two types of exceptions and they are given below
Error Code Exception
121 The semaphore timeout has expired
1168 Element not found.
I also tried with a workaround given in the below link,
http://zachsaw.blogspot.in/2010/07/serialport-ioexception-workaround-in-c.html
but nothing fruitful.
Lastly my suspicion revolves around the Bluetooth driver.
Any insights on how to find an approach for this exceptions.
Regards,
Gibson

I had simular issue with this. My issue was resolved with .net 4.7.1. Also I needed to make sure I had the latest microsoft bluetooth driver for the bluetooth device i was using
SerialPort streams no longer terminate the process when exceptions occur on the background thread. This can happen when removing a USB serial port while in use. This new behavior is controlled by the Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions AppContext switch. This switch is set to truetf get by default when targeting .NET 4.7 or below. [428461, System.dll, Bug]
https://github.com/Microsoft/dotnet/blob/0745983093568027ff931672d9db021e3e120b5b/releases/net471/dotnet471-changes.md
Update: Actually it appears to be 2 issues in one. .net bug and a firmware issue where the device was never turning back on the bluetooth module.

I used a RN-42 chip for Bluetooth operations and studied few things from the below link,
https://electronics.stackexchange.com/questions/38113/does-bluetooth-range-increase-with-lower-baud-rate
The culprit was the baud rate!!!!
I tried using the standard baud rate of 9600 but surprisingly some data transfers were proved to be successful, alas the COM port got disconnected despite the Bluetooth device state being connected to the windows application. During this state, the application threw exceptions after few data transfers like "Element not found" and " The semaphore timeout period has expired". Changing the baud rate suggested by the manufacturer seems to be more stable. Workaround : Align to the same baud rate in the windows application and the Bluetooth device.

USB-Serial adapter : Serial device receives no power when running msdn example

I am trying to read data from a serial device. It has an LED that turns on when I connect it to an actual serial port (on an old XP machine).
On my target machine however, I need to use a USB-serial adapter, and the LED does not turn on when connecting it.
It does turn on when I open the serial port with Putty or Hyperterminal though.
Now I have been trying to read it in my .Net project, and in order to do that, i run the example code from the MSDN documentation here :
https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readline%28v=vs.110%29.aspx
when I do, nothing gets read from the port, and the LED does not even turn on. I would expect it to turn on whenever I hit the
_serialPort.Open();
but it does not.
Is there a specific step, or configuration, or workaound, to ensure the serial port receives power when using USB adapters?
My serial device is a GlobalCaché GC-IRE.
The USB adapters I have been testing: 3 different ones, two no-names and one TrendNet TU-S9.

C#.NET Serial port access from web application

I have a C#.NET web app that runs in IIS 7 on Server 2008 R2, .NET v4, MVC 3, SQL Server 2012. The app works on a bunch of machines already, but we've just got a new computer and the behaviour on this machine is slightly different.
In particular, when the app opens the System.IO.Ports.SerialPort and writes, no data is actually transmitted on COM1. No exception seems to be thrown either. The app goes on to wait for a response, and times out.
If I close my app, and use Termite (a terminal program) to check that the COM port is working, data comes out the serial port just fine. So the serial port, drivers, etc seem to be ok.
If I have Termite connected to COM1 when my app tries to open the port, I get an Access Denied exception (as I expect). So my application does seem to be trying to access the correct port.
But if there's nothing else using COM1, my application gets no exceptions - but nothing comes out the serial port.
Does anyone have any suggestions about how to debug this situation?

I had the same problem - C# SerialPort couldn't connect to my serial device but Termite could despite following the device manual.
I compared the SerialPort properties with my Termite settings and found that there's some terminology difference between the two. For example, Termite has an option for "DTR/DTS" (which I needed) while SerialPort doesn't have anything called "DTS". Setting these properties of the SerialPort object worked for me:
DtrEnable = true;
RtsEnable = true;

SerialPort.GetPortNames() behavior

In my C# 2008 application, I use the SerialPort.GetPortNames() function to retrieve the list of currently available ports. What I have noticed is, when ever I plug in a USB device, it's port number i s shown in the list on my Application and when I unplug it and refresh the list, the port number is no longer there.
One phase of the application involves reading/writing data from/to the device continuously. Now, my expectation is, If I unplug the device during the operation and get the current Port list using SerialPort.GetPortNames(), the Port Name will not be there and I can use that to make the decision that the device has been unplugged.
To my surprise, the Port name is still found despite having it removed
Why is the program behaving like this? The port name isn't listed when in no-communication mode. Does it have something to do with the device being removed when it's communicating?

You have to be talking about SerialPort.GetPortNames(), "GetPortList" doesn't make sense. The function iterates values in the registry, written there by your USB emulator device driver. You can have a look-see with Regedit.exe, navigate to HKLM\Hardware\DeviceMap\SerialComm. Unplug it, press F5, if the COM port is still there then SerialPort doesn't know any better than the port still being present.
There is no prescribed behavior as to how a serial port device driver should behave when the port suddenly vanishes. Serial ports are very primitive, they date back to an era where "bug" meant a moth gumming up the teletype. There is no hardware support at all for Plug and Play, removing a port with the power turned on is equivalent to unplugging the disk drive while Windows is swapping to the paging file.
Most device drivers return an error code, it generates an uncatchable exception that crashes your program. The subject of this feedback article. Apparently your device driver doesn't do that, which ought to be preferable over bombing your program. Encouraging btw, most USB emulator device drivers are utter junk.
The ultimate workaround is simple: put a little tag on the plug "don't disconnect while in use!" It's kinda of a problem with USB, most people look at it and go "hmm, what can I do with it?". And arrive at the only answer and unplug it. After a couple of kabooms, they'll learn to not do that anymore.

I'm assuming you mean System.IO.Ports.SerialPort.GetPortNames(), because i could not find a GetPortList() function anywhere. MSDN says: "If the registry contains stale or otherwise incorrect data then the GetPortNames method will return incorrect data", so that's probably where the problem lies. I guess Windows doesn't update the registry if the port is still being 'used', just like you can't delete a file when a program has a handle on it.
If you want to test if the device is removed, you can do so with a Window API call (http://www.pinvoke.net/default.aspx/user32/RegisterDeviceNotification.html). Hope that helps!

It is correct that GetPortNames() reads the ports from the Registry key
HKLM\Hardware\DeviceMap\SerialComm
This is automagically updated by Windows every time a port is opened or closed.
But nevertheless it has happened to me that there is a non-existent Port listed in the Registry, and also returned from GetPortNames(). When I try to open this port I get "The Port XYZ does not exist".
What is that ???
I now found out the reason:
This happens always after using PortMon from www.sysinternals.com.
This tool is buggy and lets the dead port hanging around in the Registry if the port is closed while it is monitored.
In this case the only remedy is to reboot the computer.

As others have mentioned, it's very driver-specific. There does not appear to be a way to check with the .Net API whether a port returned by GetPortNames() actually exists and is valid.
As for why the ports behave like this, I have found that some USB-to-serial drivers cause the application to crash when the port is unplugged suddenly.
Other drivers, often those that do not crash, will keep the port in the list until your application closes it, then it disappears. Trying to read from or write to the stale port will (usually) cause timeouts or errors. Presumably, in order not to crash the application, the driver needs to keep the stale port around while it is still open in the application.
If you plug in the port again, some drivers are even be able to reconnect it to your application, others will not recognize the port until your application closes the stale port. This reconnecting behaviour can be somewhat dangerous if the port disappeared because the device rebooted, because then it will suddenly be in a different state than your application expects without an obvious indication that it has reset. At least if you get errors from the port you know that something happened.
I've also found that if I forget to close the port, it won't disappear from the list until the garbage collector gets around to disposing the SerialPort object.