Address Bar Freezes...

[psychonaut2000]

Win2K Pro SP3
Office 2002 + SP1 + SP2

Here's the scenario: An Office App (e.g. Outlook, Word...) is open. User clicks "File", "Open" and then clicks the drop-down arrow on the Address Bar in order to choose the drive or share which contains the file to be opened. As soon as the drop-down arrow is clicked, the app. freezes and the address bar becomes "greyed-out".

This occurs under any user profile (domain or local admin). Tried reinstalling office without results. Is this a known issue? Thoughts?

Thx!

 

[psychonaut2000]

I Removed Office and deleted all registry entries that reference "microsoft office". Rebooted and performed a clean install of Office under the local admin account. Applied all current SPs and patches.

Issue now exists for any authenticated domain user but *not* under the local admin account.

Was unable to locate any relevant data on MS Support website or other tech support sites.

Contacted MS Premier Support to discuss the issue.

MS suggested I DL two freeware utilities called "Filemon" and "Regmon" from Systernals.

http://www.sysinternals.com/ntw2k/source/filemon.shtml

Filemon, as the name implies, monitors filesystem activity and generates a log of what is doing what and when.

Basically, I would open Office, Start Filemon, and then replicate the issue in order to determine which process might be associated with the hang-up.

I ran this a number of times, each time removing one potential causative agent.

By the final run, I had disabled McAfee VirusScan Console and Virus Shield, and uninstalled the Zen Agent since these seemed to *potentially* be implicated in my early runs.

Regarding the Zen Desktop Management Agent. I noticed during the sixth run that there is a delay associated with Zen as shown below:

1908 4:13:35 PM WINWORD.EXE:1452 QUERY INFORMATION C:\WINNT\system32\shell32.dll SUCCESS Attributes: A
1909 4:13:47 PM ZenRem32.exe:724 QUERY INFORMATION C:\Program

Notice the 12 second delay? I uninstalled Zen, rebooted and ran another trial...

I noticed, in this final filemon log file, that there is a significant delay (26 seconds) between lines 97 and 98 where an effort is being made to access a drive J: (???) which returns "bad network path". This is not anything that the user has mapped. Is there some login script that is referencing this? I'll attach the logfiles but here are the entries I'm referring to:

97 4:35:10 PM explorer.exe:856 QUERY INFORMATION C:\WINNT\system32\shell32.dll SUCCESS Attributes: A
98 4:35:36 PM SERVICES.EXE:228 OPEN J:\ BAD NETWORK PATH Options: OpenIf Access: 00000000

So... it seems to me, and MS concurred, that what's happening in a nutshell is this:

When you click the drop-down arrow, Office attempts to verify (ping?) the various mapped drives to determine their validity. If there are invalid entries (e.g. Drive J or if there are connectivity issues this might cause the process to hang until a response is retrieved. This would explain why the issue does not occur under the local profile, where no mapped drives need to be verified.

Interestingly, this same hanging behavior does *not* occur with Windows Explorer. I made MS aware of this and he reminded me that Windows and Office use different DLLs for this. Is a way (registry entry perhaps) of disabling the autorefresh type feature that causes office to attempt to verify the network each time you click the dropdown box. If there were a way to used cached data to populate the list that might help but this is just wild conjecture from a desperate and disturbed human being.

Thoughts?

 

[xlhelp]

Une question, sil vous plait.

Have you waited to see of anything happens say with five minutes or so?

Deja Moo - "I have heard that bull before"

 

[psychonaut2000]

Yes...after an extended delay of up to 5 minutes or so the system will respond...

 

[xlhelp]

In that case, you have a network drive that no longer exists. You need to go and disconnect it under Windows Explorer.

Deja Moo - "I have heard that bull before"

 

[psychonaut2000]

That's exactly it. Just so happens that I experienced this same issue on another user's workstation yesterday. Disconnecting the invalid mapping did the trick...thx...