Virtual serial ports are used by both Bluetooth services and client
applications. The desire to preinstall a few is explained by the inability
of Windows non-admin users to add devices served by unsigned drivers.
And now a shameless plug: Broadcom Widcomm BTW Bluetooth stack generally
does not create a COM port until it is needed by a particular client or
service.
Regards,
-Ilya
----- Original Message -----
Subject: Re: Locking down a com port friendly name - another
driver/installer
is hijacking my COM name!
From: “S. Drasnin”
Date: Fri, 9 Jun 2006 15:39:17 -0700
X-Message-Number: 52
thank you for the good info!
I found some postings on the web indicating that others also ran into this
com
port Toshiba bluetooth com port hijacking problem in version 3. Also the
release
notes for version 4.00.01 indicate what looks like a fix: Added the feature
to
fix the COM port confliction issue.
(Definitely a embarrassing bug.)
What is the purpose of all those com ports (more than 5!) being taken by
the
Bluetooth stack? Is there one port each for a specific type of data - so
that it
is routed based on who reads from a particular com port?
thanks again
----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: June 09, 2006 11:59 AM
Subject: RE: [ntdev] Locking down a com port friendly name - another
driver/installer is hijacking my COM name!
The kernel itself does absolutely nothing. The ports class installer uses
the
ComDB to assign names. The comdb uses its own tracking system b/c the
SERIALCOMM key is only populated by running drivers and claiming a port
number
for a driver which is currently not running is just as evil as claiming one
for
a running driver.
The ports class installer assumes ppl are playing by the rules. It is
used to
hand out names that it knows are free, its role is not to prevent a
malicious
device install from taking a port name away from another driver.
There is nothing you can do here. This is a massive chicken and egg
problem,
esp if they are not installing in the ports class.
d
________________________________________
From:
xxxxx@lists.osr.commailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, June 09, 2006 11:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Locking down a com port friendly name - another
driver/installer is hijacking my COM name!
hi
I have a bug on my plate in which, when installed, theToshiba Bluetooth
stack
version #3 hijacks 2 of the 4 COM ports my virtual-serial-over-usb driver
creates while my virtual com ports are actually in use by an app! (It’s not
clear whether the Toshiba code has hard-coded what COM Ports it expects to
use -
I don’t see anything in their inf file that specifies a COM Port name. I
also
don’t see anything in there indicating it wants to be part of the Ports
class.
Note that version #4 of the Toshiba Bluetooth stack version #4 doesn’t repro
the
problem, but I need to make sure my driver is robust and protects itself as
much
as possible.))
I am concerned that there is something I need to do (besides what I’ve
done)
to lock down the COM port friendly name, or if the Toshiba Bluetooth stack
is
behaving badly.
Here’s what I am currently doing - I think that 2c would be enough to lock
down the com port name, but I might be wrong.
1) bus driver that creates the 4 PDOs creating the represent the COM ports
creates the PDOs, specifying that the device name should be auto-generated
by
specifying FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN as one of
the
IoCreateDevice parameters.
2) The driver that gets loaded for the child PDOs specifies “Class=Ports”
so
that the OS knows to assign the name of the COM port.
On the IRP_MN_START_DEVICE, I call a routine that does the following:
a) First, look up the COM port friendly name under
HKLM\System\CurrentControlSet\Enum<hardwareid>\DeviceParameters. The name
is
listed under the PortName value.
b) Create a symbolic link between the link name (\DosDevices\COM#) and the
device name (\Device\VirSerN)
where N is the instance number and #is the com port name fetched from b.
c) Under HKLM\Hardware\DeviceMap\SerialComm, create a new entry for the
COM
Port:
\Device\VirSerN REG_SZ COM#
I would think that having that each of the entries under
HKLM\Hardware\DeviceMap\SerialComm would be enough to lock down the COM port
(so
that other drivers couldn’t use the same names) since this is a system-wide
registry key. (It also has an entry for the COM1 standard serial port on
PCs).
What checking does the OS do to prevent a driver from hijacking a COM Port
already assigned by the OS? Is this checking robust, is there any holes? Is
the
checking based on registry key entries?
I will look at the same DDK serial driver again and google, but I’m hoping
one
of you (Doron perhaps?) knows the answer to this already and/or have looked
into
bugs in this area before. And running regmon might help too.
thanks in advance!!!</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>