Right Click on Drives or Folders Hangs Explorer for 3.5 Minutes

One thing that I have found causes significant delays when opening Windows Explorer, especially if you click to open My Computer or My Network Places is having network drives mapped that are not accessible at that time.  For example, my laptop has drives mapped to the network shares in my office, but if I am using the laptop away from the office, the system is unable to find those drive and appears to hang while it is looking for them.  The more drives I have mapped, the longer the perceived hang.  I have just disconnected the mapped drives and, when in the office, either manually map the drive or access it via UNC paths rather than a mapped drive letter.

nsx106052:

Haven't run hijackthis becuz a) didn't seem like that type of problem, and b) I run McAfee Antivirus full time. I'll try it.

As far as other processes, you remind me of another symptom: the problem occurs in ANY window which offers a right click option on a drive or folder, such as an Open File dialog box.

HudsonMarine:

Thanx, but no network drives are involved.

Maybe send us your Autoruns (http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx) log even though you already disabled everything with ShellExView.

Orangutang:

Autoruns log attached. I should point out that when disabling all the shell handlers did not fix the problem, I re-enabled all of them - got to have a usable system, you know, even if it has a few glitches!

Ditched McAfee, installed Kaspersky. It found nothing related.

Did notice one thing, though. As I explained in the original post, when Windows Explorer goes into its 3+ minute hang, I can open a second copy of Explorer and right click will work fine in there. When the first copy of Explorer comes back to life, a right click in the second Explorer will now cause it to hang for 3+ minutes. And while that is happening, right click works fine in the first copy. This seems to be able to go back and forth indefinitely.

Also, disable them again in ShellExView. Then send all of the loaded modules in "explorer.exe" from Process Explorer (http://download.sysinternals.com/Files/ProcessExplorer.zip).

Orangutang:

Here's what Process Explorer shows for "explorer.exe", with ALL shell handlers disabled by ShellExView (see attached file).

Also. as I look around, I see some fairly elementary posts (e.g., "please recommend a browser alternative") offering 500 points for difficulty, so it seems clear that I need to bump up the point value on this one.

Click "explorer.exe", click the "View DLLs" icon at the top, and send the DLLs that are listed at the bottom.

Also, open Process Explorer and when explorer freezes, double-click "explorer.exe", click the "Threads" tab, and tell us the "Start Address" of the thread that's taking up the most CPU.

Power outage yesterday. Dinner (PBJ sandwiches) by candlelight, but no computer activity.

Today: disabled all handlers. Did the right-click thing in Explorer. List of DLLs attached.

The only thread that showed any CPU at all (and not much, either) during the time of the hang was :
SHLWAPI.dll!Ordinal505+0x37a

When Explorer came back to life, there was a short burst of activity at a new thread that appeared:
BROWSEUI.dll!Ordinal138+0x7b8d

Did you right-click first and then look at the list of threads while explorer was frozen?

Yes.

But only BROWSEUI.dll!Ordinal138+0x7b8d used a lot of CPU for a short time? It wasn't the whole time when explorer was frozen?

Correct. It only appeared in the thread list at around the time Explorer came back to life. The activity burst was merely a fraction of a second.

Well, if it's some sort of third-party module, here are the possibilities:
LgMsgHk.dll      Logitech Message Hook Library      Logitech Inc.      1.01.0000.0000
LgWndHk.dll      Logitech Call Window Hook Library      Logitech Inc.      9.79.0019.0000
miscr3.dll      Kaspersky Anti-Virus Ring 3 Hooker Helper      Kaspersky Lab      7.00.0000.0125
scrchpg.dll      Script Checker      Kaspersky Lab      7.00.0000.0125

I'll do some more research.

The problem's been going on for at least a month, maybe two. Kaspersky was just installed recently, so that's not likely to be it.

Way to go, Orangutang! It was the registry. Am I correct in thinking that if I compare the current values in these two branches against the values that I exported before I made the changes, that there will be at least one difference, and that the difference will point to the source of the problem? And what is it exactly that regsvr32 does?

Problem still existed in Safe Mode. Clearing out the two branches from the registry and running regsvr was the fix.

Well, I think that Windows reads those registry keys when you right-click a directory. Since I didn't know what could be causing the problem, I just thought of completely deleting those keys and re-adding the default keys which is what running:
regsvr32 /i shell32.dll
does. Running that command also sets other registry values and keys to the default so I don't know if the problem might have been solved with something else that running that command corrected. Thank you. I hope the problem doesn't come back.