Virtual Serial Port changing COM port number

nicos

unread,

Oct 13, 2009, 5:15:02 PM10/13/09

to

I've developed a virtual serial port driver (UMDF) which uses the
built in SerialPortPropPageProvider (msports.dll) to display the port
property page.

If the COM port number has been changed in the property page, what is
the best way of restarting/reconfiguring the driver?
From what I can tell, one option is to create a co-installer to look
out for the DIF_PROPERTYCHANGE and then restart the driver. Is that
the normal way of doing it?

Maxim S. Shatskih

unread,

Oct 14, 2009, 1:07:11 AM10/14/09

to

> If the COM port number has been changed in the property page, what is
> the best way of restarting/reconfiguring the driver?

What is the need of this? why restart the device if its symlink name changed?

--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com

Wilhelm Noeker

unread,

Oct 14, 2009, 3:52:31 AM10/14/09

to

nicos wrote:

> I've developed a virtual serial port driver (UMDF) which uses the
> built in SerialPortPropPageProvider (msports.dll) to display the port
> property page.
>
> If the COM port number has been changed in the property page, what is
> the best way of restarting/reconfiguring the driver?

As Maxim already said, you shouldn't. It's not only unnecessary, but
you'll even find that those two actions combined (change port number via
msports proppage, then restart the port device) will make your COM port
unaccessible (until you restart Windows). This was discussed here
recently, see
http://groups.google.com/group/comp.os.ms-windows.programmer.nt.kernel-mode/msg/00f50fefe393a648

> From what I can tell, one option is to create a co-installer to look
> out for the DIF_PROPERTYCHANGE and then restart the driver. Is that
> the normal way of doing it?

If you want to do some extra work, write your own property page
provider. Or just go on using the built-in provider as you do now, and
wait and see if that is good enough for what your customers usually do.

nicos

unread,

Oct 14, 2009, 11:00:10 AM10/14/09

to

>why restart the device if its symlink name changed?

The problem is, after changing the port number (using the property
page), that port can no longer be opened with CreateFile .

This is what I found so far using WinObj (under Vista)...

-When the driver installs it creates a symbolic link in the global
DosDevices directory
-Changing the port number with the property page (msports.dll) deletes
that symbolic link, and creates a new symbolic link in the local
DosDevices directory (not the global).

To get CreateFile to work again you have to restart the PC or disable/
enable the device (causing the driver to create a symbolic link in the
global DosDevices).

I'd imagine it must be a problem other people have run in to, unless
it's something to do with the fact it's a UMDF driver?

Maxim S. Shatskih

unread,

Oct 15, 2009, 1:35:53 AM10/15/09

to

"COM1" names are obsolete, try using device interface names instead.

--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com

"nicos" <nico...@googlemail.com> wrote in message news:a04f2835-9db1-4c37...@e8g2000yqo.googlegroups.com...

Wilhelm Noeker

unread,

Oct 15, 2009, 3:47:20 AM10/15/09

to

Maxim S. Shatskih wrote:

> "COM1" names are obsolete, try using device interface names instead.

Surely you're joking? I've never seen a piece of software open a serial
port for communication by any other means than CreateFile() on the
port's symbolic link name.

Chris

unread,

Oct 20, 2009, 11:05:34 AM10/20/09

to

No, he's not joking. And I've seen that many times. Actually it's
preferred for a number of reasons, not the least of which is that
people's COMDb's can and do get corrupted, so opening "COM4" may not
get you who you think you're getting...