If you (or your firm) have never experienced this problem, please don’t let this post plunge you into terror. It does not occur all that often: personally, I have never encountered this problem in the wild… at the law firms where I have consulted.  Nonetheless, this error originating with Microsoft .NET versions could be quite disruptive if it did occur. Here’s how to diagnose and cure it.

You (or users at your firm) may suddenly find yourselves plagued by crashes of Outlook with FileSite EMM every time it’s launched – an ‘Unexpected shutdown has occurred‘.  While there’s always the old standby of  ‘reinstall FileSite, and failing that delete the user’s profile’… that’s a terribly large hammer to smash what might be a small and solveable issue.

Or, the iManage EMM toolbar (add-in) may fail to load for Outlook 2010. Other causes of missing toolbars – or menus – are detailed over here.

Scope of the problem

This problem might shut you down firm-wide; or, it might affect only some people while everyone else is fine.  This particular crash has been reported with FileSite 8.5 in conjunction with EMM 8.5 and Outlook 2007. But because it’s such a serious failure – preventing Outlook from running – it’s worth investigating for FileSite 8.2 and Outlook 2003 as well.

How to troubleshoot

If this error is reported, it’s worth troubleshooting this scenario even if you think you fixed it before.  Nobody likes being deprived of Outlook.

Review the App Event Log on the problem desktop – not a usual step that an average user would take ;).  Looking at the time of the Outlook crash, does the App Event Log report “Fatal Execution Engine Error – .NET Runtime Event ID 1023″?  There might be different errors in the event log depending on the flavour of this particular crash.  If there’s any message in the log related to the CLR – common language runtime – this post may be the solution you need.

The Cause

This error is a known symptom of multiple .NET versions conflicting on the same machine.  Although FileSite and EMM require and use .NET version 3.5, an incompatible .NET 2.0 will trigger this error.

The bad 2.0 version could be introduced by any number of other software packages – hence its possible scattered occurrence.  If it’s been introduced by a software push throughout the firm, just jump straight to the fix section.  Your ears are likely ringing with angry screaming.  The bad 2.0 .NET can also be introduced by software that an end-user has installed, assuming that your desktops are not locked down.

The Fix

Immediate workaround: Obtain and install a fixed version of that .NET 2.0 binary from Microsoft.  It is available for free download from the Microsoft support site at http://support.microsoft.com/?kbid=963676

Important: check the version number of the .NET 2.0 binary after you install the fix, to confirm that the install was successful. Microsoft has a known problem in which .NET installations appear to succeed when in fact they fail due to a prior defective patch.  There are around forty bad patches that cause that failure: refer to the Microsoft support site at http://support.microsoft.com/kb/2431806 in order to track down which of the forty is troubling you. (hat-tip to Jan-Ingvar Johannesson on the Autonomy forums for pointing out this second Microsoft gaffe).

Sounds like fun, I know. If you need some help determining whether this is causing your Outlook crash, contact me.  Helping people with this sort of glitch is what I do.