| Date: | November 10, 2004 / year-entry #389 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041110-00/?p=37343 |
| Comments: | 66 |
| Summary: | You may have noticed that if you take a USB device and plug it into your computer, Windows recognizes it and configures it. Then if you unplug it and replug it into a different USB port, Windows gets a bout of amnesia and thinks that it's a completely different device instead of using the settings... |
You may have noticed that if you take a USB device and plug it into your computer, Windows recognizes it and configures it. Then if you unplug it and replug it into a different USB port, Windows gets a bout of amnesia and thinks that it's a completely different device instead of using the settings that applied when you plugged it in last time. Why is that? The USB device people explained that this happens when the device lacks a USB serial number. Serial numbers are optional on USB devices. If the device has one, then Windows recognizes the device no matter which USB port you plug it into. But if it doesn't have a serial number, then Windows treats each appearance on a different USB port as if it were a new device. (I remember that one major manufacturer of USB devices didn't quite understand how serial numbers worked. They gave all of their devices serial numbers, that's great, but they all got the same serial number. Exciting things happened if you plugged two of their devices into a computer at the same time.) But why does Windows treat it as a different device if it lacks a serial number and shows up on a different port? Why can't it just say, "Oh, there you are, over there on another port." Because that creates random behavior once you plug in two such devices. Depending on the order in which the devices get enumerated by Plug and Play, the two sets of settings would get assigned seemingly randomly at each boot. Today the settings match up one way, but tomorrow when the devices are enumerated in the other order, the settings are swapped. (You get similarly baffling behavior if you plug in the devices in different order.) In other words: Things suck because (1) things were already in bad shape—this would not have been a problem if the device had a proper serial number—and (2) once you're in this bad state, the alternative sucks more. The USB stack is just trying to make the best of a bad situation without making it any worse. |
Comments (66)
Comments are closed. |
But why make it so difficult to clean up the mess?
On Windows 2000 the control panel applet was "Add/Remove hardware", which allowed you to see all the hardware devices installed so you could remove these redundant entries. On XP it changed to just "Add Hardware" which doesn’t.
What was the reason for this change?
Device manager hides devices that are no longer connected, even when "Show hidden devices" is on. The workaround is to set an environment variable DEVMGR_SHOW_NONPRESENT_DEVICES but this is one of those tips thats not widely know and it can get frustrating trying to fix problems.
Most people would be surprised at how many entries show up for "HID compliant mouse" or "Generic Volume" when they see all the redundant copies that have been installed, especially on portable computers.
It isn’t so much of a problem so long as its only unused device registrations, the issues come where some other resource is being allocated.
For example I had a USB->Serial cable for syncing my mobile phone with my PC. Every time I plugged it into a different port it reinstalled the drivers and allocated itself a new COM port. Eventually the com port number of the cable went outside the range of ports that the phone sync software would accept. I couldn’t uninstall the devices and reclaim the COM ports because the devices didn’t show up in device manager
The real question is is it really necessary to launch the Found New Hardware UI in this scenario, or in the scenario that you’re plugging in a device with a different serial number?
I really don’t see any user value in notifying them that they’re either (a) plugging the device into a different port [or even more subtly, changing the topology somehow without touching the device in question]; (b) they’re plugging in a new serial number device.
After you’ve installed the driver the first time I would expect it just to work.
I was about to post exactly what ‘ac’ did, but got there too late. I don’t have a problem with the assumption that it’s possibly a different device, but the "please feed me the installation disks again" that occurs, especially when you have lots of USB ports.
This whole reenumeration thing has always bugged me. It takes far too long.
I came across a type of device that had the "same serial number" on every device problem. I learnt three things:
1. There’s nothing in the USB specs I could find that require the serial number to be unique. It is only common sense that dictates so.
2. Windows doesn’t mind if you plug two equivalent devices with the same serial number into the machine if you plug them into USB ports that are peers of each other (i.e. they are connected directly to the same hub).
3. It is only Windows that gets upset about this. Other operating systems that have a far less heavyweight "plug and play" mechanism work fine.
We have been having an exciting time with USB devices due to exactly this issue of devices having the same serial number. We embed these third-party devices in equipment that we manufacture and it has been a real headache.
However I recently discovered that Windows has a ‘magic’ setting in the registry to help us deal with rogue manufacturers who assign a single serial number to all instances of a particular product. You know that you have such a problem product when you plug two of them into Windows XP and it reboots as soon as the second device is enumerated. To work around this you can create a binary key in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlUsbFlags that has the form IgnoreHWSerNumVVVVPPPP. Here VVVV is the 4 hex digits of the vendor id and PPPP is the 4 digits of the product id. Creating this and setting the value to 01 means that windows will ignore the serial number and act as if the device never had one at all. Doing this causes windows to then use the connection number to discriminate between different devices which works fine.
Yeah, I guess they thought that calling it a serial number implied the need for uniqueness…
My gripe: for some reason, my trashy work pc drops and redetects my usb mouse, then demands driver files for it, rather than just using the generic driver, or at least leaving me be.
Sorry Raymond, I know it’s not your bitch, but you brought it up ;_)
What I don’t understand about the situation where 2 devices on seperate hugs that have the same serial number causes windows XP to throw up and reboot, is why it doesn’t simply fall back to the situation where it had no serial numbers. As Pat said earlier, there is this magic registry key to make things work, but why doesn’t windows automatically ignore the serial number if there is a contention, and act like it’s a new device?
It just seems like all the hard work has been done.
btw, I’m not going to be as nice and PC as Pat (we work together) The devices we have problems with are Phillips USB webcams.
What annoys me the most is that my normal user does not have the rights to install drivers, therefore I have to either remember which port I’ve used last time for the device or, as an administrator, plug the device into every port at least once.
Raymond, I wasn’t suggesting that the first device be made track-by-connection automatically, but when the second device is plugged in and windows detects that it appears to have two identical devices, surely it is not beyond the wit of man to say, "uh-oh, we’ve got a new device which appears to be identical to a previous device, perhaps we should track this one by connection", unless there is some implementational issue I’m not aware of which makes this impossible. Surely crashing is a sub-optimal solution to the problem.
My guess is that the term came from the OSI model, which traditionally depicts the layers of its protocol stack as boxes stacked on top of each other:
http://en.wikipedia.org/wiki/TCP/IP_stack
Rather off-topic:
What is the origin of the word "stack" in phrases like "USB stack" and "TCP/IP stack"? What is stacked on top of what?
@Marcel: That was the most anoying part of the story for me also. But it seems to have been fixed. Now, windows asks for an admin username/password before opening the add/remove dialog! I never noticed that before so maybe it was an SP2 feature? Good work Microsoft.
"Bad hardware will always win."
If necessary, it will even play dirty to win. The installer for the PQI I-Stick USB circumvents the "driver is not signed" dialog by sending it a click on the OK button. Too bad they didn’t work as hard on the actual driver, it blue-screens XP SP2 because of a bad kernel memory pool header.
"… then reattach both devices using the drivers that you already have…"
which causes the customizations for the first device to be lost since it was tracked by SN, but that device is no longer being tracked by SN. Is that acceptable?
What I’d like to know is why does Windows, in this situation, always insist on the original install disks again? It already has the INF file and the drivers. If it comes up complaining that it can’t find a particular driver file, and you KNOW it’s already there in System32, you can just point it to that file and it will happily install it over itself. So why can’t Windows check if the file is already present before asking for it again?
I have no idea. That bugs me too.
Well you work for Microsoft – ask someone :)
Hate to join in the USB team bashing, but expecting unique serial numbers in cheap hardware is crazy. Doing it preoperly requires that the device has a E2PROM, or fusible links or some other form of writeable, non volatile memory that is written just after manufacture, and that would add to the cost of the device.
Tom – Dallas/Maxim make a 1-wire chip just for that purpose.
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2903
1000+ of these are $0.61. I’m sure if you were selling in real volume, you could get a better deal.
If your device uses an FPGA (most do), then you’ve got even less of an excuse.
My little story of how this drives me nuts is that I tried to configure my USB flash drive(s) to mount in a directory on an NTFS partition so they wouldn’t get essentially random drvier letter assignments.
But then when I plugged the drive into another port, it would show up as a new drive letter, effectively rendering my idea useless.
So, I’d like to sort of second Rowland Shaw’s question: is there a way to force a USB device to get identified uniquely via some other mechanism? In the case of a USB Mass Storage device, I’d think that the volume serial number might be sufficient (at least for the purpose of determining where it gets mounted into the filesystem). In this case, I don’t really care if the USB bus drivers think it’s a completely different device, I just want the volume mounted where I told it to be mounted.
That would be nice wouldn’t it, but it also creates a chicken-and-egg – you don’t know that it’s a disk drive with a volume serial number until after you’ve assigned it an identity and handed it up the stack to the block device driver, but you can’t assign it an identity until you read its volume serial number (which only the block device driver can do)…
So is this what Microsoft was thinking: "If it worked the way people expect, there would be exceptions to the rule, and that’s hard to program. So, instead, we’ll just make it work according to a consistent set of rules that inconvenience almost everybody."
How does Apple deal with this? I’ve never heard any complaints from that side of the aisle.
Imagine, you plug in a second device with the same serial number, and the following insane dialog pops up:
"The device you just inserted has the same serial number as a device you already have. How would you like to proceed:
[] Ignore the second device. (Note that due to the unpredictability of USB device enumeration, the device that is ignored may change each time the bus is re-enumerated.)
[] Use both devices, associating settings with the USB port rather than the device serial number. (Previous settings will be lost since the identity of the first device is changing. Make sure no programs are using the first device because it will be removed with its old identity and reinserted with its new identity.)
[] Use both devices, assigning settings to each device in the order it is found. (Note that the order may change each time the bus is re-enumerated.)"
Most people will say, "What do you mean it has the same serial number? I can see the number on the sticker on the outside of the box and they’re clearly different." That’s assuming those people even read the dialog at all. Which they won’t.
Isn’t it funny that when Raymond makes a post like this, people say "why doesn’t Windows do a better job of dealing with this buggy hardware?"
Yet, whenever he posts about odd little application compatibility hacks that have been done to make buggy third-party apps work on Windows, there’s always a bunch of comments saying "Why does Microsoft do hacks to fix other people’s buggy software? Let ’em rot!"
Just an observation.
"there is this magic registry key to make things work, but why doesn’t windows [do it automatically]?"
I thought this was obvious: Because the Research department has yet to perfect clairevoyance.
When you plug in a device with a serial number, Windows needs to know, "Gosh, is this a device whose serial number I should ignore? I should ignore it if the user will ever plug in an identically-numbered device in the future." PnP has to decide at the time you install the *first* device whether it should be a track-by-serial-number device or a track-by-connection device. This requires a degree of predictive power (and negation of free will) that modern science has yet to develop.
If Windows was consistent, maybe the responses would be too.
I’m sorry, I don’t normally do Windows bashing, but that just sounds like an excuse to me Raymond.
If XP reboots when you insert two devices with the same serial number, it’s a bug.
Windows does not need to know when you plug the first device in if it needs to ignore the serial number. It needs to know when you plug the *second* device in.
If this is difficult to do with the current code, then it’s a coding fault. Unforseen yes, but these things happen. Trying to say that the Research department would need clairevoyance is just avoiding the problem.
I’m not trying to say that they should have anticipated this problem would occur, that’s impossible. What I’m saying is that there should be a way to fix it. "It can’t be done with the current code" is not an excuse.
I agree that rebooting is just plain bad. Then again, how hard should software try to protect itself against bad hardware? Bad hardware will always win.
The issue is how hard it is to convert a track-by-serial-number device to a track-by-connection device *on the fly*. I don’t know the answer. (You have to convert; you can’t have one track-by-serial-number device and one track-by-connection device with the same serial number, or you run into exactly the same problem described in this article!)
Simon
I’m thinking more about $30 devices like USB to Serial cables based on commodity ASICs like this
http://www.hitachi-hitec.com/jyouhou/prolific/ds_pl2303x_v11.pdf
This chip does allow you to have a serial number, but only if you have an external e2prom. All the cables I’ve seen don’t have a unique ID’s however, and I get the same symptoms as Edward.
I don’t think the problem is the cost of the prom (which is probably < $1 as you point out), it’s more that having it requires that someone program the unique IDs.
On the other hand, you can skip the prom and the manufacture without any programming. 99.99% of the people that buy it won’t ever notice any difference, except that the promless cable might be a bit cheaper.
Cheap broken hardware tends to drive out the slightly less cheap working stuff unless it’s completely unusable.
"Hate to join in the USB team bashing, but expecting unique serial numbers in cheap hardware is crazy. Doing it preoperly requires that the device has a E2PROM, or fusible links or some other form of writeable, non volatile memory that is written just after manufacture, and that would add to the cost of the device."
Sorry, but it is perfectly reasonable to expect this. Many USB devices already have some kind of EEPROM already built in, which stores the vendor ID and device ID.
Things like ethernet cards have unique MAC addresses, this should be no different.
Raymond, question…
Can a USB device without a unique serial number get WHQL certified?
<i>I agree that rebooting is just plain bad. Then again, how hard should software try to protect itself against bad hardware? Bad hardware will always win.
The issue is how hard it is to convert a track-by-serial-number device to a track-by-connection device *on the fly*. I don’t know the answer. (You have to convert; you can’t have one track-by-serial-number device and one track-by-connection device with the same serial number, or you run into exactly the same problem described in this article!)</i>
It’s already been pointed out that the spec doesn’t require a unique SN, so it’s not technically bad hardware. You should either deal with the problem or fail safe. Rebooting due to a properly functioning device showing up is unnacceptable.
The fix for duplicate SNs is fairly straightforward – if a second USB device with an identical SN is added to the system, add the product id to the list of known funky hardware, then reattach both devices using the drivers that you already have.
Observer, I’m sure windows would be infinitely consistent, if you were willing to wait a decade between releases and/or pay thousands of dollars for each copy of XP. Remember, time, money, and completeness, you can often have two but very rarely all three.
Tom, that may well be what happened in cases like this.
"PnP has to decide at the time you install the *first* device whether it should be a track-by-serial-number device or a track-by-connection device."
Is there anyway to force it the other way around (on a per device basis)? My situation is that XP is convinced I have 3 Canon Eos 300Ds. I wish I did, but as the device (presumeably) doesn’t have a serial, it’s a bit of a pain to remmeber which USB port it went in last (giving three different autorun settings and other fun side-effects)
11/10/2004 10:59 AM Raymond Chen
> I have no idea. That bugs me too.
It’s a relief to see that at least part of Microsoft is aware of this particular issue and is even bugged by it. But, are you also bugged by the fact that at least 7 years have passed without this being fixed?
Though actually a portion of it has been fixed. In Windows 95 and/or 98, if the keyboard was plugged into a different USB port than it used to be plugged into, then Windows demanded the driver disk and demanded that the user use the mouse or keyboard to click "OK", but Windows didn’t recognize the click on "OK" because the keyboard was plugged into….. And it only got that far if the user didn’t have to input a password and click "OK" or "Escape" to get past a login screen. (By the way, this is on computers that don’t have PS/2 ports, except for the keyboard’s internal PS/2 hub where the mouse plugs into the keyboard. The advice in some KB articles to use your ordinary keyboard to log in, or whatever, is laughable.) Anyway, this part of it is fixed in Windows XP and I think maybe in 2000 too, at least Windows gets as far as recognizing a keyboard by itself.
Now for comparison, do you know why PCMCIA drivers don’t have a similar problem? A device that used to be plugged into PCMCIA slot 0 can be plugged into slot 1 and its existing drivers will take charge immediately. Sure PCMCIA is older than USB, but that doesn’t mean it took more than 7 years to solve. This much of PCMCIA handling even worked in the original release of Windows 95. It even worked for hard disks (reading and writing worked as long as you hadn’t used Windows 95’s fdisk command over PCMCIA).
http://www.microsoft.com/whdc/device/storage/usbfaq.mspx
Q: Must a USB storage device contain a unique serial number?
Yes. To comply with the USB Mass Storage Class Bulk-Only Transport Specification, all USB storage devices must contain a unique (12 digits or longer) serial number, represented as a UNICODE string. Refer to section 4.1.1 of the USB Mass Storage Class (Bulk-Only Transport) specification. (http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf)
lazybones » USB nuts
Perhaps the reprompting is by design? To make sure that you have the version of the driver that came with the OS, it has to go and check the version that came with the OS to see if they match. I’m just guessing. (Otherwise you can get into the state where the device is permanently toast because a bad copy of the xyz.sys driver got onto your machine. If PnP tried to short-circuit the driver install, it would say, "Oh, look you have an xyz.sys driver already, I don’t need to install it." Even though your xyz.sys driver is a bad one. Like I said, I’m just guessing.)
Joe – all the Mass Storage class USB devices I’ve seen have a serial number.
Mind you if the mass storage class is an ATA bridge it would be easy to generate one from he ATA Identify Device command – just return a CRC of the data you get back from the device.
Myron: Yes, if even a £2 (er, $4) Ethernet card can have a unique MAC it doesn’t seem unreasonable to expect USB devices to have real serial numbers if they have them at all.
I suspect that the identical serial numbers are being used as a cheap kluge to make Windows use the same settings when the device is moved t another port, and the manufacturers just don’t care about users with more than one – though I’d have thought they’d be happy to sell several devices to the same user.
Tom/Pat: On this PC running Windows XP SP2 there’s an ignore-serial-number entry in the registry already for a Philips webcam (PCA645VC according to the ID list at linux-usb.org) even though no such device has ever been near this PC.
"We do have problem when we manufactured some devices with unique serial number. The final test become really slow because of the repeating driver installtion. You can image how frustrated the QA guys were."
I’m not sure I believe you. The companies that make this junky hardware really have QA? :-) BTW, was your driver WHQL certified or did you work around that problem somehow?
In any case I think you have the inconvenience equation wrong. Better to inconvenience a couple of QA guys than a couple of thousand customers.
QUOTE
Tom/Pat: On this PC running Windows XP SP2 there’s an ignore-serial-number entry in the registry already for a Philips webcam (PCA645VC according to the ID list at linux-usb.org) even though no such device has ever been near this PC.
QUOTE
Is that the same as this webcam? There are problems on Linux too:
http://www.smcc.demon.nl/webcam/
Interestingly, there’s a common theme. Philips use a light weight compression algorithm to get a decent frame/rate resolution with a cheap microcontroller and USB 1.0.
Not unreasonably they want to keep this proprietary, but allowed someone to write a binary only Linux driver under NDA with the decompression code. This seems to be a violation of the linux equivalent of hardware compatibility guidelines.
From your comment it looks like they skipped the serial number too.
The cameras work though – Philips can probably live with not having a Linux driver in the kernel, and the ever OEM frendly Microsoft seem to have added a registry entry to handle the bogus serial number. And they sell like hot cakes.
Tom, we know they sell like hot cakes. Pat has 4 on his desk right now! I think we are currently using the pcvc8xx series (toUCam II).
Raymond, I don’t think that USB device enumeration is quite as random as you were sugesting, or else, if you were using devices which had no serial numbers and they were randomly reassigned when the bus was re-enumerated (like when the pc rebooted) the driver would be re-installed, when in fact it is not. What we have found is that if you plug a serial-number-less device (either real or forced) into a port on a given hub, then any identical device on that port on that hub will be given the same device ID, regardless of what order devices are plugged in or found. It may not be specced that way but it appears that in fact ports always enumerate in the same order. I guess things might be different if you plug an external hub in somewhere though.
WHQL certifies *drivers*, not *devices*. I don’t know anything about WHQL-certifying USB drivers, having never done one, but I suspect the answer is that WHQL doesn’t care so much if the hardware behaves poorly, but only if the driver does.
Tom M: That’s because the device (lacking a serial number) is being tracked by port.
Raymond, if you had a toasted driver all you had to do is go to Device Manager, show non-present devices (which Microsoft decided to hide for some reason) and uninstall. The next time you plug your device in you will be asked to install new driver since the old one would be gone.
I thought that just uninstalled the device but left the driver.
At any rate, that’s not what a typical user is going to do. If they have a problem with a device, they’re going to unplug it and replug it. They’re not going to go to this "Device Manager" thing and check some obscure options…
No they’re not, but if they plug it in back in the same port they won’t get prompted for a new driver anyways so they won’t have a chance to fix it anyways. That’s why I missed the point of your thought on why Windows asks you for the driver even when it already has it.
As for Device Manager not showing drivers – it does, if you unplug a device (be it from USB or any other bus) it’s still shown, as "Device is not present" and you can unistall (or update) the driver even when the device is not connected.
Edward,
I have your issues way beat. I do cell phone software for fun (currently on my desk are 13 cell phones and 17 data connectivity cables). Some cell phones are composite devices and present two interfaces, and consume two COM port numbers.
On XP you can’t access com ports above COM9 without using the \?COM99 convention. Given my plethora of cables, how many phones or usb to serial cables don’t have serial numbers, and the 10 or so USB ports I use (two on case, two 4 port hubs), I regularly end up with COM numbers in the 30’s.
Every now and then I have to go into the registry and delete all of them. That requires wiping out several keys and hierarchies in several places. It is unbelievable how many different places record what the COM number assigned to a particular device is.
And just to make my life more fun, I have several different device drivers for some phones. (It would appear to be rocket science to make non-buggy USB modem or serial drivers).
Joe,
Thanks for the link. I poked around the WHDC site, but somehow I missed that page.
Use WHQL-approved hardware/drivers, and life is good. If you install something that isn’t WHQL-certified, then buyer beware.
11/10/2004 10:59 PM Steve Dispensa
> WHQL certifies *drivers*, not *devices*.
Ooh. Then are there any plans to establish a WSQL that will certify devices?
11/11/2004 3:15 PM Anonymous Coward
> On XP you can’t access com ports above COM9
> without using the \?COM99 convention.
Yikes. Just yesterday I put together a machine that’s going to need them, and COM3 through COM12 are showing up properly in Device Manager, and I didn’t guess I was going to have to play games in the calls to CreateFile(). I noticed that COM10 and above aren’t reserved device names in MS-DOS commands, but adding a colon still got it recognized as a device name. I guess there’s something else getting in the way at a lower level. Thank you for the warning.
I think USB is a pain.
One of my most common USB problems is my scanner (A Microtek X12USL), sometimes (without removing the cable) it is converted into an unknown device. Getting it recognized again is a huge task, involves a lot of cursing, several reboots, etc. Same for my Logitech wireless desktop receiver. Of course the scanner allways worked when plugged in via SCSI, and the Logitech receiver works on PS/2. My Printer (a HP 970 Cxi) works fine when plugged via Parallel Port, but is a pain when plugged via USB.
The only devices that work fine (and provide a real advantage) on USB are USB mice ;-) and USB attached storage devices.
"Use WHQL-approved hardware/drivers, and life is good. If you install something that isn’t WHQL-certified, then buyer beware. "
Unfortunately, that’s simply not true in practice; WHQL-approved drivers on Designed for Windows (or whatever the badge is) hardware can still shit the bed with alarming regularity.
One question, and I’m not sure who should answer: is there ever a situation where you would want two of the same device to have different drivers?
The second thing is a feature request: how about a simple wizard style cpl gadget that allows management of device-driver relations? I’m sure that stuff is accessible already, but it’d be easier to reinstall drivers with something like this, especially if windows stopped hammering me with demands for drivers for my mouse (which I roundly ignore)
The whole windows driver model is so bizarre. The way that USB and/or PCI devices are enumerated and configured, I could in theory have a different driver for each different device instance.
However, take for example my two nVidia cards. All the nVidia drivers would install "nv4.sys" into system32. So, while I could *try* and use different drivers, I can’t really.
As regards pauls assertion that its somehow MSs fault. That makes no sense. Or does it. Clearly if you cant afford to manufacture the device with unique serial numbers, there is an option :- use no serial number at all.
The problem with that is the Windows USB stack insists on tracking each device uniquely, either by serial, or by port. Which inconveniences users when they accidentally plug the device into a different port and the OS demands the driver disk *again*. Given that probably 90% of the companies customers are going to own a single device, fudging identical serial numbers gives that 90% a better experience while inconveniencing 10%.
This touches on my most recent pet peeve with SP2 – Add New Hardware asking if it can access the internet to get a new driver. I support cell phone data functions, and I’ve lost track of the number of problesm I’ve solved by telling people not to cancel that dialog, just select "Have Disk". These are often people that are instlling the device that will allow them to connect to the internet; so they look at the dialog box that asks them to connect, and press cancel, because they’re not ready yet. And of course, it borks the entire process (the drivers don’t get installed, cats and dogs live together, etc)
I bought an i-river portable hard disk for music downloading. After setting up the drivers, I unplugged it, but when I returned the computer would not recognise the device in the same USB port, so I tried the other one which worked. The next time I tried to connect it niether port recognises it! I’m a little lost here I thought XP enabled plug and play. Can anyone help me?
为什么把同一USB设备插到不同的USB口上Windows有时会把它看成不同的设备，而要求再次安装驱动程序
PingBack from http://tim.cexx.org/?p=422
PingBack from http://rtshiva.com/2009/05/19/usb-specification-and-windows-limitation-on-serial-numbers/