Error Code 52 – USB ports not recognizing connected USB devices stating that “Windows cannot verify the digital signature for the drivers required for this device”
Original Title: Error Code 52 – USB ports not recognizing connected USB devices
I have recently purchased a new laptop with Windows 7 and had no initial problems connecting USB devices (mouse, hard drive, camera etc.) to the ports. Since installing a number of windows updates none of my USB ports will now recognize any hardware that is connected to them.
The error code is quoted as follows “Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52”.
I have been into Device Manager and notice that each USB icon has a yellow exclamation mark icon next to it. I have uninstalled each USB port and scanned for hardware changes which has no positive affect. I have also tried to ‘Update driver software’ in device manager and again this tells me that the driver is up-to-date for each USB port.
ANSWER
Boot into Advanced Boot Options and disable driver signing checking.
The Advanced Boot Options screen lets you start Windows in advanced troubleshooting modes. You can access the menu by turning on your computer and pressing the F8 key before Windows starts.
Disabling driver signature enforcement has helped a lot of users in fixing the issue.
You may also delete the USB “Upper Filter” & “Lower Filter” Entry and check if that helps.
Before we go any further, please first backup the Registry.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
How to back up and restore the registry in Windows
http://support.microsoft.com/kb/322756/
1. Click “Start”, type “regedit” (without quotation marks) in the “Search” bar and press Enter.
Note: If UAC (User Account Control) pops up, please accept it.
2. Right click “Computer” (the root node) in the left pane, click “Export” under the “File” menu, choose “All” under “Export range”, and select “Desktop” in the “Save” in box and type backup in “File Name”. Click “Save”.
Note: The backup file is on the Desktop and named backup.reg. We can simply restore the registry by double-clicking the backup.reg file.
3. Click “Start”, type “regedit” (without quotation marks) in the “Search” bar and press Enter again.
4. Locate the “UpperFilters” value under the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36FC9E60-C465-11CF-8056-444553540000}
5. On the “Edit” menu, click “Delete”, and then click “OK”.
6. Locate the “LowerFilters” value under the same key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36FC9E60-C465-11CF-8056-444553540000}
7. On the “Edit” menu, click “Delete”, and then click “OK”.
8. Quit Registry Editor and restart the computer.
Second Additional Solution
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.
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.
I strongly recommend using the tool above instead of the old ways.
For reference, here are the old ways of fixing the problem:
——————————— Old Methods ———————————
There are two ways to address this issue. The easy but messy method. And the (slightly) harder but much cleaner method…
(BTW, obviously, both of these methods assume that you have already installed SP1.)
Easy but messy: Go into the Device Manager and delete your USB controllers. Reboot. When you reboot, Windows will reinstall the controllers that you deleted, and it will use the “repository” copies when it does this, thus updating the “active” copies.
The reason this is messy is the way in which Windows serializes and identifies devices. Windows will treat these as “new” controllers, and all the devices connected to them as “new” devices. So all of your existing USB devices will be reinstalled. Depending on how many USB devices you have and what type of device they are, this could either be a very minor nuisance or it could be a major headache. For example, if you have a USB TV tuner, Windows will see this as a new, separate TV tuner, and Media Center and other TV tuning apps will have you run through the entire TV signal setup again for your “new” tuner.
The proper (and recommended) method: Instead of something as crude and blunt as nuking your controllers, I prefer to tackle the problem with surgical precision.
———————————
Update: There is an alternate batch file that does extra checking posted in post #65 by MikeRepairs.
———————————
1) Download the (open-source) pendmove tool (the author was even kind enough to fix a minor bug in his tool for me today, so kudos to him), and copy the executable (you MUST use the 64-bit version if you have 64-bit Windows) into C:\Windows\System32 (…or anywhere else in %PATH% …or you could edit the batch file below to reference the path to pendmove)
(BTW, the reason I use pendmove instead of the Sysinternals MoveFile tool is that MoveFile does not work if your Windows is 64-bit because it can’t deal with the WOW64 file system redirection layer; if you have 32-bit Windows, you can substitute pendmove with MoveFile if you want, but for 64-bit users, pendmove is your only option.)
2) Run this batch file:
@echo off
echo Reminder: This must be run from an elevated command prompt!
pause
if ["%PROCESSOR_ARCHITECTURE%"] == ["x86"] goto x86-32
if ["%PROCESSOR_ARCHITECTURE%"] == ["AMD64"] goto x86-64
echo Invalid PROCESSOR_ARCHITECTURE!
goto end
:x86-32
set SourceRoot=%SystemRoot%\winsxs\x86_usbport.inf_31bf3856ad364e35_6.1.7601.17514_none_bfc9c95e61cfba61
set SourceRoot2=%SystemRoot%\winsxs\x86_winusb.inf_31bf3856ad364e35_6.1.7601.17514_none_f9fc4e7173e3735c
goto start
:x86-64
set SourceRoot=%SystemRoot%\winsxs\amd64_usbport.inf_31bf3856ad364e35_6.1.7601.17514_none_1be864e21a2d2b97
set SourceRoot2=%SystemRoot%\winsxs\amd64_winusb.inf_31bf3856ad364e35_6.1.7601.17514_none_561ae9f52c40e492
goto start
:start
pushd %SystemRoot%\System32\drivers
copy %SourceRoot%\usbehci.sys usbehci.sys.new
pendmove usbehci.sys.new usbehci.sys
copy %SourceRoot%\usbport.sys usbport.sys.new
pendmove usbport.sys.new usbport.sys
if exist winusb.sys (
copy %SourceRoot2%\winusb.sys winusb.sys.new
pendmove winusb.sys.new winusb.sys
)
popd
echo Now you need to reboot.
:end
pause
3) Reboot (if you have signature issues, reboot twice, because in my experience, it takes an extra reboot after the file has been replaced for the Windows driver manager to notice that the file is now signed and that it can stop panicking)
——————————— End of Old Methods ———————————
