2026-06-02

USB Serial COM Port Disappears: Debugging Re-enumeration, Driver Binding, Port Numbers, and CDC Bridges

How to troubleshoot USB serial COM ports disappearing, changing numbers, re-enumerating, CDC ACM bridge resets, driver binding failures, and applications that keep stale handles.

USB serial devices are everywhere: Arduino boards, industrial controllers, modems, GPS receivers, test fixtures, debug probes, PLC tools, barcode devices, and custom CDC ACM firmware. When the COM port disappears, the application usually reports only that it cannot open the port. Bus Scope is useful because a missing COM port can be caused by very different layers: USB enumeration, descriptor problems, driver binding, device reset, stale application handle, line-coding request failure, or Windows assigning a new COM number.

Direct answer: first determine whether the USB device disappeared or only the COM-port abstraction changed. Capture from plug-in through application open, verify descriptors and configuration, inspect CDC class requests, then look for reset/disconnect/re-enumeration. Compare VID/PID, serial string, interface identity, physical path, and assigned device address before and after. If USB is healthy but the app still opens the old port, the fix belongs to OS/application device discovery rather than the bus.

COM port is not the USB device

The COM port is an operating-system abstraction created after the USB device enumerates and the serial driver binds. If the USB device never enumerates, no COM port can appear. If the USB device enumerates but the CDC interface fails, the COM port may still be missing.

Separate the layers:

Did the USB device attach?
Did descriptors read correctly?
Did configuration complete?
Did CDC interfaces appear?
Did the driver bind?
Did the OS assign a COM port?
Did the application open the correct current port?

Re-enumeration changes port numbers

Windows may assign a new COM number when a device appears with a different serial number, different USB path, different VID/PID, or different interface identity. A device that resets into bootloader mode may expose a different COM port or no COM port at all.

Symptoms:

Device was COM8, now COM11.
Application remembers old COM port.
Replugging into another USB port changes assignment.
Bootloader uses a different port.
Device appears as unknown after firmware update.

The bus trace identifies whether the device identity changed.

CDC ACM control requests

CDC serial devices often receive class requests:

SET_LINE_CODING
GET_LINE_CODING
SET_CONTROL_LINE_STATE
SEND_BREAK

If firmware stalls or mishandles these, the port may open but data never flows, or driver binding may fail.

Capture open-port behavior, not just plug-in. Many failures happen when the application opens the COM port and the driver sends line coding or DTR/RTS state changes.

Stale application handles

Sometimes USB re-enumerates correctly, but the application keeps an old handle or cached COM port list. The bus shows the new device is present. The application still fails because it did not release or refresh the port.

This is not a USB bus failure. It is application/device-management behavior.

Debug checklist

Use this workflow:

Capture from plug-in.
Confirm device descriptor and configuration descriptor.
Inspect CDC interface descriptors.
Capture application opening the COM port.
Inspect CDC class requests.
Check for reset or disconnect after line coding.
Compare device identity before and after reconnect.
Check whether COM number changed.
Check whether the application uses a stale port name.
Preserve both USB evidence and OS port assignment notes.

Final diagnosis

A disappearing USB serial COM port can be enumeration failure, CDC descriptor failure, driver binding failure, re-enumeration with a new identity, line-coding request failure, reset under load, or stale application state.

Bus Scope helps by showing the USB side of the story so COM port symptoms can be tied to attach, descriptors, CDC requests, resets, and actual device identity.

Diagnose by layer

Layer	Evidence	Typical symptom
Physical/topology	Attach, reset, speed, disconnect, hub path	Device vanishes or flaps
Enumeration	Device/configuration/interface descriptors and `SET_CONFIGURATION`	Unknown device or no driver binding
CDC contract	Communication/data interfaces and functional descriptors	USB device appears but no serial function
Driver binding	OS chooses serial driver for intended interface	No COM port despite successful enumeration
Port assignment	OS maps device/interface identity to a port name	COM number changes
Port open	CDC line coding and control-line requests	Port appears but open fails/resets
Data path	Bulk IN/OUT and notification endpoint	Open succeeds but no data
Application state	Handle, cached list, retry logic	New port works manually but app stays broken

Do not treat Device Manager's port label as proof about lower layers. Capture and OS observations must be correlated.

Preserve enumeration identity

Record before and after:

VID and PID;
device bcdDevice;
manufacturer/product/serial strings;
configuration and interface numbers;
CDC class/subclass/protocol;
interface association descriptor for composite functions;
endpoint addresses;
physical USB port/controller;
host-assigned address;
OS port name.

If the serial string changes, disappears, or is duplicated incorrectly, Windows may treat the device as a different instance. If the firmware switches to a bootloader VID/PID or interface layout, a new port is expected rather than random.

Verify CDC descriptor structure

A CDC ACM function commonly includes:

communication-class interface;
class-specific header descriptor;
call-management descriptor where applicable;
abstract-control-management descriptor;
union functional descriptor linking control and data interfaces;
interrupt IN notification endpoint;
data-class interface;
bulk OUT and bulk IN endpoints.

Composite devices may use an interface association descriptor to group the function. Check interface numbers and union references against raw bytes. A descriptor can be syntactically readable yet point to the wrong data interface.

The USB descriptor debugging guide provides a field-validation workflow.

Capture the port-open sequence

The device may enumerate normally and fail only when software opens it. Start the application while capture continues and locate:

Request	What to inspect
`SET_LINE_CODING`	Baud rate, stop bits, parity, data bits, status
`GET_LINE_CODING`	Returned values if the driver asks
`SET_CONTROL_LINE_STATE`	DTR and RTS state, completion status
`SEND_BREAK`	Duration/value and firmware support

Firmware should validate request length, interface recipient/index, data direction, and allowed values. A stall may be correct for an unsupported request but can cause a driver/application failure when support is required.

DTR/RTS-triggered resets

Development boards and bootloaders sometimes use DTR/RTS transitions to reset or enter programming mode. The apparent sequence can be:

COM port opens.
Host sends SET_CONTROL_LINE_STATE.
Hardware reset fires.
USB disconnects.
Bootloader or application firmware re-enumerates.
Port identity changes.
Original handle becomes invalid.

Capture the class request immediately before disconnect and compare firmware/hardware reset logic. The USB trace can prove correlation but not the board-level reset circuit by itself.

Bootloader versus application identity

Create a table:

Property	Bootloader	Application
VID/PID
Serial string
Configuration
Interfaces
CDC interface number
Endpoints
Windows COM port

Different VID/PID or interface layout usually produces a different device instance. An updater must expect the transition, release the old handle, watch for the new identity, and reopen only after enumeration completes.

Device address versus COM number

The host-assigned USB address is temporary and can change every enumeration. The COM number is an OS-level persistent or semi-persistent mapping based on identity and topology. They are not interchangeable.

Use USB address to filter one capture instance.
Use VID/PID, serial, interfaces, and physical path to correlate re-enumeration.
Use OS device APIs to discover the current port.
Do not hard-code the host-assigned USB address or assume a COM number identifies firmware mode forever.

Known-good versus failing trace

Align at application open:

Sequence	Known-good	Failing
Enumeration	Descriptors/configuration complete	Same or first divergence
Driver class setup	CDC requests succeed	Stall, timeout, changed value, or absent
Port-open control	DTR/RTS state	Reset/disconnect correlation
Data OUT	Bulk request completes	Missing/failing
Data IN	Response/notification	Missing/failing
Recovery	Handle remains valid	Re-enumeration/new identity

The first divergence tells whether to investigate descriptors, class handling, reset logic, endpoint data, or the application.

Windows driver-binding checks

When USB enumeration succeeds but no COM port appears:

Verify the intended CDC interface class/subclass/protocol.
Check composite grouping and interface numbers.
Inspect OS device status and chosen driver.
Check whether a custom or stale driver package owns the interface.
Compare known-good VID/PID/interface identity.
Capture a clean first enumeration before repeated driver changes.

Bus capture cannot show every Plug and Play policy decision. Pair it with OS setup/device logs and record which interface the driver attempted to bind.

Linux comparison

Linux may expose a CDC ACM device as a /dev/ttyACM* node rather than a COM port. A device that works there but not on Windows provides useful evidence:

core USB descriptors and endpoint behavior may be sufficient;
Windows-specific driver binding, Microsoft descriptors, composite grouping, or identity mapping may differ;
application port-discovery logic may be platform-specific.

It does not prove firmware is universally correct. Compare enumeration and class requests on both hosts.

Application recovery requirements

A robust serial application should:

enumerate devices by stable identity where possible;
release the old handle on removal;
invalidate cached port lists;
distinguish bootloader and application identities;
wait for re-enumeration completion;
retry with bounded backoff;
show the new port rather than silently reopening the old name;
preserve user intent without spinning forever.

If the bus shows a healthy new CDC instance and another terminal can open it, fix application recovery instead of changing USB firmware.

Bus Scope workflow

Capture before plug-in on the correct backend.
Verify device and configuration descriptors.
Verify CDC interfaces and functional descriptors.
Note initial address and COM port.
Continue capture while opening the application.
Inspect line coding and control-line state.
Mark reset or disconnect.
Identify the re-enumerated device.
Compare identity and endpoints.
Export a bounded case with OS port notes and firmware build.

Use platform capture setup before a time-critical reproduction.

Common mistakes

Installing random drivers before capturing

Preserve a clean enumeration attempt and OS binding state first.

Blaming the COM number

A changed number is a symptom of identity/topology mapping. Compare descriptors and serial string.

Capturing plug-in but not port open

CDC failures often begin with class requests sent only when the application opens the port.

Ignoring bootloader mode

Bootloader and application firmware may intentionally expose different identities.

Calling stale application state a USB failure

If the new device is healthy, the application must refresh discovery and handles.

Questions and answers

Why does my USB serial COM port disappear when opened?

The open sequence may send line-coding or DTR/RTS requests that trigger a firmware stall, reset, bootloader transition, or disconnect. Capture the class request immediately before disappearance.

Why did COM8 become COM11?

Windows may see a different device instance because serial string, VID/PID, interface identity, physical path, or firmware mode changed.

Can a device enumerate without creating a COM port?

Yes. Basic enumeration may succeed while CDC descriptors, composite grouping, or driver binding fails.

Is a new USB address the same as a new COM port?

No. USB address is temporary per enumeration. COM number is an OS mapping based on device/interface identity and topology.

What should firmware log?

Log CDC requests and values, interface state, endpoint activation, reset cause, USB disconnect/reconnect, and bootloader/application transitions.

What proves the problem is in the application?

The re-enumerated device has correct descriptors, driver binding, and data behavior; another client can open it; but the original app continues using a stale name or handle.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: