Skip to main content

Cloud

Internet Explorer Crashing When Launching Office Documents From SharePoint and WSS

A while back my browser (IE7) started crashing quite often when I was in SharePoint sites. After a while, a pattern started to emerge – the crashes would happen when I clicked on a link to open an Office document. Other people with my same setup could open the same document on the same SharePoint site with no issues whatsoever.

Depending on whether or not you’ve got Visual Studio installed, (or some other product that gives you a debugger) the resulting error message looks like the following:

"Visual Studio Just-in-Time Debugger: an unhandled win32 exception occurred in iexplore.exe (2080). Just-in-time debugging this exception failed with the following error: No installed debugger has just-in-time debugging enabled. In Visual Studio, Just-in-time debugging can be enabled from Tools/Options/Debugging/Just-in-Time. Check the documentation index for ‘just in time debugging, errors’ for more information."

There’s a lot of JavaScript that gets executed when you click on links to documents in a document library, and I finally got sick enough of IE crashing that I attached a script debugger to see what was actually happening.

Part of what that JavaScript is doing (and there’s quite a lot going on in there) is trying to figure out if checkouts are required, if you are in the contributor role, and if you have an application installed that supports SharePoint integration and can open the file that you’ve selected. If all of that turns out to be true, you’ll end up getting the following dialog:

If some or all of that is not true, you don’t get that dialog, you get the standard IE save/open dialog. One thing you should immediately recognize about the dialog above is that it’s not the standard Internet Explorer script dialog. It’s got some extra formatting and it has a checkbox that allows you to select whether you want to use your "local drafts folder."

This dialog, and the extra functionality that it suggests, is being provided by the SharePoint.OpenDocuments class in owssup.dll. This dll gives you all of the interop capabilities between SharePoint and Office. The JavaScript that executes when you click on a link to an Office doc has to figure out which version of this class to activate. Depending on which versions of the Office suite that you have installed, there’s going to be SharePoint.OpenDocuments.3, SharePoint.OpenDocuments.2, etc. (Remember, one of the golden rules of COM is that you cannot ever change an interface once it’s been released. So just create a new interface with every change you make and append an integer to the class name. That’s adhering to the spirit of the law…)

At the time of my crashes, my machine had the core Office 2007 suite installed. But it had Visio 2003 and Project 2003 installed, since we don’t yet have licenses for the 2007 version of those products. Also, I had uninstalled B2TR of Office 2007. So I imagine the state of my registry with respect to owssup.dll was rather interesting.

My JavaScript debugging showed that IE would crash immediately upon attempting to execute the ViewDocument3 method of SharePoint.OpenDocuments.3. I messed around with trying to register and unregister the various versions of owssup.dll on my machine, but that just made matters worse.

The next thing I tried was a repair of Office 2007. No change. So I removed Windows Sharepoint Services Support from Office 2007 and then added it back in. Bingo. That fixed the problem. IE hasn’t crashed since. You can find the uninstall for Windows Sharepoint Services Support under "Microsoft Office/Office Tools/Windows Sharepoint Services Support/Windows Sharepoint Services Support" in the Add/Remove Features section of the Office 2007 install/uninstall.

This has since worked in several environments with differing configurations – Office 2003, IE6, WSS 3 and WSS 2, etc. So it looks like it might be a good fix (if a rather intrusive one – you’ll need to be an administrator to do it…) Also looks like it’s a somewhere pervasive problem.

As always, your mileage may vary. I’d love to know exactly what’s at the bottom of this. But since I can get it to go away, it’s dropped in the priority stack for the time being.

MB

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Michael Becker

More from this Author

Follow Us