Enable test mode to solve USB problems?

I had to check the Mbam tutorial mainly because of your questions.
Step 8 instructs you to clean
Step 9 instructs you to repair
Step 10 instructs you to attach

It might have been a communication breakdown - I said you could skip the VirusTotal step. That might have been interpreted as you could stop at that step.

Read, not skim, Bill
Oh wait - there's that stop sign - - you're really good Crabby, you know that.
Read, not skim, Bill

I had to check my own work to make sure I gave the correct instructions in the tutorial.
It looks as though I need to change the Clean step or add instructions for cases like this one.

I have to revisit the tutorial anyway, Mbam has changed a bit [action dropdown boxes instead of checkboxes] - thanks for bringing these things to my attention.

Step 9 SFC scan, did you run that after the scan? Please do after the scan that is running

Step 10 attach - this is the one that really made me think the tutorial needed attention. I thought I had the location in that step.
I did - phew!
Mbam logs: C:\ProgramData\Malwarebytes\Malwarebytes Anti-Malware\Logs

The logs you attached were in xml, and I understand the difficulty you had with empty text files.


Try this with after the current scan
- quarantine all
go to History, application logs
double click on the most recent log (should be a later time than 14-59-30 | 2:59:30)
click the export button and select .txt
save it to your Downloads folder and name it MbamRootScan.txt

I hope I covered everything,

Bill
.

Thanks Crabby,

The last Mbam screenshot looks clean. I'll finish checking the original log and will post anything that I think needs to be done.

One step forward ... I'll post the information CompGeek wants and then I'm out to Happy Hours. I'll probably fade fast though.

Here ya go Jerry,

I used the Date field instead of Date Created & Date Modified. It saved some room
I also added a column for Version and sorted by Folder path

Reported dates are often confusing, for instance when I had the date fields in your example, the creation was later than the modification.

All Attributes are Archive (A) - no other attribute is set on my Dell for theses files.

Let me know if you need anything else off of this machine and I'll drag it out of the closet again

Bill
.

@Crabby, after skimming (yeah, I know, I'll read it later) the original Mbam log, there is only one thing I really want to check.

Please post the TDSSkiller log - I know you said it was clean. The one thing Mbam reported that I want to check is a fairly generic name. The one bad threat would have been detected and remedied by TDSSkiller, the other versions are just PUPs and Mbam remedied that one. Where there's one there's usually more.

At this point the machine is looking a lot better re: malware.

Here's where you should find the log I want to see.

The log file is placed on the System Drive (normally C:\) with the file naming convention:

TDSSKiller.Maj#. Min#. Bld#.Rev#_MM.DD.YYYY_HH.MM.SS_log.txt

Example:
C:\TDSSKiller.3.0.0.17_03.15.2014_12.03.49_log.txt

The numbers will be different but the prefix (TDSSKiller), suffix (_log) and extension (txt) should be the same.

Thanks,

Bill
.

ComputerGeek said:

.....
Then i can go on and explain more

Don't explain for my benefit, it detracts from what I thought you wanted to do - the security catalog.
I mentioned that I thought I saw something about repairing/rebuilding it.

Catalogs screwed (again) [FIXED] - Sysinternals Forums - Page 1
Solution
1. Stop Cryptographic Services (cryptsvc) by running "net stop cryptsvc".
2. Delete or rename the C:\Windows\System32\catroot2 folder.
3. Start cryptsvc by running "net start cryptsvc".
4. C:\Windows\System32\catroot2 will be recreated. If it is not, restart the computer.
5. Wait for all the catalog files from C:\Windows\System32\catroot to be imported into the catroot2 database. This may take up to an hour, so be patient.

And this is where I thought you were heading (I found a reference, I'm not sure if it the reference I saw before, but it fits the bill, er Jerry :))

This is a discussion, not a task to be completed.

Give CompGeek a chance to say "Yeah, that's what I was going to do" or "No don't do that!"

DO NOT hit enter Crabby

Time for a recap.

The Issue: Three USB 3.0 ports, one USB 2.0 port on the machine. None work

Device Manager:

USB 2.0 devices report code 52 under Universal Serial Bus category
USB 3.0 devices report code 28 (no driver) under Unknown devices
Installing the chipset driver for the USB 3.0 device from HP downloads moves it out of the unknown category and into the Universal Serial Bus category but reports code 52

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)

The hardware tested good (it worked) using an Ubuntu boot.

ComputerGeek suggested fixing the signatures either on the individual drivers or on a global scale.
Malware scans to date do not indicate anything serious.

Other related tasks (not necessarily in this order):
completed: Clean startup
completed: Disable hibernation and System Protection to avoid resurrecting the issue
completed: Windows Update changed to manual to avoid thrashing and control when updates are installed
completed: Disable Device Update to avoid battle with automatic updating of a device
completed: create Repair disc
completed: BIOS flashed to correct version F.0A
completed: C:\SwSetup renamed to move the HP install path out of the way
completed: System File Checker - mapi hash mismatch, fixed by NoelDP (unrelated to the USB issue)

Other things considered:
Clean Install: ruled out for various reasons.
Repair install: still considered, but have not prepared
System Drivers are not affected by a Repair install

Observations:
HP Recovery partition is visible - unusual for an HP
HP unpack folder, C:\SwSetp, had an odd tree structure (see above)
The touchpad update from WU breaks the touchpad - this is not that uncommon, so the update is hidden
Windows is up-to-date

What bugs me:
The code 52 indicates an unsigned driver or malware. Malware scans look good and the USB 3.0 driver has been freshly reinstalled (uninstall in DevMgr removing software). It's possible, but unlikely, that the HP drivers are bad (unsigned). This points more to what ComputerGeek is thinking - the store is corrupt.

There are probably things I missed, but this provides everyone with the same information I have in one tidy package. If I got something wrong writing it from memory - let me know and I'll correct it - thanks.

What's left (not necessarily in this order)

• Create install media - just in case we need it Done
• Disable Driver Signature Enforcement Done - this solved the USB 2.0 ports issue but not the USB 3.0 issue
• Repair/ rebuild the catroot2 store
• Determine if the individual driver signature for the affected drivers is the culprit.
• Determine if another driver is causing the issue (ComputerGeek commented that this is a possibility and CrabbyRightNow indicated that the NVidia driver was updated (WU) around the time this started)
• Continue malware scans
• Apply the HP QFE
• Repair install
  System Drivers are not affected by a Repair install

There is order in the Universe and in trouble shooting computer issues

Bill
.