Been there, tried that :)

The trouble with test-opening each port is that there might be some unusual ports in the system, eg. BlueTooth / GPS, USB-to-Serial converters, Serial-over-Ethernet and forwarded serial ports in a virtual PC, some of them hanging the application for several seconds when you open them.

Your best bet is to enumerate the registry keys under HKLM\HARDWARE\DEVICEMAP\SERIALCOMM. It's not officially documented, but the .NET Framework 2.0 has a method that returns the available serial ports in the system which does exactly that.

-Markus-

Quote:Original post by Antheus
In my experience (even under Linux), assuming anything about serial ports will crash, hang, dead-lock or mess up the system badly.

For anything port related, I don't try to be smart in any way whatsoever. Let user enter the exact information - if it's wrong, it's their fault.

COM ports are bad and unreliable enough when using supported drivers with correct settings.

If you do use some automated enumeration, I'd strongly suggest against automatically probing anything.

I work on a program at work that enumerates the ports and then probes them in turn. After a few years of no reported problems with this, we only found a problem about a month ago where bluetooth COM ports would lockup the program for a very long period of time.
It worked just fine with USB to serial devices of a number of different kinds.
The problem is though that there isn't any reliable way to determine if a port is a non-bluetooth port before opening the port.

COM port numbers actually go all the way up to 256 btw!

So my advice is that you can enumerate them as Cygon explains no worries. However, only use that to populate some list for the user to select from.
At the absolute most, provide a search button that probes ports as a last resort if you must, but don't ever do the probing without being asked to!