This documentation is archived and is not being maintained.

Application Shutdown Changes in Outlook 2007 SP2

Office 2007

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Summary: Learn how Microsoft Office Outlook 2007 Service Pack 2 has changed the way that the Outlook process shuts down. Customers developing Outlook solutions that run outside of the Outlook process should understand these changes and the impact on their solutions.

Ryan Gregg, Microsoft Corporation

November 2008

Applies to: Microsoft Office Outlook 2007 Service Pack 2


As part of the performance improvements included in the Microsoft Outlook 2007 Service Pack 2 (SP2), Outlook has changed the way it manages its process life cycle. Prior to Outlook 2007 SP2, Outlook followed the best practices for Component Object Model (COM) servers and allowed clients of the Outlook COM server to control the shutdown of the Outlook process. This caused a significant end-user side effect: often the end user could not close Outlook because of lingering external references from Outlook.

As a result of customer feedback about the need to close Outlook and have Outlook stop running, Outlook 2007 SP 2 changes the way Outlook closes, ensuring that the intent of the end user─to close Outlook─is respected. These changes significantly affect the way that the Outlook COM server shuts down, which can impact solutions using the Outlook object model outside of the Outlook process.

If your solution is an in-process COM add-in, or if you used Microsoft Visual Studio Tools for Office to write an add-in for Outlook, this change does not affect the way that Outlook and your add-in work together. The lifetime of in-process add-ins and in-process COM references to Outlook objects in Outlook 2007 is the same as the lifetime of the Outlook process. When the user closes the last Outlook window and Outlook starts to close, Outlook disconnects add-ins and releases all of their references to Outlook.

Add-ins can use the Quit event on the Application object to determine when Outlook closes down. After Outlook raises the Quit event, the OnDisconnection method of the IDTExtensibility2 interface of the add-in or the Shutdown method of the ThisAddin class of the Visual Studio Tools for Office add-in will be called, the add-in will be unloaded, and Outlook will close.

In versions of Outlook earlier than Outlook 2007 SP2, before Outlook closed, Outlook would check for external, out-of-process references on its COM server and wait for those references to be released. This allowed out-of-process solutions that depended on Outlook data to keep Outlook running until the references were released. This is a common behavior for COM servers; however, this is unexpected behavior for end users, who expect that an application will close when they close the last window of the application.

By default, Outlook 2007 SP2 ignores external COM references when determining if it should close. When an end user closes the last Outlook window on the user's computer, Outlook starts closing down the process: first raising the Quit event on the Application object, then disconnecting add-ins and external references, followed by flushing internal caches to disk, and finally exiting its process.

Because of the way COM works, when Outlook releases external references, these referenced objects become disconnected objects in cross-process solutions. Without being aware that previously referenced objects have been disconnected by Outlook, a solution that attempts to use any of these object references will receive an error, RPC_E_DISCONNECTED. Solutions that are not designed to handle this error may stop responding or respond unexpectedly. This occurs when a solution attempts to use an object reference to Outlook after Outlook has closed and disconnected all previous references to the object.

To work properly with the new behavior in Outlook, a solution should listen for the Quit event on the Application object. When that event is raised, the solution should stop any work in progress that uses Outlook data, and release all references to Outlook. Any remaining references after the solution returns from the Quit event will be disconnected. The solution should no longer use any of these disconnected references since any operation will result in an error. If the solution subsequently needs to access data from Outlook, it can request a new instance of the Application object by using the CoCreateInstance function, which will start Outlook without any user interface as described below. However, this should be avoided because the end user has closed Outlook.


The solution should be aware of the Windows shut-down events, and should not attempt to invoke a new instance of Outlook if Outlook is shutting down because Windows is shutting down.

While a solution is handling the Quit event, Outlook can appear to have stopped responding to the end user and the operating system. The end user may forcibly terminate Outlook instead of waiting for it to finish closing. Therefore, the solution should handle and return from the Quit event as quickly as possible.

Group Policy Override

The preceding sections describe the default behavior for Outlook 2007 SP2. This default behavior can be changed through group policy to restore the process life cycle of Outlook to its behavior before Outlook 2007 SP2. To do so, administrators can set the following registry key:


Add the following value to the key:


Setting this registry key will require Outlook to wait for all external references to be released before closing. This registry key should never be configured automatically by a solution, and is intended to be used by only IT administrators to enable solutions working with earlier versions of Outlook to work properly with Outlook 2007 SP2.

Outlook Running Without User Interface

When Outlook is started without any user interface, such as when Outlook is not running and a solution calls CoCreateInstance, Outlook will use external references to determine the lifetime of the Outlook process. This behavior is contrary to the behavior of Outlook started with a user interface. This behavior remains until a visible Outlook window is displayed.

For example, if a solution uses CoCreateInstance to start Outlook, it can continue to use references to Outlook without displaying any visible user interface to the end user. When the last reference from the solution has been released, Outlook will close. However, if, while this instance of Outlook is still active, another solution connects to Outlook and displays an Outlook window, and if the end user closes this Outlook window, because the only Outlook window for the end user has been closed, Outlook will raise the Quit event, start to close down, and disconnect all external references to these instances of Outlook.

Outlook 2007 SP2 changes the way Outlook manages its process life cycle, possibly affecting solutions that automate Outlook using the Outlook object model. As a result of this change, solutions may work differently on Outlook 2007 SP2. Solutions providers may need to update their solutions so that they work properly with the new behavior in Outlook 2007 SP2.

Ryan Gregg is a program manager for the Outlook product development team.