Enable test mode to solve USB problems?

Ok, I was just typing a similar post. We can pick this up in the morning.

g'nite

CrabbyRightNow said:

Bill,
I did that last thing with devices and printers, and in answer to your other questions: I don't know how to tell if I am standard or administrator, I am using MSE and I did a full scan of my computer during the week and there were no threats detected.
I'm the only one using this computer, so I assume I am the administrator.

Ok, you've told the machine not to update anything until you tell it to update something. One of us has to remember to turn those back on when you get through troubleshooting the USB issue.

You are most likely an administrator account, to check
Launch Control Panel -> User Accounts
you'll have to poke around it's either the main screen or one of the selections (manage another account??) that tells you the account type for a user profile. I'm working on a Win8 machine and the screens are different.

Good to know MSE came up clean.

I think the next step is to rectify the BIOS version, but let me sleep on that.

Now I'm really going to bed, g'nite

Bill
.

ComputerGeek said:

If I might also try to help. First, I'd like to collect some additional diagnostic data
@Slartybart

This Chipset update seems as though it only changes the name shown in Device manager.

fyi the name change... Manufacturers burn Plug and Play ID info into device firmware. This includes a device description string.
> When Windows can't find a device driver (this is the case when device is listed under "Other" device), Device Manager displays the PnP device description from the mfr for device name
> Once Windows finds a driver, Device Mgr shows the name found in the driver

That's why the Chipset install changed the device name. The chipset install provided a driver (tho unfortunately the device still doesn't work )

/* EDIT */
Ugh. It's not a BIOS issue. I just looked up Code 52: Windows cannot verify the digital signature for the drivers required for this device. Which would also indicate is certainly a software issue.

More help on this is appreciated as long as we don't bang heads or confuse the other member

Yeah, without the driver, there's no string to display - got it.

The BIOS issue is separate from the USB issue, but being BIOS could be relative to a solution. I had to check about 5 times, to be sure ... the HP assistant report F.0B, the HP support page for the machine reports F.0A; typos or failure to update versions on the webpage or bugs in HP assistant could be possible causes for the discrepancy. After searching HP for a BIOS that superseded F.0A and finding none, I thought maybe the HP assistant reported F.08 and my eyes saw F.0B. Anyway, at this point, there is no F.0B on HP, and I saw correctly the version as F,0B in HP Assistant - phew!

Code 52 can be handled by turning off driver signature enforcement in advanced boot - but I'm hesitant to do that until more things are researched. I've never seen a driver from a vendor be flagged that way. Drivers found by Googling, sure, but not from a vendor.

I want to double check the other driver warnings Crabby posted (after uninstalling), but believe that is just another instance of code 52, but from the automatic driver updates - those are turned off now.

I have yet to read the information Crabby posted to satisfy your request, I will right after this post.

The short plan:

UNinstall the 3 drivers if they're installed (I forget if the last one was successful or not).

Maybe .. maybe ... probably suggest cCleaner to look at any Registry entries related to the devices. DriveCleaner would have taken care of ghost device entries, but we've made at least one attempt to install after running that utility. Might be worth running DriveCleaner again before attempting the next driver install.

Install the F.0A BIOS
Check everything again before proceeding.

Install the USB chipset driver
If all goes well (no code 52), we're done.

Last ditch effort (unless another solution presents itself) - disable device checking.
Install the USB chipset driver.

Enable all of the things disabled (WU, Driver install, Device checking)

That's the plan as I see it - any thoughts?

@Crabby, I'll read the info you posted for CompGeek. Then I'll finalize the above and post it
- I always like to measure twice, cut once if you know what I mean.

Bill
.

Please follow this tutorial to provide the current operating environment of your machine.
Speccy - Publish Snapshot of your System Specs

I asked for this before, it must have slipped through the cracks.
Or I buried it with my long posts

Thanks

CrabbyRightNow said:

ComputerGeek, here is what I got in problem devices:

Intel(R) USB 3.0 eXtensible Host Controller PCI\VEN_8086&DEV_1E31&SUBSYS_1818103C&REV_04\3&11583659&0&A0 This device is working properly.
Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E2D PCI\VEN_8086&DEV_1E2D&SUBSYS_1818103C&REV_04\3&11583659&0&D0 This device is working properly.
Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E26 PCI\VEN_8086&DEV_1E26&SUBSYS_1818103C&REV_04\3&11583659&0&E8 This device is working properly.

Hey ... who threw that wrench in the machinery

dxDiag says This device is working properly for all three devices.
DevMgr shows an error and the devices don't work.

The HWIDs are good to have - thanks. I've been thinking there's more base drivers that might bear further investigation.

I have trouble finding the chipset drivers to install on my own dv6, only because HP doesn't break them out of the APU and AMD makes it hard to get updates directly from them.

The dv7 machine is Intel, but it's HP ... so more research ... it's HP!
Who knows, maybe the IME chipset has more than IME drivers in it.

I think that looking at Intel is another option, but it should be done after BIOS F.0A

Bill
.

ComputerGeek said:

Driver's have a digital signature. (This signature verifies the file is not corrupt nor a file simply placed there by a hacker). Digital signatures are stored in ".cat" files (Security Catalog Files).

Some devices have their own .cat file. It resides among the device's other driver files. But there's a system level .cat file as well.

Here's a Microsoft Technet article with instructions to fix a corrupt System level .cat file. It's about Windows Server 2008. (but Server 2008 was built on top of Win 7 Pro so I believe it should apply to your machine too.) Repair the system catalog database.

To start, let's just see if you have any security events logged in your Event Viewer

• Download VEW and run it
• Right click VEW.exe then Run as Administrator. When VEW opens
  
  • Under Select log to query: select Application and System
  • Under Select type to list: select Error and Warning
  • Click the radio button for Number of events, Type 20 in the 1 to 20 box
  • Click the Run button. It may take several seconds, Notepad will open with the output log
  • In the Notepad window, click Ctrl+A to select all, then Ctrl+C to copy, then Ctrl-V to paste the result in your post

(VEW tool courtesy rev-Olie)

Thanks, this is a good place for me to sit on the side until CompGeek does his Event Viewer VooDoo. I'm not giving up on the issue, just passing the baton :)

VEW is a tool I will add to my toolbox.
edit: I've also bookmarked the catalog repair/rebuild page. Thanks CompGeek for bringing that information forward.

Bill
.