Sign in to follow this  
Followers 0
Tripredacus

USB connect/disconnect delay

13 posts in this topic

I've been experiencing problems with USB on my 7PRO32 PC. If I connect or disconnect a USB key, there is quite often a delay (30seconds to 3 minutes) before Windows acknowledges the connection. Here are the two symptoms:

Connect USB Key: CPU hits 98% to 100%, with SVCHOST.EXE using about 50%. During the delay, no sounds will play in the OS, for example AIM notifications. Once the delay is up, the Scan/Not Scan box comes up, and then all cached sounds will play at once (AIM, USB Connect) and then the key is usable as normal.

Disconnect USB Key: Basically the same as the connect, except the delay is longer, and the drive will still appear in Computer until the svchost.exe process exits and the disconnect sound plays.

It doesn't seem to matter what USB Key I am using. The same thing also happens with USB HDD Enclosures. And some devices, such as the Seagate GoFlex flat out won't be detected any more. Safely Remove Hardware doesn't make a difference either. And for the CPU usage, svchost.exe always uses about 50%, but I can't find in Task Manager what else is using CPU to make it hit 98%, since other than System Idle Process (which is ignored) there is usually just a 1-4% on the next item (such as Firefox or IE or whatever I am using.

What can I run to determine where the problem is?

0

Share this post


Link to post
Share on other sites

What can I run to determine where the problem is?

Have you cleared the "database" of connected devices?

(that should be IMHO the very first thing to try)

Some details are given here (only seemingly UNrelated):

jaclaz

0

Share this post


Link to post
Share on other sites

The Nirsoft app is great. It did indeed fix the problem (removing devices that weren't present) while it did take quite a long time. The worst was when the keyboard and mouse stopped working (no PS2 ports on this system).

:thumbup

0

Share this post


Link to post
Share on other sites

... while it did take quite a long time.

Sure :) why do you think that you were experiencing "lags"?

Most probably EXACTLY because you had probably a few hundred entries in the Registry (and it does take some time to delete them).

What you should be careful with are those devices - USB sticks usually - (they are quite rare, but you never know) that for one reason or the other do not have a serial number, I seem to remember that those are the ones that may "confuse" Windows and create (or incrase) those lags.

For machines to which you connect a great number of different devices, periodically clearing the Registry is usually a good enough preventive measure, you should run the thingy from time to time (if there are not too many registry entries it will be quick ;)).

jaclaz

0

Share this post


Link to post
Share on other sites

Well this problem has returned. NirSoft only showed 6 entries. Removed all not actually connected. Now NirSoft only sees 3 devices (usb, mouse, ufd used with RDP) and the delay on connect/disconnect is 5-10 minutes with other UFDs. Using the Safe Remove Hardware option on it first doesn't seem to make a difference.

Any other ideas?

0

Share this post


Link to post
Share on other sites

Well this problem has returned. NirSoft only showed 6 entries. Removed all not actually connected. Now NirSoft only sees 3 devices (usb, mouse, ufd used with RDP) and the delay on connect/disconnect is 5-10 minutes with other UFDs. Using the Safe Remove Hardware option on it first doesn't seem to make a difference.

Any other ideas?

It's strange. :unsure:

I mean, if you had an evident benefit from clearing the database and now you are back to the same situation (possiby worse as you were talking of 30 seconds ÷3 minutes and now you have 5÷10 minutes :w00t:) there must be *somehting else* going on, but then again originally cleaning the device database could not have created a speeding up.

Try checking manually the relevant keys listed here:

jaclaz

0

Share this post


Link to post
Share on other sites

I went through that, and it seems better again. Interesting to note, I disconnected my RDP key. It had 3 entries in Device Manager, and while the key worked perfectly fine, one of the entries had a Code 43. Its possible that was related to the problem.

In other news, when I connect a USB key now, I no longer get either the Scan message, or the autorun prompt. That's not so much a big deal, but interesting to note.

0

Share this post


Link to post
Share on other sites

I went through that, and it seems better again. Interesting to note, I disconnected my RDP key. It had 3 entries in Device Manager, and while the key worked perfectly fine, one of the entries had a Code 43. Its possible that was related to the problem.

Through WHAT?

HOW?

What do you mean by "I disconnected my RDP key"?

WHAT (the heck) is a RDP key?

In other news, when I connect a USB key now, I no longer get either the Scan message, or the autorun prompt. That's not so much a big deal, but interesting to note.

Those should still be :unsure: connected to :

http://code.google.com/p/buncha-toolz/wiki/AUTORUN_DISABLE_Documentation

jaclaz

0

Share this post


Link to post
Share on other sites

I went through that, and it seems better again. Interesting to note, I disconnected my RDP key. It had 3 entries in Device Manager, and while the key worked perfectly fine, one of the entries had a Code 43. Its possible that was related to the problem.

Through WHAT?

HOW?

What do you mean by "I disconnected my RDP key"?

WHAT (the heck) is a RDP key?

The RDP key is a USB key I had connected at all times that I shared as a local disk for when I RDP into something. It was only used for that purpose.

0

Share this post


Link to post
Share on other sites

The RDP key is a USB key I had connected at all times that I shared as a local disk for when I RDP into something. It was only used for that purpose.

So, it is a "normal" USB stick?

How comes you had three entries for it in the device manager? :unsure:

Still, you should have seen an anomaly when going through the Registry keys (provided that the still missing answer to WHAT?/HOW? is that is the "that" :whistle: )

The error 43 can only happen (AFAIK) when repeatedly inserting a device (which is seemingly not your case) or when there is a conflict between two drivers, it's really strange what you report, I don't recall having ever seen more than one entry in device manager for the same device (either working or with ! or ? ) ....

jaclaz

0

Share this post


Link to post
Share on other sites

Oh. The What/How was the instructions in your link to remove registry entries for the USB devices. I had removed the USB key I used for RDP transfer prior to that when I realised how many entries were there... and not certain which one was for that key.

The 3 entries were:

- one in Disk Drives, which showed no error. Was able to populate the volume data.

- one in USB Controllers, as Mass Storage Controller

- the third one... was in a section that normally doesn't appear. I can't remember the location, as the notes I started were lost when I had to reboot (forgot to save).

Normally a USB key will have only 2 entries. One for USB Controllers, and one for Disk Drives, presuming it is formatted.

0

Share this post


Link to post
Share on other sites

Normally a USB key will have only 2 entries. One for USB Controllers, and one for Disk Drives, presuming it is formatted.

Yes, but there is NO connection between the entry in Disk drives and whether the device is formatted (or partitioned and formatted).

In Device Manager:

The whole device will have a single entry as "USB mass storage". <- this is usbstor.sys (the "single" entry I was referring to)

NO matter if formatted or not, the disk device will have an entry under "disk drives". <- this is disk.sys and partmgr.sys (tI see it as a "direct consequence" of the above)

If the device is NOT formatted, it will still (if functional) get a drive letter (in order to let you format it ;) ).

As always everything is possible but the "Code 43" should not be connected to the "disk device" part (or more generally with disk.sys or partmgr.sys) on a functional USB stick (it may happen with a USB adapter + hard disk, but on a Stick they are "all together"), in these cases widows would stop the "Usb Mass storage" device as a whole :unsure: .

It's a pity you don't remember where exactly the third entry (if I get it right the one with actually Code 43) came out in the Device Manager tree, but unless it was a single "glitch in the matrix", there will probably be a "next time" when you will be able to record this piece of info, as it still doesn't sound "right", I mean a device is either working or Windows has stopped it"....

...or could it be a case of "phantom device"? :ph34r:

http://windowssecrets.com/newsletter/how-to-prevent-and-remove-phantom-devices/

jaclaz

0

Share this post


Link to post
Share on other sites

run ProcMon in background and look what causes the delays.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.