How to properly release Excel COM objects

Posted on Tuesday, November 5th, 2013 at 7:18 am by  Pieter van der Westhuizen .
 
 
You’ll see a lot of complaints on the internet about Excel and other Microsoft Office applications not quitting properly after using the object model to perform certain actions, or showing sporadic and unpredictable behavior in COM add-ins. In the end most of these issues boil down to developers not properly disposing of COM objects.
The challenge is that despite the fact that, as .Net developers we can use the Office Interop Assemblies to access the various Office object models using managed code, the PIA’s are still essentially wrapping around COM objects. So what is the problem?

A general rule of thumb

For or ForEach Loops

ReleaseComObject and FinalReleaseComObject?

GC.Collect and GC.WaitForPendingFinalizersr

Ways to kill the Excel.exe process

 

A general rule of thumb

Our very own  Andrei Smolin  wrote two great articles explaining the reasons behind  why Excel does not quit and  when to release COM objects in .Net . Both articles contain a lot of very useful and thorough advice and you’ll notice that it all starts with a simple rule:
’1 dot good, 2 dots bad’
I’m sure you’re staring at your screen with wide-eyed confusion at the moment, but this rule is actually very easy to explain. Consider the following code:

Excel.Application app = new Excel.Application(); Excel.Workbook book = app.Workbooks.Add(); Excel.Worksheet sheet = app.Sheets.Add();   sheet.Range["A1"].Value = "Lorem Ipsum"; book.SaveAs(@"C:\Temp\ExcelBook.xlsx"); book.Close(); app.Quit();

The code above will build and run without a problem, it will create a new Excel workbook, add a new sheet and set the value of the first cell in the newly created sheet. However, even after calling the Quit method of the Excel.Application object, you’ll still see the Excel.exe process in the Windows Task Managers’ list of background processes.
This strange phenomenon occurs because in the above code, we’re not releasing any COM objects and we’re also “chaining” object references by using double dots. You must ALWAYS release COM objects, even if you see no adverse effects, it might work perfectly on your PC but behave entirely different on a user’s computer.
Let’s look at how to change the code in order to safely dispose of any COM objects:

Excel.Application app = null; Excel.Workbooks books = null; Excel.Workbook book = null; Excel.Sheets sheets = null; Excel.Worksheet sheet = null; Excel.Range range = null;   try { app = new Excel.Application(); books = app.Workbooks; book = books.Add(); sheets = book.Sheets; sheet = sheets.Add(); range = sheet.Range["A1"]; range.Value = "Lorem Ipsum"; book.SaveAs(@"C:\Temp\ExcelBook" + DateTime.Now.Millisecond + ".xlsx"); book.Close(); app.Quit(); } finally { if (range != null) Marshal.ReleaseComObject(range); if (sheet != null) Marshal.ReleaseComObject(sheet); if (sheets != null) Marshal.ReleaseComObject(sheets); if (book != null) Marshal.ReleaseComObject(book); if (books != null) Marshal.ReleaseComObject(books); if (app != null) Marshal.ReleaseComObject(app); }

Pay close attention to the above code, we never used more than one dot when working with objects. We also wrapped all the code in a try-finally, so even if the code throws and exception we will still safely release the COM objects using the ReleaseComObject method on the Marshal object.

For or ForEach Loops

There is no obvious reason why you should use a for-loop rather than a ForEach loop, however it is recommended that you rather use a for loop since a for-each might cause some unexpected behavior and your code to hang. Consider the following code:

Excel.Application app = null; Excel.Workbooks books = null; Excel.Workbook book = null; Excel.Sheets sheets = null;   try { app = new Excel.Application(); books = app.Workbooks; book = books.Open(@"C:\Temp\ExcelBook.xlsx"); sheets = book.Sheets;   foreach (Excel.Worksheet sheet in sheets) { Console.WriteLine(sheet.Name); Marshal.ReleaseComObject(sheet); }   book.Close(); app.Quit(); } finally { if (sheets != null) Marshal.ReleaseComObject(sheets); if (book != null) Marshal.ReleaseComObject(book); if (books != null) Marshal.ReleaseComObject(books); if (app != null) Marshal.ReleaseComObject(app); }

In the above code, everything appears to be fine. We did not use more than one dot and we safely released all COM objects using a try-finally code clock. However, using a foreach loop to loop through the Sheets collection of the Excel.Workbook object automatically generates the enumerator behind the foreach statement that uses an internal COM object, which needs to be released..
To be on the safe side, you should avoid using a foreach loop and rather use a normal for loop, and release each COM object in the collection, as illustrated below:

Excel.Application app = null; Excel.Workbooks books = null; Excel.Workbook book = null; Excel.Sheets sheets = null;   try { app = new Excel.Application(); books = app.Workbooks; book = books.Open(@"C:\Temp\ExcelBook1Sheets.xlsx"); sheets = book.Sheets;   for (int i = 1; i <= sheets.Count; i++) { Excel.Worksheet sheet = sheets.Item[i]; Console.WriteLine(sheet.Name); if (sheet != null) Marshal.ReleaseComObject(sheet); } book.Close(); app.Quit(); } finally { if (sheets != null) Marshal.ReleaseComObject(sheets); if (book != null) Marshal.ReleaseComObject(book); if (books != null) Marshal.ReleaseComObject(books); if (app != null) Marshal.ReleaseComObject(app); }

ReleaseComObject & FinalReleaseComObject?

When you access an Office COM object via the interop assemblies, the .Net framework automatically wraps it in a  Runtime Callable Wrapper , the RCW object is also responsible for controlling the objects’ lifetime.
Keep in mind that the .Net runtime creates one RCW for each COM object. So, no matter how many references you have to a specific COM object, there will always be just one Runtime Callable Wrapper for it. As you create more references to a certain COM object the RCW’s reference count will increase and this is where the ReleaseComObject and FinalReleaseComObject come into play.
Both methods are used to release references to a RCW, ReleaseComObject simply decreases the reference count of a specific RCW, whereas FinalReleaseComObject releases ALL references to the RCW and sets the reference count to zero.
Essentially, calling FinalReleaseComObject would be similar to creating a for-loop and callingReleaseComObject until its reference count is zero. When the reference count is zero, it means the object is ready to be garbage collected.
Both methods need to be used with a relative degree of caution, if you release a COM object and try to access it afterwards an  InvalidComObjectException  will be shown with the following message:
“COM object that has been separated from its underlying RCW cannot be used”
As a rule we never use FinalReleaseComObject, by calling ReleaseComObject the reference counter should be decreased and if everything is correct the COM object should be properly released with a single call.FinalReleaseComObject is redundant and might cause unexpected results and a whole lot of pain.

GC.Collect & GC.WaitForPendingFinalizers

The generally accepted best practice is not to force a garbage collection in the majority of cases; however, you can release COM objects using the .Net garbage collector, as long as there are no references to the objects. In other words, the objects are set to null. Be aware that GC.Collect can be a time consuming process depending on the number of objects.
You would also need to call GC.Collect and GC.WaitForPendingFinalizers twice when working with Office COM objects since the first time you call the methods we only release objects that we are not referencing with our own variables. The second time the two methods are called is because the RCW for each COM object needs to run a finalizer that actually fully removes the COM Object from memory.
So, it is totally acceptable to see the following code in you COM add-in projects:

GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); GC.WaitForPendingFinalizers();

Ways to kill the Excel.exe process

WM_CLOSE

Of course, there are ways to kill the Excel process if you have to. One such way is to send a WM_CLOSE message to the Excel windows in order for it to terminate. First, you’ll need to use the DLLImportattribute to invoke the SendMessage method contained in the user32 dll. Do this by adding the following code at the top of your class:

[DllImport("user32.dll", CharSet = CharSet.Auto)] private static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wParam, IntPtr lParam);

The trickiest part of this is to get the window id or hWnd of the main Excel window. Luckily, if you’ve accessed the Excel object model you can retrieve the main windows’ hWnd by checking the Hwnd property on the ActiveWindow object. The ActiveWindow object is a property on the Excel.Application object. If the Excel version you’re targeting does not have the Hwnd property on the Application object, you can use late-binding to access it, as illustrated below.

Excel.Application app = new Excel.Application(); hWnd = app.Hwnd;

After you’ve retrieved the hWnd value, call the SendMessage method as indicated below, to force the main Excel window to close:

SendMessage((IntPtr)hWnd, 0x10, IntPtr.Zero, IntPtr.Zero);

Process.Kill

An easier way kill all Excel processes, is to use the Kill method of the .Net Process object. The object can be found in the System.Diagnostics namespace. The following code will retrieve all the Excel processes and kill each one:

Process[] excelProcs = Process.GetProcessesByName("EXCEL"); foreach (Process proc in excelProcs) { proc.Kill(); }

Windows Job Objects

Lastly, you could also use the  Windows Job Objects  to properly dispose of the Excel process even if it takes a bit more work to get going. First you need to add a new class to your project:

namespace JobManagement
{ public class Job : IDisposable { [DllImport("kernel32.dll", CharSet = CharSet.Unicode)] static extern IntPtr CreateJobObject(IntPtr a, string lpName);   [DllImport("kernel32.dll")] static extern bool SetInformationJobObject(IntPtr hJob, JobObjectInfoType infoType, IntPtr lpJobObjectInfo, UInt32 cbJobObjectInfoLength);   [DllImport("kernel32.dll", SetLastError = true)] static extern bool AssignProcessToJobObject(IntPtr job, IntPtr process);   [DllImport("kernel32.dll", SetLastError = true)] static extern bool CloseHandle(IntPtr hObject);   private IntPtr handle; private bool disposed;   public Job() { handle = CreateJobObject(IntPtr.Zero, null);   var info = new JOBOBJECT_BASIC_LIMIT_INFORMATION { LimitFlags = 0x2000 };   var extendedInfo = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION { BasicLimitInformation = info };   int length = Marshal.SizeOf(typeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION)); IntPtr extendedInfoPtr = Marshal.AllocHGlobal(length); Marshal.StructureToPtr(extendedInfo, extendedInfoPtr, false);   if (!SetInformationJobObject(handle, JobObjectInfoType.ExtendedLimitInformation, extendedInfoPtr, (uint)length)) throw new Exception(string.Format("Unable to set information. Error: {0}", Marshal.GetLastWin32Error())); }   public void Dispose() { Dispose(true); GC.SuppressFinalize(this); }   private void Dispose(bool disposing) { if (disposed) return;   if (disposing) { }   Close(); disposed = true; }   public void Close() { CloseHandle(handle); handle = IntPtr.Zero; }   public bool AddProcess(IntPtr processHandle) { return AssignProcessToJobObject(handle, processHandle); }   public bool AddProcess(int processId) { return AddProcess(Process.GetProcessById(processId).Handle); }   }   #region Helper classes   [StructLayout(LayoutKind.Sequential)] struct IO_COUNTERS { public UInt64 ReadOperationCount; public UInt64 WriteOperationCount; public UInt64 OtherOperationCount; public UInt64 ReadTransferCount; public UInt64 WriteTransferCount; public UInt64 OtherTransferCount; }   [StructLayout(LayoutKind.Sequential)] struct JOBOBJECT_BASIC_LIMIT_INFORMATION { public Int64 PerProcessUserTimeLimit