Re-enumeration of first device when second device is connected.

xxxxx@gmail.com wrote:

As far as the INF file, it is same section for both devices
guess from the inf we cannot directly refer class installer

here are the parts of the INF file

Why not send us the entire INF file? It’s amazing how many times people
say to themselves “I don’t need to send THAT part of the code”, when
that’s the exact part that contains a problem. Now, I’m not convinced
the problem is in the INF, but we can’t tell anything from this snippet.

Stepping back for a moment, is this behavior really all that
surprising? When the second device is installed for the first time, the
system is going to refresh the driver files from the driver store. It
can’t copy over the driver file unless it stops all of the devices that
are currently using that driver.

Once both devices have been seen once, you won’t see this behavior when
plugging and unplugging.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Stepping back for a moment, is this behavior really all that
surprising? When the second device is installed for the first time, the
system is going to refresh the driver files from the driver store. It
can’t copy over the driver file unless it stops all of the devices that
are currently using that driver.

Once both devices have been seen once, you won’t see this behavior when
plugging and unplugging.

Base on Tim’s description, from technical aspect, it is understoodable.
But from real user case, and user experience aspect, this case is an less consideration case, or need to optimized.

Driver fetch from App store is not a good explanation of the previous installed device be interrupted when they are in working state.

I think Alex suggest you to capture the USB trace on the bus instead of the ETW.

@Tim,

below is the complete INF File

[Version]
Signature=“$CHICAGO$”
Class=Ports
ClassGUID={4d36e978-e325-11ce-bfc1-08002be10318}
Provider=%UsbcdcV%
DriverVer=06/17/2014,1.0.0.32
CatalogFile=CdcUSBF.cat

[Manufacturer]
%UsbcdcV%=MRI,NTAMD64

[MRI]
%VUART_1% = UsbcdcV.Install,USB\VID_1123&PID_2019
%VUART_2% = UsbcdcV.Install,USB\VID_1123&PID_2013

[MRI.NTAMD64]
%VUART_1% = UsbcdcV.Install,USB\VID_1123&PID_2019
%VUART_2% = UsbcdcV.Install,USB\VID_1123&PID_2013

[SourceDisksFiles.x86]
CdcUSBV.sys =1
CdcLFlV.sys=1
DIFxAPI.dll = 1
Cdc_CoInstallerv.dll = 1

[SourceDisksFiles.amd64]
CdcUSBV.sys =2
CdcLFlV.sys=2
DIFxAPI.dll = 2
Cdc_CoInstallerv.dll = 2

[SourceDisksNames]
1=%CdcInstallationDisk%,\i386
2=%CdcInstallationDisk%,\amd64

[DestinationDirs]
CoInstaller_CopyFiles=11
UsbcdcV.Files.Driver.NT=12

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Windows XP

[UsbcdcV.Install.NT]
CopyFiles=UsbcdcV.Files.Driver.NT
AddReg=UsbcdcV.NT.AddReg

[UsbcdcV.Install.NTAMD64]
CopyFiles=UsbcdcV.Files.Driver.NT
AddReg=UsbcdcV.NT.AddReg

[UsbcdcV.Files.Driver.NT]
CdcUSBV.sys
CdcLFlV.sys

[UsbcdcV.Install.NT.Services]
AddService = UsbcdcV, %SPSVCINST_ASSOCSERVICE%, UsbcdcV.Service
AddService = CdcLFlV,CdcLFlV_AddService

[UsbcdcV.Install.NTAMD64.Services]
AddService = UsbcdcV, %SPSVCINST_ASSOCSERVICE%, UsbcdcV.Service
AddService = CdcLFlV,CdcLFlV_AddService

[UsbcdcV.Install.NT.HW]
AddReg=UsbcdcV.HW.AddReg

[UsbcdcV.Install.NTAMD64.HW]
AddReg=UsbcdcV.HW.AddReg

[UsbcdcV.NT.AddReg]
HKR,EnumPropPages32,“MsPorts.dll,SerialPortPropPageProvider”

[UsbcdcV.HW.AddReg]
HKR,Security,“D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)”
HKR,“LowerFilters”,0x00010000,“CdcLFlV”

;-------------- WDF Coinstaller installation

[UsbcdcV.Install.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[UsbcdcV.Install.NTAMD64.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[CoInstaller_CopyFiles]
Cdc_CoInstallerV.dll
DIFxAPI.dll

[CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “Cdc_CoInstallerV.dll,CdcCoInstaller”

[UsbcdcV.Install.NT.Wdf]
KmdfService=UsbcdcV, UsbcdcV_wdfsect

[UsbcdcV.Install.NTamd64.Wdf]
KmdfService = UsbcdcV, UsbcdcV_wdfsect

[UsbcdcV_wdfsect]
KmdfLibraryVersion=1.9

;-------------------------------------------
[UsbcdcV.Service]
DisplayName = %UsbcdcV.ServiceName%
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
ServiceBinary = %10%\System32\Drivers\CdcUSBV.sys
LoadOrderGroup = Base

[CdcLFlV_AddService]
DisplayName = %CdcLFlV.ServiceName%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\CdcLFlV.sys

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Strings

[Strings]
Std = “UsbCdc Uv port types”
UsbcdcV = “UsbCdc Provider”
CdcInstallationDisk = “UsbCdc Provider Installation Disc”
UsbcdcV.ServiceName=“CDC USB UART”
CdcLFlV.ServiceName = “Usbcdc Uv Lower Filter”

SPSVCINST_ASSOCSERVICE = 0x00000002; Driver service is associated with device being installed
COPYFLG_NOSKIP = 2 ; Do not allow user to skip file
SERVICE_KERNEL_DRIVER = 1
SERVICE_AUTO_START = 2
SERVICE_DEMAND_START = 3
SERVICE_ERROR_NORMAL = 1

VUART_1 = “UV 770 Device”
VUART_2 = “UV 780 Device”

@Wesley, @Alex

I think Alex suggest you to capture the USB trace on the bus instead of the ETW.

I do not have external Bus analyzer device, let me know, using any 3rd party software only tools will be sufficient for analysis.

@Tim, @Wesley,

Stepping back for a moment, is this behavior really all that surprising? When the second device is installed for the first time, the system is going to refresh the driver files from the driver store. It can’t copy over the driver file unless it stops all of the devices that are currently using that driver.

Once both devices have been seen once, you won’t see this behavior when plugging and unplugging.

I do agree, if it is 1st time connection of dev2, which may take time and might re-enum all the existing devices.
But in my case, I see almost every time, when connect the dev2

In other words, driver is installed, 1st and 2nd devices are connected and driver is loaded for both of them.
Now disconnect any device and reconnect back, I see the other device gets re-enumerated (two AddDevice calls appearing)

Latest observations:

  1. Tested with different USB COM driver the same reported issue observed.

  2. If the device is physically removed and connected back, we see the other device getting re-enumerated.
    However if the device is power cycled (by removing external power supply of the device and connecting back or device self restarted), the issue is not observed (i.e. second device remains intact)

From the above observations, not able to localize issue

  • driver level or device level or issue with PC USB ports & Hubs

xxxxx@gmail.com wrote:

below is the complete INF File

[UsbcdcV.HW.AddReg]
HKR,Security,“D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)”
HKR,“LowerFilters”,0x00010000,“CdcLFlV”

That will replace the entire LowerFilters key, deleting whatever was
there before. When you create a filter value in the registry, you
should use 0x00010008 to append yourself to the list if not already present.

Do your devices have serial numbers?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I’m afraid your device doesn’t reset its address (and other configuration) when just unplugged from USB.

You really need an USB analyzer on it.

Hi Tim,

should use 0x00010008 to append yourself to the list if not already present.
Thanks, updated the INF file as per your suggestion.

Do your devices have serial numbers?
It is not fully implemented, I verified using USBCV tool and found below output

No string returned for given index
Failed to get serial number string for iSerialNumber : 3
Device must support a GetDescriptor(String) request.

xxxxx@gmail.com wrote:

> Do your devices have serial numbers?
It is not fully implemented, I verified using USBCV tool and found below output

No string returned for given index
Failed to get serial number string for iSerialNumber : 3
Device must support a GetDescriptor(String) request.

You need to fix that. Really. You aren’t required to have serial
numbers, but if you don’t have them, then iSerialNumber needs to be 0.
What you are doing now violates the USB specification, so whatever
behavior you get is not surprising.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim,

Sure, will convey this info to the device team and getback on this.

@Alex,

Sure I will check with bus analyzer and update

Thanks all for your valuable inputs.