Solved: Can’t connect to high (>10) Windows COM ports / cleaning out unused COM ports

Problem: Windows, and many Windows apps that use serial (COM) ports, have various problems accessing “high” numbered COM ports. I cannot find an authoritative or quantatative definition of “high” (and it may depend on your app), but I have seen apps start failing after COM8, COM9, COM15… anything in the 20s is asking for trouble. If you are a developer and routinely plug in different “serial” devices (including USB gadgets with virtual COM support, Bluetooth dongles, Arduinos etc.) Windows will happily assign a new port number to each one until something breaks and you go hunting for this post.

Depending on the application, the “s**t-the-bed” breakover often depends on a hardcoded number (e.g. only supports up to COM8), or going to double digits, etc.

Solution1: Some apps may let you enter the COM port number in a special way (UNC path) that lets higher-number COM ports be used, e.g: \\.\COM25
(that is, precede the port name with a double backslash, dot, and then another backslash). If the app uses backslashes as an escape character, try doubling the backslashes, e.g. \\\\.\\COM37

Why this form? Why only some applications? Why does the number where this form becomes necessary differ between applications? (avrdude.exe requires it for COM10 and higher; pyserial will work without it up to at least COM15 or so, but not COM25. Of course, this all may just depend on the phase of the moon and your results may vary.) Beats the hell outta me. If anyone knows what this is all about, please post in the comments!

Solution2: Clean out those rusty, dusty old unused COM port numbers (you know, for that silly dongle you plugged in exactly once years ago and never touched again) so you can recover those “working” low COM port numbers for new devices. Trouble is Windows will not show it in Device Manager unless the device is plugged in, which is a problem if the thing got lost or broke long ago. To see the hidden allocations and remove them:

1. Open a command prompt as Administrator. (Start->Run, type cmd ). Or, right-click Start->Programs->Accessories->Command Prompt and choose “Run as administrator”

2. At the command prompt type set devmgr_show_nonpresent_devices=1

3. At the command prompt type start devmgmt.msc to start Device Manager. For this to work you MUST start it from this command prompt – don’t mouseclick your way into it or try to use an already open copy.

4. When device manager opens, select View -> Show hidden devices

Now when you expand the COM ports section, every COM port ever allocated will be shown (all the ones for nonexistent devices will be grayed out). Now you can right-click all the defunct ones and uninstall them.

NOTE: Without the magic incantations above, you will still have a View -> Show hidden devices option, but it won’t actually show the nonexistent COM port eating devices.

Tags: , , , , , ,

3 Responses to “Solved: Can’t connect to high (>10) Windows COM ports / cleaning out unused COM ports”

  1. NewWorld says:

    In PySerial in needs to be prefixed with “\\.\” I think.

  2. M.J. says:

    It’s always “\\.\”!

    This article is wrong and for some reason it’s the second result if you google for “windows double digit com port”.
    The first hit is a Microsoft page, and it clearly states that double digit ports are prefixed as “\\.\COM10”.

  3. Tim says:

    Wrong how exactly? I’ll take this article over the Microsoft reference you cited any day. This reference applies specifically to the CreateFile() method in the Win32 API. While it does mention the same UNC path approach (“\\.\”) as I mention above, it claims specifically that ‘COM10’ and higher will always fail with a specific error code (false), and does not explain why double-digit port names “usually work” in practice, but suddenly start failing at some randomly-generated number, or how or why that number varies (today, I had to re-read this post because PySerial could open ‘COM41’ but not after I plugcycled the Bluetooth dongle it was associated with and it became ‘COM43’).

    Also, note that many applications do not let you just type in arbitrary strings (UNC-like paths or otherwise) for the serial port name, and instead have you choose from a pre-populated dropdown list. Clearing out unused ports to bring them down to single digits (or ‘working’ arbitrarily lower numbers) is an effective workaround, both for app developers misusing the CreateFile() API and for the probably-unrelated and still-unsolved issue that causes them to fail at COM22, COM43 or other dice-roll number.

Leave a Reply