Super Sarge
New Member
- Joined
- Jun 4, 2009
- Messages
- 1,734
- Thread Author
- #1
Please read, Even though I was not having the problem described in this article, I ran the fix and yes I had the old files instead of the new as stated.It will do no harm to check the fix will only work if your machine need it.
Excerpts from another forum..No credit to me.
I can say from my hands on experience that whether I install from the stand alone .exe or from Windows update the below described existed so I run the tool at the end of this article to fix it. Excerpts taken from another forum. No credit to me.
The Windows 7 SP1 USB Driver Bug (what it is and how to fix it)
This was a bug that was first noticed by a member of this forum, burfadel, in another thread. At first, I thought that this was just a minor bug in the SP installer, nothing to get too excited about. But then this bug bit me hard...
Who is affected by this bug?
Anyone who updates Windows 7 to SP1 using the executable installer (i.e., windows6.1-KB976932-???.exe).
Who is NOT affected by this bug?
Anyone who installed a new copy of Windows 7 SP1 using an official integrated ISO (and it looks like homemade slipstreamed integrated ISOs are okay, too).
Update: From the user reports in this thread, it seems that a small subset of users do not appear to be affected by this bug. I'm not sure what causes some users to be "immune" to this bug, but it does appear to be a minority.
What does this bug do?
Of the several USB-related driver files updated by SP1, three files, usbport.sys, usbehci.sys, and winusb.sys (note: not all hardware configurations use winusb.sys, so it is normal for it to be missing) were only partially updated; i.e., the SP1 installer only updated the "repository" copies of these files--i.e., the copies found in WinSxS and DriverStore. The "active" copies, found in System32\Drivers, are not updated (this is a bug with the installer). People who did a new installation using an integrated ISO are not affected (both the "repository" and "active" copies are 7601) (so this only affects a 7600->7601 update), and other USB-related driver files seem to be unaffected (e.g., the SP1 installer updates both the "repository" and "active" copies of usbhub.sys).
What is the impact of this bug?
For most people, this bug just means that they keep using the old 7600.16385 version of usbport.sys, usbehci.sys, and winusb.sys instead of the newer 7601.17514 version. So, for most people, it's not a very big deal.
However, there is a scenario where this would result in your USB2 (EHCI) controller becoming unsigned, which may result in all your USB2 devices being downgraded to USB1.1. This particular scenario happens when (1) you have KB976972 installed (this hotfix was distributed via Windows Update to anyone with a NVIDIA USB controller, such as people with nForce boards or first-generation ION) and (2) you ran a cleanup (either via the disk cleanup wizard or via "DISM /Online /Cleanup-Image /spsuperseded") after installing SP1. The cleanup operation removes all the hotfixes that had been superseded by SP1, so it deletes the KB976972 security catalog and all the "repository" copies of the KB976972 usbehci.sys. But the "active" copy of usbehci.sys is still the KB976972 version (the cleanup operation only deletes obsolete security catalogs and obsolete copies in the repository--it never touches the "active" copies of files because the SP1 updater should have replaced those already), so you are still using the KB976972 usbehci.sys (thanks to the installer bug) but the corresponding security catalog is gone (due to the cleanup), so Windows no longer has a signature for the file. The device manager does not immediately notice the problem (in my case, it flagged the controller as unsigned only after I plugged in a new USB device and rebooted), but once it sees the problem, it disables the EHCI (USB2) controller, thus forcing all the USB2 devices to use the legacy OHCI or UHCI (USB1.1) controller.
This scenario can play out in other ways too, of course. If you installed "private" hotfixes (those not released to WU), then you might have a hotfixed version of usbport.sys, in which case, installing SP1 and then doing a cleanup will result in ALL of your USB controllers becoming unsigned, which will basically disable USB on your system. To the best of my knowledge, I think usbehci.sys was the only driver affected by the SP1 installer bug that had a hotfixed version on WU (and that hotfix was not offered to everyone; my systems with Intel controllers never got that hotfix).
How do I fix this?
Update: There is a much easier (and safer, and fool-proof) way to fix the problem. kliu, the author of pendmove, ei.cfg remover, HashCheck, etc., has posted a tool to check for the problem, and apply the fix if the problem exists. 6.1.7601 USB Driver Update Fix/
Note: If you are experiencing a signature error problem, you may need to reboot one extra time since the device manager sometimes takes an extra reboot to notice changes in signatures.
Dell Studio 540, Windows 7 Ultimate, Intel Core 2 Quad Processor Q8200 (2.33GHz, 1333MHz FSB), w/
4MBcache, 4GB DDR2 SDRAM 800MHZ- 4X1GB DIM M, ATI Radeon HD 3650 256MB supporting HDMI
Excerpts from another forum..No credit to me.
I can say from my hands on experience that whether I install from the stand alone .exe or from Windows update the below described existed so I run the tool at the end of this article to fix it. Excerpts taken from another forum. No credit to me.
The Windows 7 SP1 USB Driver Bug (what it is and how to fix it)
This was a bug that was first noticed by a member of this forum, burfadel, in another thread. At first, I thought that this was just a minor bug in the SP installer, nothing to get too excited about. But then this bug bit me hard...
Who is affected by this bug?
Anyone who updates Windows 7 to SP1 using the executable installer (i.e., windows6.1-KB976932-???.exe).
Who is NOT affected by this bug?
Anyone who installed a new copy of Windows 7 SP1 using an official integrated ISO (and it looks like homemade slipstreamed integrated ISOs are okay, too).
Update: From the user reports in this thread, it seems that a small subset of users do not appear to be affected by this bug. I'm not sure what causes some users to be "immune" to this bug, but it does appear to be a minority.
What does this bug do?
Of the several USB-related driver files updated by SP1, three files, usbport.sys, usbehci.sys, and winusb.sys (note: not all hardware configurations use winusb.sys, so it is normal for it to be missing) were only partially updated; i.e., the SP1 installer only updated the "repository" copies of these files--i.e., the copies found in WinSxS and DriverStore. The "active" copies, found in System32\Drivers, are not updated (this is a bug with the installer). People who did a new installation using an integrated ISO are not affected (both the "repository" and "active" copies are 7601) (so this only affects a 7600->7601 update), and other USB-related driver files seem to be unaffected (e.g., the SP1 installer updates both the "repository" and "active" copies of usbhub.sys).
What is the impact of this bug?
For most people, this bug just means that they keep using the old 7600.16385 version of usbport.sys, usbehci.sys, and winusb.sys instead of the newer 7601.17514 version. So, for most people, it's not a very big deal.
However, there is a scenario where this would result in your USB2 (EHCI) controller becoming unsigned, which may result in all your USB2 devices being downgraded to USB1.1. This particular scenario happens when (1) you have KB976972 installed (this hotfix was distributed via Windows Update to anyone with a NVIDIA USB controller, such as people with nForce boards or first-generation ION) and (2) you ran a cleanup (either via the disk cleanup wizard or via "DISM /Online /Cleanup-Image /spsuperseded") after installing SP1. The cleanup operation removes all the hotfixes that had been superseded by SP1, so it deletes the KB976972 security catalog and all the "repository" copies of the KB976972 usbehci.sys. But the "active" copy of usbehci.sys is still the KB976972 version (the cleanup operation only deletes obsolete security catalogs and obsolete copies in the repository--it never touches the "active" copies of files because the SP1 updater should have replaced those already), so you are still using the KB976972 usbehci.sys (thanks to the installer bug) but the corresponding security catalog is gone (due to the cleanup), so Windows no longer has a signature for the file. The device manager does not immediately notice the problem (in my case, it flagged the controller as unsigned only after I plugged in a new USB device and rebooted), but once it sees the problem, it disables the EHCI (USB2) controller, thus forcing all the USB2 devices to use the legacy OHCI or UHCI (USB1.1) controller.
This scenario can play out in other ways too, of course. If you installed "private" hotfixes (those not released to WU), then you might have a hotfixed version of usbport.sys, in which case, installing SP1 and then doing a cleanup will result in ALL of your USB controllers becoming unsigned, which will basically disable USB on your system. To the best of my knowledge, I think usbehci.sys was the only driver affected by the SP1 installer bug that had a hotfixed version on WU (and that hotfix was not offered to everyone; my systems with Intel controllers never got that hotfix).
How do I fix this?
Update: There is a much easier (and safer, and fool-proof) way to fix the problem. kliu, the author of pendmove, ei.cfg remover, HashCheck, etc., has posted a tool to check for the problem, and apply the fix if the problem exists. 6.1.7601 USB Driver Update Fix/
Note: If you are experiencing a signature error problem, you may need to reboot one extra time since the device manager sometimes takes an extra reboot to notice changes in signatures.
Dell Studio 540, Windows 7 Ultimate, Intel Core 2 Quad Processor Q8200 (2.33GHz, 1333MHz FSB), w/
4MBcache, 4GB DDR2 SDRAM 800MHZ- 4X1GB DIM M, ATI Radeon HD 3650 256MB supporting HDMI
