Can you repro either the usbview problem or the double SET_ADDRESS
problem on Win7? Win7 has better diagnostics. (As others have
suggested, please ensure there is no serial number conflict at any point.)
xiedong_sl@126.com wrote:
To Ries ,
This issue is not reproduced on all HW platforms . So , I am not sure you can reproduce at your side .
At our side , device is phone . The steps are like these :
Connect 2 equivalent phones with same version of firmware flashed . Send restart command to it using an internal tool. Note that manually restart doesn’t reproduce this issue .
After restart is done and phones are ready , the device manager can show them up correctly(driver are loaded correctly) , Launch USBView and find that there is only one in it .
At this time , I click rescan for the hardware in Device Manager and then , USBView can show both up.
I also see another issue on these phones.
Sometimes , PC tries to assign 2 different device addresses to one phone in the course of device enumeration by PC. Since the other phone doesn’t get device address so that it is not correctly enumerated by PC. Is it possible that USB data is sent to incorrect USB port queue and accordingly the configured phone receives the device address again ?
I suggest you can give some clue of how to therapy this issue remotely. And then I will follow it and report the result to you.
I confirm that there are no serial number for themselves in the subsequent tests and this issue still exists
I will try them on win 7 and report the result .
oops , This issue can not be reproduced on Win 7 …
xiedong_sl@126.com wrote:
I confirm that there are no serial number for themselves in the subsequent tests and this issue still exists
OK, let me double check a possible point of confusion here. When you
say “there are no serial number”, do you mean that you set the serial
number to an empty string, or do you mean you set the iSerialNumber
field of the device descriptor to 0?
If iSerialNumber is not 0, then your devices DO have serial numbers. An
empty serial number is still a serial number, and two devices with an
empty serial number will still cause this problem.
In order to remove the serial number, you must set iSerialNumber to 0 in
the device descriptor.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
To Roberts :
the iSerialNumber field of the device descriptor is 0
I continue to investigate this issue in view of disassemble code .
I set a bp so that the execution stops whenever a structure pointer of the specified UBB port is changed . From code, I think it’s tested to get to know if the specified port connects to phone .
I do get execution sequence .
When Phone is restarted , PC responses to the USB removal by the execution :
usbhub!USBH_ProcessPortStateChange
usbhub!USBH_FdoQueryBusRelations
In these two functions , this pointer is assigned to 0 .
Also , when Phone gets ready , PC response to the USB Arrival by the execution :
usbhub!USBH_CreateDevice…
And then , another call to USBH_PDORemoveDevice happens to change this pointer to 0 .
I think it’s the root cause of why this port is always 0 .
I screen snap the pic and collect the dump . Could you help to share a mail box ?
I’d like to send them to you (pic and dump file) .
xiedong_sl@126.com wrote:
I continue to investigate this issue in view of disassemble code .
I set a bp so that the execution stops whenever a structure pointer of the specified UBB port is changed . From code, I think it’s tested to get to know if the specified port connects to phone .
I think you are chasing ghosts down a rathole here. You are intent on
trying to blame this on a Windows bug. I can assure you with complete
confidence that plugging in multiple identical USB devices without
serial numbers works just fine in Windows, and has done so since the
very beginning.
Can you please post your descriptors? You can use usbview or uvcview
for this. Make sure “configuration descriptor” is checked.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
This may not be related to the op’s question. Based on my experience I
support you on that multiple identical USB devices without serial numbers
can work fine on Windows. And I tested that long ago. My question is how
windows kernel identifies each of the identical USB devices without serial
number? Thanks.
On Fri, Sep 4, 2009 at 12:55 PM, Tim Roberts wrote:
> xiedong_sl@126.com wrote:
> > I continue to investigate this issue in view of disassemble code .
> >
> > I set a bp so that the execution stops whenever a structure pointer of
> the specified UBB port is changed . From code, I think it’s tested to get
> to know if the specified port connects to phone .
> >
>
> I think you are chasing ghosts down a rathole here. You are intent on
> trying to blame this on a Windows bug. I can assure you with complete
> confidence that plugging in multiple identical USB devices without
> serial numbers works just fine in Windows, and has done so since the
> very beginning.
>
> Can you please post your descriptors? You can use usbview or uvcview
> for this. Make sure “configuration descriptor” is checked.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Michael Zhu wrote:
This may not be related to the op’s question. Based on my experience I
support you on that multiple identical USB devices without serial
numbers can work fine on Windows. And I tested that long ago. My
question is how windows kernel identifies each of the identical USB
devices without serial number?
It’s interesting that we just had this conversation within the last
couple of weeks.
Windows generates a unique number, based on the physical location of the
device in the tree of all USB devices. So, a device plugged in to port
number 3 of a hub plugged into port number 2 of the 1st host controller
gets a different unique number than a device plugged into port number 2
of that same hub. That unique number is used instead of the missing
serial number.
That’s why you have to install a new driver when you move a non-serialed
device to a new port for the first time. As far as Windows is
concerned, it’s a brand new device that it’s never seen before.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim for the answer. Do you mean that if there is a serial number for
the device, then Windows will use the serial number (along with VID&PID)
instead of generating a unique number to identify that device? In other
words Windows will generate that unique number based on the physical
location only if there is no serial number for the device, right?
My other question is: Is there any way to retrieve that unique number that
Windows generated based on the physical location in the USB bus controller
upper filter driver? By sending some kind of query URB down? Thanks Tim.
On Fri, Sep 4, 2009 at 2:51 PM, Tim Roberts wrote:
> Michael Zhu wrote:
> >
> > This may not be related to the op’s question. Based on my experience I
> > support you on that multiple identical USB devices without serial
> > numbers can work fine on Windows. And I tested that long ago. My
> > question is how windows kernel identifies each of the identical USB
> > devices without serial number?
>
> It’s interesting that we just had this conversation within the last
> couple of weeks.
>
> Windows generates a unique number, based on the physical location of the
> device in the tree of all USB devices. So, a device plugged in to port
> number 3 of a hub plugged into port number 2 of the 1st host controller
> gets a different unique number than a device plugged into port number 2
> of that same hub. That unique number is used instead of the missing
> serial number.
>
> That’s why you have to install a new driver when you move a non-serialed
> device to a new port for the first time. As far as Windows is
> concerned, it’s a brand new device that it’s never seen before.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Michael Zhu wrote:
Thanks Tim for the answer. Do you mean that if there is a serial
number for the device, then Windows will use the serial number (along
with VID&PID) instead of generating a unique number to identify that
device? In other words Windows will generate that unique number based
on the physical location only if there is no serial number for the
device, right?
Correct. That’s why duplicate serial numbers are a problem. It’s
equivalent to having two devices in the same slot. Windows thinks they
are the same device. Madness ensues.
My other question is: Is there any way to retrieve that unique number
that Windows generated based on the physical location in the USB bus
controller upper filter driver? By sending some kind of query URB down?
Easily. It’s no great secret – it is your PnP device ID.
Here’s the PnP device ID for my Comfort Curve Keyboard, which does not
have a serial number:
USB\Vid_045e&Pid_00dd\5&183185a3&0&2
That 5&183185a3&0&2 is the serial number replacement. Through reverse
engineering, you can learn that the “5” indicates how “deep” you are in
the tree. I believe “4” is straight into the host controller. As you
add more hubs and composites in between, that number goes up. The
183185a3 is a pseudo-random number of some kind, which identifies the
“end” hub in some way. The final “2” indicates that I’m in port number
2 of that hub.
Here is the PnP Device ID for a USB disk drive, which does have a serial
number (0768184E0101):
USB\Vid_13fe&Pid_1a00\0768184E0101
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>device? In other words Windows will generate that unique number based on the physical location only
if there is no serial number for the device, right?
Yes.
I think the format of PnP IDs for popular buses like PCI and USB is documented in the WDK docs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Friday, September 04, 2009 11:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB Devices are displayed in device
manager Whereas USBView can retrieve it .
I think the format of PnP IDs for popular buses like PCI and
USB is documented in the WDK docs.
I don’t think so. At least Doron always say the format is undocumented
and shouldn’t be parsed. If something changed, it’d be a good news. If
you saw it in docs, send us the link, please.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, September 04, 2009 11:01 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB Devices are displayed in device
manager Whereas USBView can retrieve it .
Easily. It’s no great secret – it is your PnP device ID.
Here’s the PnP device ID for my Comfort Curve Keyboard, which does not
have a serial number:
USB\Vid_045e&Pid_00dd\5&183185a3&0&2
In addition, if above string is prefixed with
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum, it is the registry
path where device node data are stored.
The
183185a3 is a pseudo-random number of some kind, which identifies the
“end” hub in some way.
I’d recommend to search registry for this number (or for ParentIdPrefix
values). It shows how it is connected together.
I wonder if there is a documented way how to find a hub to which the
device is connected. From INF, coinstaller or the driver. Recently I had
a need for it (to detect some flakey hub) and had to use undocumented
info, parse string which shouldn’t be parsed etc.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
>Windows does …
Just a reminder to the less experienced folks that “Windows” is a whole
family of OS’s, and there ARE differences in behaviors between family
members. Usually I use notation like “W2K8 SP2” to refer to some more
specific family member.
I bring this up because of the current discussion about PnP id’s generated
from serial numbers. For example, PCI-e devices with serial numbers,
Pre-Win7 family members don’t seem to use the serial number in the PCE-e PnP
id, for Win7/W2K8R2 it does.
Asking if “Windows USB does…” is not an accurate question. Asking if WXP
SP2 or W2K8R2 behaves some way is more accurate.
Also note that a generic “Windows” will default to different values for
different people. For me, “Windows” means W7 or W2K8R2, unless specifically
qualified otherwise. My guess is for many Microsoft folks, “Windows” ==
W7/W2K8R2, because that’s what THEY have been working on for a couple of
years.
You might carefully consider if expending engineering effort on OS’s that
are becoming obsolete is a sound business decision. Certainly companies that
have down-level products keep selling them to down-level OS users, but
making new products early in the lifecycle curve will often tend to maximize
your return on engineering investment. Look at Apple, they just released a
whole OS version that no longer runs on machines older than 3 1/2 years (The
first Intel Mac was in January 2006).
Also an observation, If someone says “Linux does…”, my guess they are not
referring to a version that was released in 2001 (which is when Win XP was
released).
Jan
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Saturday, September 05, 2009 1:07 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] USB Devices are displayed in device
manager Whereas USBView can retrieve it .
Asking if “Windows USB does…” is not an accurate question.
Asking if WXP
SP2 or W2K8R2 behaves some way is more accurate.
You’re right but regarding USB IDs there doesn’t seem to be any change
from XP to Win7.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Jan Bottorff wrote:
I bring this up because of the current discussion about PnP id’s generated
from serial numbers. For example, PCI-e devices with serial numbers,
Pre-Win7 family members don’t seem to use the serial number in the PCE-e PnP
id, for Win7/W2K8R2 it does.
That’s good information, although this discussion was specifically about
USB.
Asking if “Windows USB does…” is not an accurate question. Asking if WXP
SP2 or W2K8R2 behaves some way is more accurate.
That’s technically true, although the practical fact is that the
operation of USB in Windows 7 is virtually the same as it was in Windows
98, beyond the numerous bugs that have been squashed.
You might carefully consider if expending engineering effort on OS’s that
are becoming obsolete is a sound business decision. Certainly companies that
have down-level products keep selling them to down-level OS users, but
making new products early in the lifecycle curve will often tend to maximize
your return on engineering investment.
This is an interesting point of disconnect between Microsoft and much of
the world that I see. A manufacturer that focuses strictly on sales to
OEMs can afford to concentrate on Windows 7, since that’s what the OEMs
will be selling. However, a majority of the Windows machines running in
the real world are running Windows XP, and no engineering manager who
plans to remain unemployed is going to create an add-in product that
does not work on the majority of Windows machines. I still have two
clients that want their drivers tested on Windows 98 Second Edition.
Look at Apple, they just released a
whole OS version that no longer runs on machines older than 3 1/2 years (The
first Intel Mac was in January 2006).
Apple has historically never been afraid to cut the ties on backward
compatibility. I would not necessarily argue that this was a tactic
worth emulating. I still have a tool in my bin directory that was
compiled in 1989, and it works today just like it did then.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>> I think the format of PnP IDs for popular buses like PCI and
> USB is documented in the WDK docs.
I don’t think so. At least Doron always say the format is undocumented
and shouldn’t be parsed. If something changed, it’d be a good news. If
you saw it in docs, send us the link, please.
for PCI:
http://msdn.microsoft.com/en-us/library/ms791082.aspx
for USB:
http://msdn.microsoft.com/en-us/library/ms791080.aspx
http://msdn.microsoft.com/en-us/library/ms791086.aspx
http://msdn.microsoft.com/en-us/library/ms791081.aspx
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
To Roberts , and all .
Thanks for the great efforts on this poster.
Currently this issue really happens on certain phones and usbhub!USBH_PdoRemoveDevice function is invoked to clean something up after the devices have been ready in device manager.
It’s not so simple as iSerialNumber-related issue , I think .
Now there are 2 questions from my side :
1 . why this USBH_PdoRemoveDevice function is invoked to clean up the configured device even after the device has been ready. during this period , we , along with the application ,do nothing except restarting it.
2 . Why are these devices in prepared state in device manager whereas USBView indicates that they are not ready ?
Due to this inconsistency, I have to SUSPECT something goes wrong in MS component . Under any circumstance, it’s supposed that we should not see this inconsistency , agree ?
Currently , I hope to continue to trace back who triggers it .
Here is the stack in that scenario :
usbhub!USBH_PdoRemoveDevice+0x19c
usbhub!USBH_PdoPnp+0x5b
usbhub!USBH_PdoDispatch+0x5a
usbhub!USBH_HubDispatch+0x4b
nt!IopfCallDriver+0x31
usbccgp!USBC_Pnp+0x12f
usbccgp!USBC_Dispatch+0x195
nt!IopfCallDriver+0x31
nt!IopSynchronousCall+0xb7
nt!IopRemoveDevice+0x93
nt!IopRemoveLockedDeviceNode+0x160
nt!IopDeleteLockedDeviceNode+0x34
nt!IopDeleteLockedDeviceNodes+0x3f
nt!IopDelayedRemoveWorker+0x4b
nt!ExpWorkerThread+0xef
nt!PspSystemThreadStartup+0x34
nt!KiThreadStartup+0x16
Since remove function is invoked in a system thread , I really run into another issue : how can I identify who posts this work item. Trying to get this information by setting conditional bp in ExQueueWorkItem and IoQueueWorkItem . But PC runs much slowly and this issue seems to disappear for the time-being.
Any suggestion ?
I mean any suggestion of locating who sends ? ?