DosDeviceName lost until reboot

Consider the following entry in a device description in the ACPI tables:

Name (_DDN, “COM1”)

DDN stands for “DOS Device Name” and this entry will cause a REG_SZ to be added to the device hardware key as follows (this happens during boot):

HKLM\SYSTEM\CurrentControlSet\Enum\ACPI[devid][devkey]\Device Parameters\DosDeviceName = “COM1”

The Ports class installer will query this registry key during “devcon update” and it will use what it finds there as the device name. However, I have noticed that during “devcon remove” the Ports class installer will call SetupDiRemoveDevice() which deletes most of the entries under the device key (including DosDeviceName). Subsequent device installations will no longer find that registry entry and the intended device name will no longer be honored. It is only after a reboot that DosDeviceName reappears under the device key.

Is this the way it is supposed to work or should SetupDiRemoveDevice() leave DosDeviceName intact?

Is there a reason you need to assign DOS device name by ACPI means? On my laptop, for example, I don’t see DosDeviceName value in Device Parameters key. I see PortName=COM1

Your laptop may have a mapper that writes “PortName” based on what the BIOS reports (this is described in the link below).

Either that or the Ports class installer wrote “PortName” during installation of the serial driver. If the installer can’t determine the intended port name it will just allocate the next free port from the COM name database. This is not desirable for a physical port which needs to have a known name.

Are there actual boxes that actually use/need that? I mean, if you have a legacy COM, it will get its name on the first boot after OS install, and that name will never change.

Remove Device operation clears the HW instance key, including any port name in it. That’s how it is.

My HP xw6400 workstation uses it. There is a “DosDeviceName” with the value “COM1” under “HKLM\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0501\1\Device Parameters”.

If an end user removes the current driver and reinstalls it or installs a new version (without rebooting first) then the port name may change. That seems like a problem to me, especially if applications makes assumptions about which COM port is associated with a particular physical port.

This usage scenario is so unlikely, so it’s fair to ask the “too smart” user who installs a new version of uart driver, to go to the port properties and set the name to COM1, if there is any application that wants COM1 so much. Or ask to reboot. I mean, serial.sys is not updated more often than once in 5 years or so.