burfadel if the processor arch is x64 it does not mean os arch is x64, because a user can have a x64 capable processor but still install an x86 os, in this case your script will fail because it will set the location to x64 files although the os is actually x86. so you should add another check (like if exist Program Files (x86) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node or other ways etc..)
burfadel: Your last cmd "USB KB2529073 Fix V4" worked on an x86 laptop after removing all references to other than x86 architectures. Thanks to the hint from tuvi123. It worked flawlessly and after reboot the new files were integrated. Thank you for the great work and patience. I hope this helps others with this issue.
Seriously guys...the MS issued KB works fine (as well as the other USB KB). I don't think it's happened yet, but this script is really putting your system in jeopardy of entering a bad state. When the system thinks you have a different file version than you have in system32\drivers, you could really open yourself up to some weird behavior.
If both updates are installed, the LDR versions should be utilised correct? If there really is no bug, then the USB fix wouldn't actually functionally change anything on the system so there would be no possibility of issues. So, in the statement just made, it would appear that in fact the wrong versions are actually utilised, in which case there is an issue with USB updatedness. Windows pre-Sp1 did not exhibit these file versions issues.
Thats interesting, Why do you think this will happen as the script only copies the latest copies of the USB drivers already installed by the updates into the drivers, which the MS update does not seem to do correctly? So I am interested as to why you think this will cause weird behavior?
If you just have clean SP1 and install the packages, you're probably on GDR, since these packages have both LDR and GDR. There isn't a change to the versioning scheme in SP1, there was only a copy problem in the SP1 installer, which is fixed in the patches. It DOES do it correctly, the behavior you guys are expecting is the incorrect behavior. You're changing the correct behavior to the incorrect one. It's not an issue with what the script does so far, but for literally EVERY USB update that will ever come out on Win7, you guys are going to say it's working wrong (when it isn't), and you could potentially cause issues with your USB drivers.
KB2528984 definitely throws off the USB updates. The next USB update (if one is needed) and subsequent updates will have the proper behaviour as long as all USB files are included and they are of later versions than the current updates. Its updated like KB2528984 where some files are omitted due to it being not directly related to the update (like USBuhci.sys) that stuffs up the USB files. That said, it appears there are also instances where KB2529073 doesn't update all the filess like it should either. It could be the situation such as a 'in certain circumstances' situation. I'm also curious about KB2533552 as some people say that the files in the system32 folder are still 17514 (like pkgmgr.exe) after the update, yet the same files in the winsxs folder at the correct 17592 ones... is it proper behaviour for updates not to update the files? The following files that are newer in kb2533552. poqexec.exe dpx.dll cmiadapter.dll apircl.dll CntrtextInstaller.dll PkgMgr.exe wdscore.dll cmiv2.dll wbemcore.dll wmicmiplugin.dll CbsCore.dll smiengine.dll drvstore.dll smipi.dll wcp.dll wrpint.dll which one would expect the files in system32 to reflect the amd64 winsxs, and the files in syswow64 to reflect x86 folder...
afaik, none of the files from KB2533552 are used from the system32 folder, the sxs version is used. If the situation where 2529073 doesn't update all the files is where you have the other USB update installed, then I would expect it (or, if you have one of the latest-gen Intel chipsets where there isn't a USB 1.1 controller).
I don't mean to add a completely noobish post to this thread, but is there any way to update the needed drivers to restore USB functionality from another computer? My issue is that when I boot up I get put at the login screen but since I only have USB keyboards and mice, I can't login to run the excellent tools you guys are pumping out, and therefore am stuck. Could I possibly pull out my system drive from the desktop that is having the issue, slap in in an external enclosure, plug it into my laptop and manually modify the drivers so that the system can utilize them again? If so, how would I get the proper drivers by themselves and know specifically where to put them? Assuming my laptop (which is running the same version of Win 7 Ultimate x64) is working properly, could I just locate the couple USB-related files outlined in this thread and copy them over to the same directory on my desktop drive?
You can easily boot from Win 7 DVD into WinPE, run cmd and copy/replace files where needed ( if present ). Maybe you consider using a restore point, or a ERD Boot disk built with DaRT an uninstall the fix. I just would use my USBtoPS2 adapter
Enigma256 please update First of all, many thanks for your very helpful post. However, the tool didn't work for me so I had to go the "dirty way" by batch-file. Please note: In some circumstances (as in my situation) it is not necessary to update usbehci, usbport and winusb, but to update usbstor.sys. I edited the batch file, ran it and voila, my external harddrive is back again! Thanks again, tiberiusk.
KB2581464 is the latest update currently available that involved usbstor.sys. It updated usbstor.sys to: (GDR) 6.1.7601.17650 (or) (LDR) 6.1.7601.21771 with the LDR being installed if you have a previous usbstor.sys related update installed or have force installed the LDR version. The USB driver update bug meant the files weren't updated like they were meant to be, and this has been somewhat rectified with update KB2529073. However, if you want the later versions of some of the USB files you need to install KB2528984, which doesn't include all the USB files and actually puts the wrong files back into place! So although the original scripts were to rectify the pre-KB2529073 issue, the 'USB KB2529073 Fix v4a' script is still required if you have KB2529073 and KB2528984 installed. Having a look locally, the USB files are correct with all the updates installed (and the script used with both of those updates installed), but thats with using the updates from the hotfix repository. If you have both KB2529073 and KB2528984 installed, you still do have the USB driver bug issue! The issue will still be prevalant until such times Microsoft releases a full update like KB2529073 with file versions later than build 6.1.7601.17591/6.1.7601.21700, and in the future include ALL the USB files updates to those versions.