Why Does My FTDI COM Port Report Busy When No Other Device Is Connected? A Driver-Level Teardown

A busy FTDI COM port with nothing visible attached almost always means the port is still claimed by something other than a user-facing device: a ghost handle left by a crashed program, a Windows registry entry that survived an unplug, a second driver bound to the same chip, or a pending I/O operation that has not timed out. The adapter can be physically gone while the operating system still believes it is in use. The job is to find which layer is holding the claim, not to reinstall drivers at random.

This explainer goes deeper than the typical walkthrough because the busy state is an operating-system bookkeeping artifact, not a hardware fault. Once you understand how COM ports are enumerated, claimed, and released, the fix usually follows from a single diagnostic check.

What busy actually means at the kernel layer

A COM port is a named device object, not a wire. In Windows, the serial port appears as a device interface managed by the serial port class driver, with an FTDI function driver translating USB transfers into UART-like reads and writes. When a program opens the port, the I/O manager creates a file object handle associated with that device. The busy error is generated when a second open request arrives and the first handle has not released exclusive access. The port does not need a cable or a sensor to be busy; it only needs one outstanding handle or one pending operation.

The FTDI driver itself can enforce exclusivity in two places. The first is the standard Windows sharing model: a program may request exclusive access, and any subsequent open fails. The second is the FTDI vendor driver's own device-level arbitration, which can hold the interface open while a transfer is queued. That is why a port with no data flowing can still refuse a new connection. The outstanding request occupies the interface even though the chip has nothing to say.

There is a deeper mechanism worth naming. USB transfers are asynchronous. When an application issues a read, the driver posts a bulk-in request to the host controller and waits. If the application stops responding but the request remains queued, the host controller keeps that transfer outstanding until it completes or is canceled. The COM port therefore reports busy because the system is waiting on a transfer that will never finish on its own. A hung process that never called CloseHandle leaves exactly this residue.

Quantified context: how long a ghost claim survives

Ghost claims are not permanent, but their lifetimes vary by cause and are longer than most users expect. The following timeline reflects typical Windows behavior for common causes; exact values depend on driver version and USB stack configuration.

The 30-second to 5-minute band is the one that surprises people. A hung read can sit in the USB stack far longer than the visual disconnect suggests, because the cancellation path depends on the host controller and driver cooperation. On some systems a stuck transfer survives until the process that owns it is force-terminated or the machine reboots.

Edge cases that produce a busy port with nothing attached

Not every ghost claim comes from a crashed terminal program. Several legitimate configurations leave a port claimed without any obvious device.

A serial-port service, such as a telemetry agent or a background logger, started automatically and is holding the handle. Two FTDI drivers coexisting, for example the vendor VCP driver and a generic CDC driver bound to the same interface. A Bluetooth serial profile or a virtual COM port that has inherited the same COM number. A USB hub or docking station that has not completed enumeration, keeping the interface in a pending state. A remote-desktop or virtualization session that has redirected the COM port into another machine. A prior "safe remove" that removed the hardware but left the software device node visible.

Each of these produces the same symptom but requires a different diagnostic. Treating them all as a driver corruption problem wastes time and can make the ghost claim worse.

Misconceptions that send people down the wrong path

The most common misconception is that the busy state indicates a hardware fault. In reality, an unplugged or failed chip cannot hold the port open; the operating system must be holding the claim. A second misconception is that reinstalling the driver clears the ghost handle. It rarely does, because the handle belongs to a process, not to the driver package. Uninstalling and reinstalling can leave the pending operation untouched while adding a fresh device node.

A third misconception is that COM port numbers are unique per device. Windows assigns COM numbers by enumeration order and stores them in the registry, so a removed device can leave a reserved number that a new device inherits. This is why the busy message sometimes appears on a port you never opened. The number was claimed before you plugged anything in.

A professional caveat worth stating plainly: the single most reliable indicator of a ghost handle is that Device Manager shows the port present while no application you can see has it open. If the device node disappears on rescan, the claim is likely a stale registry reservation rather than a live process. Distinguishing these two cases before acting saves most of the debugging time.

Practical actions to release the claim

Work from the cheapest diagnostic to the most disruptive. The order matters because each step tells you which layer is holding the port.

Open Device Manager, enable View > Show hidden devices, and check for the FTDI device under Ports and Universal Serial Bus controllers. A greyed entry indicates a stale node. Use a handle-listing tool such as Process Explorer or the built-in handle search to find which process holds the COM port. Terminate only after confirming the process is not a legitimate service. Close every terminal, IDE, and background agent, then rescan for hardware changes to force re-enumeration. If the port number itself is reserved, change it in Device Manager > Port Settings > Advanced, assigning an unused number between COM1 and COM256. Disconnect the adapter, wait at least 30 seconds, and reconnect to allow the pending transfer to cancel cleanly. As a last resort, reboot; this is the only step that clears a pending bulk transfer not canceled by the driver.

The threshold to watch is the 30-second wait. Shortening it defeats the purpose because the cancellation routine has not run. If the port remains busy after a full reboot and before any application starts, the claim is coming from an auto-start service rather than a crashed program.

Why the hardware cannot be the cause

A defective FTDI chip fails in the opposite direction. It drops off the bus, generates enumeration errors, or produces framing errors during transfer. A dead chip cannot synthesize a busy response because the busy response requires an active driver-created device object. This is the counterintuitive detail: the failure mode you are seeing is proof that the software stack is alive and the hardware question is secondary.

This does not mean hardware is irrelevant. A marginal USB cable or a hub that intermittently drops the device can produce repeated enumeration and partially torn-down handles. In that case you may see the port appear, report busy, and vanish in cycles. The pattern is different from a single stuck handle, and it points to cabling or port power rather than software. If the busy state recurs every few minutes, check cable seating and hub power before touching registry settings.

Limitations: what this diagnosis cannot tell you

Driver-level diagnosis cannot confirm whether a hidden process is malicious, only that it holds a handle. Nor can it predict how long a pending transfer will take to cancel on a specific host controller, since that depends on firmware and chipset. The registry reservation behavior also differs between Windows versions, so port-number advice should be verified against your build.

Avoid "fixes" that promise a universal clean. Deleting registry keys for COM ports can orphan other devices, and third-party driver cleaners can remove the vendor driver you actually need. The safer path is to identify the claiming process first and only edit device settings when the software check comes back clean. For any deployment where the FTDI adapter is part of a safety or control system, resolve the busy state through your organization's change-control process rather than ad hoc tinkering.