C# – SerialPort.GetPortNames() returns incorrect port names

While c# is not my primary programming language, I'm maintaining such a program for a couple of years now. This program connects to a device on a serial port and works from Windows XP up to 8.1. One specific "feature" is that it uses .NET Framework 2.0.

With some users upgrading to Windows 10 we've got complains that the program cannot detect/open the COM port of the device. We have confirmed this on our own test systems with clean Win10 installation.

It turns out that the function SerialPort.GetPortNames() returns incorrect port names and adds 'strange' characters after the port name.
For example:

• COM3吀
• COM3䡢
• COM3゠

Etc. When I refresh the list, every time another character (or two) shows up after the number.
The test code is super straightforward:

  string[] portNames = System.IO.Ports.SerialPort.GetPortNames();
  log("Available ports:");
  foreach (string PortAvailable in portNames)
  {
    log(PortAvailable);
  }

Where the log function mearly adds a line to a standard TextBox on the form:

  txtLog.Text += Msg + Environment.NewLine;

This works in every other Windows version.
I've checked the registry and all looks fine there also.
Does anybody has an idea about this?

I'm suspecting that .NET Framework 2.0 is not 100% compatible anymore, although you can enable it in the Windows features and it seems that the program itself runs fine (besides my serial port problem). I'm a bit scared to upgrade to a newer .NET, let alone that we've VisualStudio 2008 for c# (max=.NET 3.5). Note that the program still needs to run on Windows XP also (POS version is still maintained by Microsoft).

ADDED:
I've "upgraded" a test program to .NET 3.5, and still having exactly the same issue.
Next step is to install a new VisualStudio (it appears that it is free nowadays?? Should I check for privacy settings in Studio also? ;-).

ADDED 2:
Installed VisualStudio 2015 and made multiple builds with different .NET framework versions. v2.0 and 3.5 still adding the strange character. But in v4.0 and up this issue seems te be solved! Now to get the original program compiled and working for the newer Framework.
But I find this issue really strange and would expect that this would hit more .NET functions and more programs.