While we spend a great deal of time and effort to ensure that the Outlook platform is 100% backwards compatible with previous versions of Outlook, occasionally add-ins do something unexpected, or use the platform in an unexpected or undocumented way. These add-ins can misbehave and cause problems when running against a new version of Outlook (such as Outlook 2007) where they have not been fully tested by the software developer.
Many beta testers found this out the hard way during the Office beta 2 release when some very popular add-ins caused Outlook to crash unexpectedly while sending mail or performing other common tasks.
I've been working closely with a number of ISVs and software developers to ensure that these problems are fixed correctly. Sometimes we've broken the way something works and we have to fix it on the Outlook side. Sometimes the problem lies in the way the add-in works and the add-in needs to be updated. Often this means that the end user needs to disable the add-in until a new version is available.
Because add-in release cycles are not necessarily tied to Office/Outlook releases, this can cause a problem for some users. In the interim between when a new version of Outlook is released and add-ins are updated, you may need to disconnect an add-in to continue to use Outlook effectively.
To Disconnect an Misbehaving Add-in:
To Enable a Disabled Add-in:
If you're a developer working on an add-in, and Outlook has disabled it, or you are a user who wants to try an add-in again that was previously disabled, you need to access the Disabled Items dialog to enable the add-in. While you can access this from the Trust Center via the Add-ins tab, the easiest way in Outlook is to select the Help menu, then Disabled Items. Find the add-in on the list of disabled items, select it, and click the Enable button to enable the add-in again.
Keep in mind that if the add-in was disabled, it's likely because Outlook believes the add-in is misbehaving. There are some add-ins that are disabled immediately when Outlook is installed, and others that are disabled because Outlook detected a problem. In all cases, you should only enable an add-in again if you are sure that it is not causing any problems in Outlook.
Technical Details for Changes in Beta 2 Technical Refresh
If you aren't a developer or a technophile, I suggest you skip this part.
In response to a number of third party problems we've seen during the Beta 2 release of Outlook, we've made a change to the add-in resiliency logic that Outlook uses. Early in the Outlook 2007 release cycle, we decided to make a change to the way Outlook handles errors from installed add-ins. Previously Outlook would catch exceptions from add-ins and silently ignore them. This prevented Outlook from crashing immediately, but Outlook usually would crash later because memory somewhere had become corrupted, and it was just a matter of time before this caused a problem. For Outlook 2007, we now crash immediately when the add-in throws an error, allowing us to better understand the root cause of the failure. Instead of crashing later in some random code, we now crash at the actual cause. However, this change caused Outlook to crash a lot more frequently due to a number of add-ins that expected to be able to throw exceptions without consequence (which is a really bad expectation).
Previously in Outlook 2003, if an add-in caused Outlook to crash while the add-in was being initialized (OnConnection) or disconnected (OnDisconnection), then the add-in could be added to the disabled items list, which prevents the add-in from being loaded or running. If an add-in crashed later, say in an event handler (the most common place we saw crashes in beta 2), then Outlook would crash, and the add-in would not be disabled. This meant that it was possible to have a very bad experience in Outlook where every time Outlook boots, it crashes due to a misbehaving add-in. The only recourse was to use safe mode to disable the add-in, which most users would not immediately discover.
Now, in B2TR Outlook will also perform the same resiliency action if the add-in causes Outlook to crash during an event handler. Outlook will still crash, but upon the next boot of Outlook, you will be presented with a dialog asking if you want to disable the add-in. This way, users who are seeing a large number of add-in related crashes in beta 2 should only see a couple of crashes in beta 2 technical refresh because the add-in can be disabled easily by the user (and we default to disable if the user accepts the prompt defaults).