runtime: On Windows ARM64, serial ports are not found by SerialPort class

@PRIMETSS thank you - glad you got it to work! I have reviewed your commit and added some comments. Major comment is to not add a new API and re-use existing one instead and besides that there are couple of minor comments/nits. I think the approach looks reasonable overall (first of all it seems to work for you while current one doesn’t)

Also you can go ahead and open draft PR when you’re not sure about approach/solution

Guys I think I have something worth sharing, not sure if you want to have a look before doing a PR?

Basically after a few days of exploring about 2/3 options before hitting issues. I believe Ive got a way of connecting to USB Serial ports that are not being correctly setup a COM(x) in Reg: HKLM\HARDWARE\DEVICEMAP\SERIALCOMM

Just got to finish up how to handle duplicate ports on Win devices that do. I think its a ok solution. Had to add a bit of interop and made a few changes to how GetPortNames() works and also how SerialStreams opens ports. Ive got it working on a Win10IoT PI with a ‘faulty/missing’ reporting COM port and also a Win10 Desktop that assigns COM4 using the same USB UART device.

In a test App its reporting & opening the ports on both devices and its receiving data via the .DataReceived ok! Would appreciate someone reviewing it, and make some recommendations, as first time I’ve contributed to the corefx Repo and took awhile to get set up & get head around it all, so might have some interpretation issues!

Thanks

Edited:

Link to commit below for comment: https://github.com/PRIMETSS/corefx/commit/f7368d696304c9a7abd3cbb45dad85857f693a01

I had no idea Serial ports are such a convoluted device! https://docs.microsoft.com/en-us/previous-versions//ff546502(v%3Dvs.85)

Further to this, I was able to compile BUSTOOLS/MinCom for ARM and was able to connect to device via GUID

MinCom uses Win32 (confimgr.dll) interop API to communicate with Serial devices https://docs.microsoft.com/en-gb/windows/win32/api/cfgmgr32/

https://github.com/microsoft/Windows-iotcore-samples/blob/develop/Samples/EdgeModules/SerialWin32/CS/Win32Serial.Device.cs

So seems there is more to how Win10IoT Core handles PnP Serial ports when discovered and first initialised in the OS. Anyone got any more thoughts as to why this seems so complex/messy & difficult?

It seems need to go back to Win32 API’s for Serial ports in Win10IOT core as it seems to skip some parts of the legacy serial port initialisation that SerialPort class is relying on ?

Hit this problem today and spent a bit of time on it and here are some quick info I found that might help? Really want to see this resolved, as like someone has mentioned before, COM port #'s can change when devices are hot swapped, so with no real way of enumerating COMPort # it will cause some issue using Serial Devices.

Environment:
Raspberry 3B+, Windows 10 IoT Build 10.0.17763.615
OS version 32Bit via (wmic os get OSArchitecture)

Needed to get COM port # of a USB LORA radio module that emulates a Serial Port. Using .Net Core 3 console app found that SerialPort.GetPortNames() returned what appears to be unicode chars

Using SSH to connect to the Pi, so not just a PowerSell display characters issue. Ive read that it is only 64Bit with this issue?, But pretty sure Im using 32 bit WinIoT10Core (below) From results I saw today, Im not convinced that its a problem with System.IO.Ports at all ?? and maybe a issue with PnP updating the Registry when COM port devices are discovered? As the Registry Key Value seems corrupt. Is it something the Win10 team might have more info? As if the registry is gobbly gook, and SerialPort.GetPortNames() is using that to get PortNames, then its got little chance?

Just for notes on how I did setup:

> Started Windows Rermote Management Service on workstation
 net start winrm
> Trusted Win10IoT host
Set-Item WSMan:\localhost\Client\TrustedHosts -Value <IoTHostName of IoT Device>
> Start PowerShell Session with IoT Device
Enter-PSSession -ComputerName <IoTHost Name> -Credential <IoTHostName>\administrator
> Determine OS Bit Architecture
(wmic os get OSArchitecture)
> Read HKLM\HARDWARE\DEVICEMAP\SERIALCOMM Key
reg query HKLM\HARDWARE\DEVICEMAP\SERIALCOMM

Result :

On Win10 Desktop, same device

Further comparing Registry with Working Desktop & Pi, found this Key missing any values, not sure if related, but on Desktop is seems to map the COMX name with Hardware ID “\?\usb#vid_1b4f&pid_214f&mi_00#6&381731fd&0&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}”

Trying to SerialPort.OPEN(PortName) COM1 through COM5, “Port Does not Exist” Exception.

@Chirishman I haven’t had time yet to look into this yet and ARM64 hasn’t been our focus yet.

I presume your code is running on Windows, right?

If you have some time for debugging here is the code we use: https://github.com/dotnet/corefx/blob/master/src/System.IO.Ports/src/System/IO/Ports/SerialPort.Win32.cs

the garbled text (which I’ve seen in the other issue) suggests this might be a Windows bug or Registry not working correctly on ARM64.

What might be useful is if you open registry and see if you can see your port under HKLM\HARDWARE\DEVICEMAP\SERIALCOMM (https://github.com/dotnet/corefx/blob/master/src/System.IO.Ports/src/System/IO/Ports/SerialPort.Win32.cs#L21)

if you can, next step would be to check if .NET APIs work correctly with registry.

If you cannot see ports at all it might be worth trying to call APIs mentioned in the comment in that file.

since this is just discovering ports and AFAIK using them still works as long as you know the port name, moving this to Future. Please let me know if this something we should address sooner (AFAIK also arm64 was not on 3.0 roadmap but if anything changed there please let me know)