The Trouble with My Documents

By pure coincidence a couple of days after my last post “the trouble with opening files” I came across a very similar issue. When I say similar I mean it had similar symptoms and I used the same technique to resolve it.   The solution, however, was completely different. It just goes to show that in this day and age, knowledge is cheap and technique is king.

So here’s the set up. When Gary from Compliance (Compliance staff in this office were something akin to the secret police, so we liked to keep them happy) opened his My Documents from the start menu it would take about 30 seconds to show the contents. The My Documents was mapped to the SAN and was fine once it displayed. Anyone logging onto his device would have the same trouble and it also happened to an undisclosed number of his colleagues. The desktop techs had recreated his profile and ran NET USE as in my previous post. The server guys couldn’t see anything wrong with his share on the SAN either.

That seems like a lot of good information. A lot of people might be tempted to get Gary to logon to various different devices and see if he worked on any of them. If he did you’d just compare the differences and that would be your answer. However there is a better, quicker and easier way.

The issue was easy to reproduce so I copied ProcMon.exe over to the offending device, started a capture and opened My Documents from the start menu. Sure enough it took about 30 seconds to display the My Documents folder. I stopped and saved the capture once I could see the contents.

I filtered on Explorer.exe, the process doing the work here, but there was still over 18,000 events.

my docs first

This is where the technique comes in. I used the scroll bar to quickly scroll down the trace and concentrated on the seconds column

my docs second column

When I saw the seconds jump from 53 to 14 I knew Explorer had been waiting for something to happen

my docs pause

Immediately after the pause Explorer was trying to enumerate the following key

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks

I right clicked on the key and selected Jump To.

There were two values under this key

{AEB6717E-7E19-11d0-97EE-00C04FD91972} and {B5A7F190-DDA6-4420-B3BA-52453494E6CD}

The former was blank but the later  had a value of “Groove GFS Stub Execution Hook”

A quick Google (yes I do use it for some stuff) revealed that this was part of the Office Sharepoint Workspace (Office 2010) or the painfully moniker’ed, dad dance of name, Office Groove in 2007. The feature wasn’t used in the organisation so I uninstalled it from Office and everything worked fine.

Despite having little knowledge of SharePoint and its components, good technique enabled me to quickly identify the culprit. Even though the symptoms to the “slow opening files” issue the solution was completely different. However the technique for finding the solution was exactly the same. It was quick, effective and you get to be a troubleshooting hero for an afternoon.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s