USB-to-Serial COM Ports on Windows: Driver and Port Drift

The same adapter can become COM3 at one desk and COM7 at another. Understanding port assignment saves repeated reconfiguration.

USB-to-serial adapters are how most modern laptops talk to serial equipment, but Windows assigns COM port numbers by the physical USB port and the adapter's identity, not by the device on the other end of the cable.

This article explains why a COM number drifts between workstations or even between USB sockets on the same machine, and how to keep your terminal sessions pointing at the right port.

How Windows assigns COM numbers

When you plug in an adapter, Windows records a binding between that adapter (identified by its USB vendor and product IDs, plus a serial number if present) and the physical port it was plugged into. The next time it sees the same combination, it reuses the COM number.

Plug the same adapter into a different USB socket, or a different adapter into the same socket, and Windows may treat it as a new device and hand out a fresh COM number. Over time a single laptop can accumulate COM3, COM4, COM7, and more for what is logically one cable.

Driver and chip families

Most adapters are built around a handful of chip families. FTDI and CP210x parts are common in branded adapters, while CH340 appears widely in low-cost modules. Each needs its own driver, and Windows may load a generic one that works for basic traffic but behaves differently on unexpected unplug events.

A driver that fails to install or that Windows replaces on update is a frequent source of 'the port disappeared'. Confirming the adapter shows up without a warning icon in the device list is the first check when a session will not open.

• FTDI. Common in professional adapters; stable driver, configurable VID/PID.
• CP210x. Silicon Labs family, widely used, simple driver model.
• CH340. Low-cost modules; driver needed and sometimes blocked by signature enforcement.

Reclaiming a drifting port

If a port number keeps climbing, you can reassign it: open the device properties for the adapter and set a preferred COM number that is free. This does not stop Windows from creating new bindings for new physical ports, but it keeps a known adapter on a known number.

For bench setups with several adapters, labeling each cable with its COM number avoids the daily hunt through the port list. The label is only valid for the socket you trained it on, so note that too.

Handling unexpected unplug

Pulling an adapter mid-session can leave the terminal holding a handle to a vanished port. A clean close before unplugging, or reopening the session after replug, avoids the stuck-port state where the software thinks the port is busy.

Some adapters also need a moment after replug before the driver re-enumerates. Opening the session immediately can fail even though the hardware is fine a second later.

A stable workflow

The practical routine is: dedicate a USB socket per adapter, label the cable with its COM number, save a terminal profile that names the device rather than the port, and verify the device list before a critical session.

When you must move between sites, expect the COM number to differ and treat 'find the port' as a normal first step rather than a failure. The device on the wire has not changed; only Windows' view of the adapter has.

If the laptop only offers USB 3.0 ports, prefer a 2.0 hub or a 2.0 socket for adapters that misbehave at higher speeds, and keep the adapter firmware current. A flaky enumeration that 'works after a few replugs' is a setup problem, not a device fault, and it disappears once the port and driver are stable.

With the port stable, open it in the Windows serial terminal, fix any data-format mismatch, and put the adapter to work on a board serial console.

Common questions

Why did my COM port number change?

Windows binds a COM number to the combination of adapter identity and physical USB socket. Moving the adapter to another socket, or using a different adapter, can yield a new number.

Do I need a specific driver for my adapter?

Yes, each chip family needs its driver. FTDI, CP210x, and CH340 adapters each rely on their own driver, and a missing or replaced driver is a common reason a port will not open.

Can I force a fixed COM number?

You can set a preferred COM number in the adapter's device properties if it is free. This keeps a known adapter stable but does not stop Windows from creating new bindings for new sockets or adapters.

Why does the port vanish after unplugging?

An unclean unplug can leave the terminal holding a handle to a gone port, or the driver may need a moment to re-enumerate after replug. Close the session first, then reopen after the device list settles.

Is CH340 unreliable compared with FTDI?

They serve different price points. CH340 modules are common and functional, but driver signature settings and cheaper cabling can cause setup friction. The choice is a cost and convenience trade, not a reliability verdict on the protocol.

Keep reading