Hello NG,

I wrote an Inf-File which installs a virtual comport using usbser.sys for my
USB device. When I connect the device to the PC the Hardware wizard comes up
an installes usbser.sys. After that I can communicate with the device via a
virtual Com-Port. So far so good.
Now I tried this on several machines and now I am facing a problem on one of
my testing machines. The driver on this machine seems to be installed
properly but the Hardware wizard comes again and again. When I open the
device manager the device appears under ports without an assigned Com-Port.
Looking into the registry I found the entry \Device\USBSER000 which value is
set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device is
not accessible via that COM Port (Com 11).

Any ideas?

Benji

RE: Virtual comport with usbser.sys by johngar

johngar
Thu Mar 08 15:40:03 CST 2007

------=_NextPart_0001_1DF18E72
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

"Benji" wrote:
Looking into the registry I found the entry \Device\USBSER000 which value
is
set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device is
not accessible via that COM Port (Com 11).

I would expect this to occur if COM ports COM1 through COM10 had already
been defined on the system at some previous time, and the next available
port was therefore COM11.

If these additional ports are not listed in Device Manager (even with "Show
Hidden Devices" enabled), then you may need to manually remove the entries
for previous devices from the registry. These should be found under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSER\Enum.

In the case you describe, I would expect device instances to be listed with
value names "0" through "11", the "Count" value set to 11, and
"NextInstance" value set to 11. The string data listed for each value
named "0" through "11" point to subkeys under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum where the devices are
listed.

If you find everything as I'm predicting you will, then deleting the
device-instance subkeys under HKLM\SYSTEM\CurrentControlSet\Enum, deleting
the device-instance values under
HKLM\SYSTEM\CurrentControlSet\Services\USBSER\Enum, and editing the
"Count" and "NextInstance" values appropriately (e.g., 0) would clear out
all unused entries and allow you to start enumerating new devices with
names beginning with COM1.

If you have non-USBSER serial devices, then the maximum values under
HKLM\SYSTEM\CurrentControlSet\Services\USBSER\Enum would be less. In
Device Manager, you can examine the Properties of the COM ports present in
the system, particularly the driver details, for clues as to which driver
is loading for each device, and thus make a guess as to which keys in the
registry contain the info on those devices.

John Garrett [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_1DF18E72
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0 Trebuchet MS;}}
\viewkind4\uc1\pard\f0\fs20 "Benji" wrote:
\par \pard\li720 Looking into the registry I found the entry \\Device\\USBSER000 which value is
\par set to "COM11" under HKLM\\Hardware\\DEVICEMAP\\SERIALCOMM but my device is
\par not accessible via that COM Port (Com 11).
\par \pard
\par I would expect this to occur if COM ports COM1 through COM10 had already been defined on the system at some previous time, and the next available port was therefore COM11.
\par
\par If these additional ports are not listed in Device Manager (even with "Show Hidden Devices" enabled), then you may need to manually remove the entries for previous devices from the registry. These should be found under HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\USBSER\\Enum.
\par
\par In the case you describe, I would expect device instances to be listed with value names "0" through "11", the "Count" value set to 11, and "NextInstance" value set to 11. The string data listed for each value named "0" through "11" point to subkeys under HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum where the devices are listed.
\par
\par If you find everything as I'm predicting you will, then deleting the device-instance subkeys under HKLM\\SYSTEM\\CurrentControlSet\\Enum, deleting the device-instance values under HKLM\\SYSTEM\\CurrentControlSet\\Services\\USBSER\\Enum, and editing the "Count" and "NextInstance" values appropriately (e.g., 0) would clear out all unused entries and allow you to start enumerating new devices with names beginning with COM1.
\par
\par If you have non-USBSER serial devices, then the maximum values under HKLM\\SYSTEM\\CurrentControlSet\\Services\\USBSER\\Enum would be less. In Device Manager, you can examine the Properties of the COM ports present in the system, particularly the driver details, for clues as to which driver is loading for each device, and thus make a guess as to which keys in the registry contain the info on those devices.
\par
\par John Garrett [MSFT]
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_1DF18E72--


Re: Virtual comport with usbser.sys by Doron

Doron
Thu Mar 08 23:57:10 CST 2007

No, you should not be touching
HKLM\SYSTEM\CurrentControlSet\Services\USBSER\Enum . that is owned by the
system's SCM. The Enum key has *nothing* to do with assigned COM port names.
COM port names are global to all drivers and allocated by the COM name
arbiter. even if you don't currenlty have COM3-10 on the machine, at one
point in time you did.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"John Garrett [MSFT]" <johngar@online.microsoft.com> wrote in message
news:a6ieZpcYHHA.2372@TK2MSFTNGHUB02.phx.gbl...
> "Benji" wrote:
> Looking into the registry I found the entry \Device\USBSER000 which value
> is
> set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device is
> not accessible via that COM Port (Com 11).
>
> I would expect this to occur if COM ports COM1 through COM10 had already
> been defined on the system at some previous time, and the next available
> port was therefore COM11.
>
> If these additional ports are not listed in Device Manager (even with
> "Show
> Hidden Devices" enabled), then you may need to manually remove the entries
> for previous devices from the registry. These should be found under
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSER\Enum.
>
> In the case you describe, I would expect device instances to be listed
> with
> value names "0" through "11", the "Count" value set to 11, and
> "NextInstance" value set to 11. The string data listed for each value
> named "0" through "11" point to subkeys under
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum where the devices are
> listed.
>
> If you find everything as I'm predicting you will, then deleting the
> device-instance subkeys under HKLM\SYSTEM\CurrentControlSet\Enum, deleting
> the device-instance values under
> HKLM\SYSTEM\CurrentControlSet\Services\USBSER\Enum, and editing the
> "Count" and "NextInstance" values appropriately (e.g., 0) would clear out
> all unused entries and allow you to start enumerating new devices with
> names beginning with COM1.
>
> If you have non-USBSER serial devices, then the maximum values under
> HKLM\SYSTEM\CurrentControlSet\Services\USBSER\Enum would be less. In
> Device Manager, you can examine the Properties of the COM ports present in
> the system, particularly the driver details, for clues as to which driver
> is loading for each device, and thus make a guess as to which keys in the
> registry contain the info on those devices.
>
> John Garrett [MSFT]
> This posting is provided "AS IS" with no warranties, and confers no
> rights.



Re: Virtual comport with usbser.sys by Wilhelm

Wilhelm
Fri Mar 09 02:58:41 CST 2007

Benji wrote:

> I wrote an Inf-File which installs a virtual comport using usbser.sys for my
> USB device.

Did you just write the INF file, or did you also write the driver? :-)

> When I open the
> device manager the device appears under ports without an assigned Com-Port.
> Looking into the registry I found the entry \Device\USBSER000 which value is
> set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device is
> not accessible via that COM Port (Com 11).

Use WinObj and look to see if \Device\USBSER000 really exists. And if
so, is there a symbolic link \??\COM11 which refers to it?

Did you check the event log? Some serial port drivers report an event
if, for example, IoCreateSymbolicLink() failed for some reason.

Re: Virtual comport with usbser.sys by Wilhelm

Wilhelm
Fri Mar 09 03:33:56 CST 2007

Wilhelm Noeker wrote:

> Benji wrote:
>
>> I wrote an Inf-File which installs a virtual comport using usbser.sys
>> for my USB device.
>
> Did you just write the INF file, or did you also write the driver? :-)

Oops, sorry for that stupid question. I wasn't aware that there is a
system-supplied driver with that name.

Re: Virtual comport with usbser.sys by CZ

CZ
Thu Mar 22 12:50:33 CDT 2007

I am having an identical issue (various COMx) and it seems that Benji's
question was never addressed...

"Benji" wrote:
>Looking into the registry I found the entry \Device\USBSER000 which value is
>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device >is not accessible via that COM Port (Com 11).

...everything that John Garett wrote is true of my registry, I also cannot
access the virtual COM port by the value reported in DeviceManager.

Re: Virtual comport with usbser.sys by Alexander

Alexander
Thu Mar 22 13:36:17 CDT 2007

Are you specifying "\\.\COM11" in CreateFile? Just "COM11" won't work.

"CZ" <CZ@discussions.microsoft.com> wrote in message
news:66243EF3-BE17-4CE2-91A1-0E703E63B06C@microsoft.com...
>I am having an identical issue (various COMx) and it seems that Benji's
> question was never addressed...
>
> "Benji" wrote:
>>Looking into the registry I found the entry \Device\USBSER000 which value
>>is
>>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device >is
>>not accessible via that COM Port (Com 11).
>
> ...everything that John Garett wrote is true of my registry, I also cannot
> access the virtual COM port by the value reported in DeviceManager.



Re: Virtual comport with usbser.sys by CZ

CZ
Thu Mar 22 14:23:31 CDT 2007

...my work is from the USB device side at this point.
I plan to develop a bulk transfer driver, but do not need it for debug at
this point.

I am using usbser.sys and a terminal program to send byte oriented commands
to the USB slave from a WinXP host.

The DeviceManager shows the USB slave installed at a specific COM port.
The terminal (and PortMon) cannot open those devices.

This happens after one or two disconnects of the USB slave.
A reboot is necessary to continue.

I entered this conversation because the conditions discussed are exactly
what I am seeing, I would imagine that the solution will similar as well...

"Alexander Grigoriev" wrote:

> Are you specifying "\\.\COM11" in CreateFile? Just "COM11" won't work.
>
> "CZ" <CZ@discussions.microsoft.com> wrote in message
> news:66243EF3-BE17-4CE2-91A1-0E703E63B06C@microsoft.com...
> >I am having an identical issue (various COMx) and it seems that Benji's
> > question was never addressed...
> >
> > "Benji" wrote:
> >>Looking into the registry I found the entry \Device\USBSER000 which value
> >>is
> >>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device >is
> >>not accessible via that COM Port (Com 11).
> >
> > ...everything that John Garett wrote is true of my registry, I also cannot
> > access the virtual COM port by the value reported in DeviceManager.
>
>
>

Re: Virtual comport with usbser.sys by Alexander

Alexander
Thu Mar 22 15:52:04 CDT 2007

Not all comm programs handle USB device unplug correctly. Make sure you
close the application before you unplug/replug of the device.

"CZ" <CZ@discussions.microsoft.com> wrote in message
news:04335BC6-5F7E-4408-8739-FEF8F20B6EDF@microsoft.com...
> ...my work is from the USB device side at this point.
> I plan to develop a bulk transfer driver, but do not need it for debug at
> this point.
>
> I am using usbser.sys and a terminal program to send byte oriented
> commands
> to the USB slave from a WinXP host.
>
> The DeviceManager shows the USB slave installed at a specific COM port.
> The terminal (and PortMon) cannot open those devices.
>
> This happens after one or two disconnects of the USB slave.
> A reboot is necessary to continue.
>
> I entered this conversation because the conditions discussed are exactly
> what I am seeing, I would imagine that the solution will similar as
> well...
>
> "Alexander Grigoriev" wrote:
>
>> Are you specifying "\\.\COM11" in CreateFile? Just "COM11" won't work.
>>
>> "CZ" <CZ@discussions.microsoft.com> wrote in message
>> news:66243EF3-BE17-4CE2-91A1-0E703E63B06C@microsoft.com...
>> >I am having an identical issue (various COMx) and it seems that Benji's
>> > question was never addressed...
>> >
>> > "Benji" wrote:
>> >>Looking into the registry I found the entry \Device\USBSER000 which
>> >>value
>> >>is
>> >>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device
>> >> >is
>> >>not accessible via that COM Port (Com 11).
>> >
>> > ...everything that John Garett wrote is true of my registry, I also
>> > cannot
>> > access the virtual COM port by the value reported in DeviceManager.
>>
>>
>>



Re: Virtual comport with usbser.sys by CZ

CZ
Thu Mar 22 16:07:03 CDT 2007

I close the port in RealTerm, watch PortMon for the IRP_MJ_CLEANUP & CLOSE to
return SUCCESS.
Then I close PortMon, then I close RealTerm.
At this point I stop the slave device with the embedded programmer, reflash
the device and let the device up out of reset.
Enumeration over USB works fine, the device registers and is assigned to
usbser.sys. ...the COM port (checked in DeviceManager) shows up in PortMon
but is inaccessable, RealTerm does not show the COM port as an option.
I have written a quick app in Python to open the port directly, no better
luck.
HyperTerminal cannot open the port either.

"Alexander Grigoriev" wrote:

> Not all comm programs handle USB device unplug correctly. Make sure you
> close the application before you unplug/replug of the device.
>
> "CZ" <CZ@discussions.microsoft.com> wrote in message
> news:04335BC6-5F7E-4408-8739-FEF8F20B6EDF@microsoft.com...
> > ...my work is from the USB device side at this point.
> > I plan to develop a bulk transfer driver, but do not need it for debug at
> > this point.
> >
> > I am using usbser.sys and a terminal program to send byte oriented
> > commands
> > to the USB slave from a WinXP host.
> >
> > The DeviceManager shows the USB slave installed at a specific COM port.
> > The terminal (and PortMon) cannot open those devices.
> >
> > This happens after one or two disconnects of the USB slave.
> > A reboot is necessary to continue.
> >
> > I entered this conversation because the conditions discussed are exactly
> > what I am seeing, I would imagine that the solution will similar as
> > well...
> >
> > "Alexander Grigoriev" wrote:
> >
> >> Are you specifying "\\.\COM11" in CreateFile? Just "COM11" won't work.
> >>
> >> "CZ" <CZ@discussions.microsoft.com> wrote in message
> >> news:66243EF3-BE17-4CE2-91A1-0E703E63B06C@microsoft.com...
> >> >I am having an identical issue (various COMx) and it seems that Benji's
> >> > question was never addressed...
> >> >
> >> > "Benji" wrote:
> >> >>Looking into the registry I found the entry \Device\USBSER000 which
> >> >>value
> >> >>is
> >> >>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my device
> >> >> >is
> >> >>not accessible via that COM Port (Com 11).
> >> >
> >> > ...everything that John Garett wrote is true of my registry, I also
> >> > cannot
> >> > access the virtual COM port by the value reported in DeviceManager.
> >>
> >>
> >>
>
>
>

Re: Virtual comport with usbser.sys by chris

chris
Thu Mar 22 17:37:24 CDT 2007

On Mar 22, 4:07 pm, CZ <C...@discussions.microsoft.com> wrote:

> I close the port in RealTerm, watch PortMon for the IRP_MJ_CLEANUP & CLOSE to
> return SUCCESS.

Ah. There's your problem. I think if you use PortMon on a USB serial
device, you have to reboot after you remove the device. At least,
that's always been the case for me.


Re: Virtual comport with usbser.sys by CZ

CZ
Thu Mar 22 18:54:13 CDT 2007

Thanks Chris, this has been a TREMENDOUS help...now I can go on with
development!

"chris.aseltine@gmail.com" wrote:

> On Mar 22, 4:07 pm, CZ <C...@discussions.microsoft.com> wrote:
>
> > I close the port in RealTerm, watch PortMon for the IRP_MJ_CLEANUP & CLOSE to
> > return SUCCESS.
>
> Ah. There's your problem. I think if you use PortMon on a USB serial
> device, you have to reboot after you remove the device. At least,
> that's always been the case for me.
>
>

Re: Virtual comport with usbser.sys by Alexander

Alexander
Fri Mar 23 10:26:06 CDT 2007

Looks like some driver is still holding a reference to USBSER.sys. Properly
designed USBSER, though, should delete its symbolic links at
SURPRISE_REMOVAL. Knowing poor quality history of USBSER.sys, I would not be
surprised if it doesn't delete its links and interfaces at SURPRISE_REMOVAL.

"CZ" <CZ@discussions.microsoft.com> wrote in message
news:0FE4700A-B207-45A0-BC6A-B4B62CE278A6@microsoft.com...
>I close the port in RealTerm, watch PortMon for the IRP_MJ_CLEANUP & CLOSE
>to
> return SUCCESS.
> Then I close PortMon, then I close RealTerm.
> At this point I stop the slave device with the embedded programmer,
> reflash
> the device and let the device up out of reset.
> Enumeration over USB works fine, the device registers and is assigned to
> usbser.sys. ...the COM port (checked in DeviceManager) shows up in
> PortMon
> but is inaccessable, RealTerm does not show the COM port as an option.
> I have written a quick app in Python to open the port directly, no better
> luck.
> HyperTerminal cannot open the port either.
>
> "Alexander Grigoriev" wrote:
>
>> Not all comm programs handle USB device unplug correctly. Make sure you
>> close the application before you unplug/replug of the device.
>>
>> "CZ" <CZ@discussions.microsoft.com> wrote in message
>> news:04335BC6-5F7E-4408-8739-FEF8F20B6EDF@microsoft.com...
>> > ...my work is from the USB device side at this point.
>> > I plan to develop a bulk transfer driver, but do not need it for debug
>> > at
>> > this point.
>> >
>> > I am using usbser.sys and a terminal program to send byte oriented
>> > commands
>> > to the USB slave from a WinXP host.
>> >
>> > The DeviceManager shows the USB slave installed at a specific COM port.
>> > The terminal (and PortMon) cannot open those devices.
>> >
>> > This happens after one or two disconnects of the USB slave.
>> > A reboot is necessary to continue.
>> >
>> > I entered this conversation because the conditions discussed are
>> > exactly
>> > what I am seeing, I would imagine that the solution will similar as
>> > well...
>> >
>> > "Alexander Grigoriev" wrote:
>> >
>> >> Are you specifying "\\.\COM11" in CreateFile? Just "COM11" won't work.
>> >>
>> >> "CZ" <CZ@discussions.microsoft.com> wrote in message
>> >> news:66243EF3-BE17-4CE2-91A1-0E703E63B06C@microsoft.com...
>> >> >I am having an identical issue (various COMx) and it seems that
>> >> >Benji's
>> >> > question was never addressed...
>> >> >
>> >> > "Benji" wrote:
>> >> >>Looking into the registry I found the entry \Device\USBSER000 which
>> >> >>value
>> >> >>is
>> >> >>set to "COM11" under HKLM\Hardware\DEVICEMAP\SERIALCOMM but my
>> >> >>device
>> >> >> >is
>> >> >>not accessible via that COM Port (Com 11).
>> >> >
>> >> > ...everything that John Garett wrote is true of my registry, I also
>> >> > cannot
>> >> > access the virtual COM port by the value reported in DeviceManager.
>> >>
>> >>
>> >>
>>
>>
>>



Re: Virtual comport with usbser.sys by chris

chris
Fri Mar 23 10:57:42 CDT 2007

On Mar 23, 10:26 am, "Alexander Grigoriev" <a...@earthlink.net> wrote:

> Looks like some driver is still holding a reference to USBSER.sys. Properly
> designed USBSER, though, should delete its symbolic links at
> SURPRISE_REMOVAL. Knowing poor quality history of USBSER.sys, I would not be
> surprised if it doesn't delete its links and interfaces at SURPRISE_REMOVAL.

I'm fairly certain this is a PortMon issue as I've seen this behavior
with every modem driver I've ever debugged with that tool. I wonder
if it's some side-effect of attaching to an already build stack, as
PortMon does.