Why doesn’t Excel quit?

The case

In today’s portion of questions at Excel for Developers forum, there’s this one:

I am currently working on a project that requires Excel to be controlled from within the C# environment. The program runs correctly and quits excel however it doesn’t remove the .EXE from the task manager. This is a problem as I need to open and close the Excel many times and it is filling up my RAM. Here is a code snippet:

Ex._Application OpenExcel;
OpenExcel = new Microsoft.Office.Interop.Excel.Application();
OpenWorkbook.Save();
OpenExcel.Quit();

From my experience, Excel doesn’t quit because there’s a COM object left unreleased either in your code or in the code of a COM add-in loaded in Excel. That is, to debug such an issue, you need to start with turning all COM add-ins off.

To turn a COM add-in off:
Set LoadBehavior = 0 in {HKLM and HKCU\Software\Microsoft\Office\Excel\Addins\{an add-in}.

The theory

Now, let’s discuss this code line:

oWb = oApp.Workbooks.Open()

Its execution results in creating two COM objects: the first is a Workbook object, the other one is a Workbooks collection object. Let’s look at how the latter is created.

Because of the way .NET manages COM objects, oApp.Workbooks creates three objects:

• #1 – the Workbooks collection, a COM object. You don’t access it in your code; instead, you manipulate it using #2 and #3 below.
• #2 – an object called RCW which is an intermediate layer between a COM object and .NET; it deals with how the COM object is created/released. Although this is a .NET object, it isn’t accessible in your code.
• #3 – a regular .NET object which holds a reference to the RCW (#2 above); this object represents the Workbooks collection in .NET.

That is: a .NET object (#3) holds a reference to the RCW (#2), which in its turn references the COM object (#1). When you call Marshal.ReleaseComObject(#3), #2 releases #1. Starting from this moment, invoking any property/method on #3 produces the exception “COM object that has been separated from its underlying RCW cannot be used”.

If you use Marshal.ReleseComObject to release a COM object, set the corresponding .NET variable to null (Nothing in VB.NET) as an indication that the corresponding COM object is released.

Setting null (or Nothing in VB) to a .NET variable that references a COM object doesn’t release the COM object which will stay alive until the next run of the GC. This results in holding resources and poor memory management.

When you call oApp.Workbooks.Open(), the three objects above are created for oApp.Workbooks… and another three for …Open(). The difference is: object #3 for …Open() is kept in oWb, while object #3 for oApp.Workbooks… is not referenced. It will be collected if only GC has a chance to run.

When Excel is closing…

Now, let’s see what occurs when you quit Excel.

If Excel was started by the user and the construct above is created in a VSTO add-in, then the VSTO add-in unloads the corresponding AppDomain; this kills #3, then #2 and, consequently, #1. In case of a COM add-in, Excel 2007-2010 kills unreleased objects after a time-out and this allows the add-in to unload and Excel to quit.

If Excel was run via Automation e.g. new Excel.Application(), you are responsible for releasing everything.

Conclusions:

• When developing an application that deals with an Office application such as Excel, you need to release COM objects.
• Debug your application or an add-in with all extensions in the Office application turned off.
• If you develop an add-in for an Office application, you must release COM objects too; otherwise running the Office application by any standalone application will leave the Office application in the Processes list.

How and when to release COM objects?

There are three strategies:

1. Not to release COM objects at all.
2. Call GC.Collect at a proper moment.
3. Use Marshal.ReleaseComObject() to release every COM object created in your code.

Strategy #1 is most wide-spread. It results in problems which are numerous and various. Excel’s non-quitting is just an example.

Strategy #2 requires that you define:
a) a proper moment(s);
b) what COM objects will be released at this moment;
c) what COM objects will live until the next such moment (or to the end) ;
d) how all this stuff will behave in different scenarios in different Excel versions.

Besides, running GC is a time-consuming operation.

Strategy #3 requires that you explicitly declare variables to hold EVERY COM object you create (such as oApp.Workbooks above) and apply Marshal.ReleaseComObject to every variable as soon as you don’t need the corresponding COM object. This is a scrupulous approach. But this is exactly what COM Rule #1 says: if you create a COM object, then you must release it. That is, following this approach is correct and expected. It does no harm, it does good only.

In When to release COM objects in Office add-ins developed in .NET, I voted for using Marshal.ReleaseComObject(). Note that Microsoft votes for it too, see the article I mentioned in my reply to the forum question.