Mission Planner Crashes Scanning Bluetooth COM Ports

[StephenCarlson]

OS: Windows 10
Mission Planner Version: 1.3.83

Description:
I just updated from 1.3.77 to 1.3.83 on Windows 10. The way that the new version is parsing COM ports is causing the application to crash and exit after a few seconds. Specifically, I have a TPLink Bluetooth 5.0 adapter that I typically have plugged into my workstation, and this did not cause any issues with the previous version, but in 1.3.83, this device being present on the system during program startup is causing it to crash. Mission Planner starts up correctly if the device is removed prior to starting. When I plug the device back in, the program is fine, but the moment I click the drop-down menu for the ports, the crash occurs.

The screenshot attached shows the banner pulled down in the moment before the program crashes.

Also attached here is a screenshot of the device tree after the adapter is plugged in, the naming isn't unusual?

I used Gemini AI to chew on the log file that is generated in C:\ProgramData\Mission Planner, and the following a snippet of what it thinks is the issue:

The issue you encountered is a well-documented (though rare) behavior in .NET applications on Windows where the Serial Port Enumeration logic hangs or crashes when interacting with specific Bluetooth driver stacks.

What is happening in the code?
Mission Planner populates the COM port dropdown in the top-right corner immediately upon loading the main interface. To do this, it scans the Windows registry and WMI (Windows Management Instrumentation) to find every active serial device.

• The Culprit: The System.IO.Ports.SerialPort.GetPortNames() method (and the associated WMI queries) can "block" indefinitely if a Bluetooth driver is in a "hanging" state or responding slowly.

• The Crash: When this call hangs the main UI thread for too long, or if the driver returns a malformed string that the regex parser doesn't expect, the application either hits a timeout it can't recover from or throws an unhandled exception in a background thread that brings down the process.

Which file is to blame?
In the Mission Planner repository, the logic responsible for this is primarily located in:

1. MainV2.cs: Specifically within the methods that initialize the cmbComPort (the COM port selection box). Look for where it calls GetPortNames or its own internal serial utility.

2. MissionPlanner.Comms (Namespace): This is where the custom wrappers for serial communication live.

3. Program.cs: The log you provided showed the crash occurring around line 546. While that specific line is usually part of a "Type Resolver" debug handler (which is why you see the TypeResolve Failed noise), it confirms that the application is still in its heavy initialization phase.

...

The MissionPlanner.log shows the last entries are TypeResolve Failed debugging lines in Program.cs.

The hang likely occurs during the population of the COM port dropdown menu (cmbComPort in MainV2.cs).

Suspected cause: A blocking call to System.IO.Ports.SerialPort.GetPortNames() or a WMI query (SELECT * FROM Win32_PnPEntity) that is stalling on the Bluetooth driver stack.

It would nice if I didn't have to constantly unplug and replug the Bluetooth adapter, and this is a critical issue if users are trying to use the Bluetooth device as a COM port. I hope this can be fixed. Thank you.

[StephenCarlson]

A quick addendum: The program crashes regardless of the Enabled/Disabled state of the Bluetooth COM ports, such as this condition:

It also crashes even when the Bluetooth COM ports are Uninstalled from the Device Manager.

I also tried removing the adapter, opening Mission Planner, and reattaching the adapter and then disabling both the Bluetooth COM devices, and it still crashes when the port drop-down is clicked. Crash also happens when the Bluetooth COM devices are uninstalled and then clicking the drop-down.

I've also tried leaving the COM port selection on a stable port, such as COM1; the selection is preserved between launches of Mission Planner, but the crash still happens if the Bluetooth adapter is present on launch.

I've tried updating the Bluetooth COM Serial drivers, but these are up-to-date.

I've also tried disabling just one of the pair. I'm not entirely sure why the adapter asserts two identical Bluetooth Serial COM devices, is the duplication of the same name causing this? And again, why did the four-year-old 1.3.77 version of the program tolerate this just fine for years, but this version cannot handle it?

[StephenCarlson]

This may be related to a commit several months ago where this Bluetooth bug is addressed for Non-Windows systems: 68904b2 . A bunch of changes to ExtLibs/Comms/CommsSerialPort.cs which, while likely fixing the issue outside of Win10, might be the reason why it occurring now within Win10? @meee1 the link on line 395 is stale/broken (http://connect.microsoft.com/VisualStudio/feedback/details/236183/system-io-ports-serialport-getportnames-error-with-bluetooth) , closest similar thread: (https://learn.microsoft.com/en-us/answers/questions/4325925/bluetooth-virtual-com-port-names-corrupt-when-retu)

[StephenCarlson]

I uninstalled 1.3.83 and have installed 1.3.82, and the issue does not exist; no instant crash with Bluetooth adapter plugged in, nor any crash when the COM port list is populated after plugging it in. I'll be sticking with 1.3.82 until the issue is resolved?

Image from 1.3.82 of the port being parsed correctly:

[StephenCarlson]

Its been two weeks, is this going to be addressed? Is there a known work-around?