Excel does not quit after automation from .NET side
Hello, I am Colbert from MSDN Forum Support team. I believe most of Excel developers encounter this very famous issue when automating Excel from .NET side, C# or VB.NET.
As a support engineer in MSDN support team, I have seen many reports about this in MSDN forum and newsgroup. Here are some scenarios, analyses, solutions to the kind of problem.
The typical scenario:
Considering the following simple codes,
1: static void Main(string[] args)
2: {
3: Excel.Application excel = new Excel.Application();
4: Workbook workbook = excel.Workbooks.Add(Type.Missing);
5: Marshal.FinalReleaseComObject(workbook);
6: excel.Quit();
7: Marshal.FinalReleaseComObject(excel);
8: Console.ReadKey();
9: }
10:
After the codes execute to Console.ReadKey(), we can still see Excel process does not quit in background. I am not going to too detailed on this because you can find a very nice article about this from Geoff Darst’s blog article,
(https://blogs.msdn.com/geoffda/archive/2007/09/07/the-designer-process-that-would-not-terminate-part-2.aspx). The short answer is excel.Workbooks.Add has created a RCW of Workbooks on the heap but not referencing it. To correct it, we should modify the codes to keep a reference of Workbooks and release it.
1: static void Main(string[] args)
2: {
3: Excel.Application excel = new Excel.Application();
4: Workbooks workbooks = excel.Workbooks;
5: Workbook workbook = workbooks.Add(Type.Missing);
6: Marshal.FinalReleaseComObject(workbook);
7: Marshal.FinalReleaseComObject(workbooks);
8: Console.ReadKey();
9: }
10:
Although, in most of scenarios, as long as we follow the rule that referencing every object in a variable and releasing it later, it should work fine, but there are still exceptions. Here are my experiences,
1. Your Excel loads a managed AddIn(Shared AddIn or VSTO AddIn), which breaks the rule. After your application automates the Excel application, Excel application could not exit correctly because the loaded AddIn has some underlying RCWs not released. In this condition, the Excel does not quit even if your automation client terminates. So a step to troubleshoot this kind of issue would be disabling all AddIns to isolate the root cause. J
2. Recently, another report on a similar issue takes me some time to research and lead to another scenario. We have written some very simple codes that automate Excel to do a simple task like above codes. The codes look all right. Actually it works in a Console application. But if we put it in a WebService application, when debugging from Visual Studio, it works. While deploying to IIS, it fails and Excel does not quit again. Finally, it turns out automation across session causes it fails. If we run the codes in Console application, or debug the WebService from Visual Studio, our application is executed under session2 which is same for the target Excel. If we deploy the web service to IIS, w3wp.exe is executed under session0(NETWORK Service account), but the target Excel executes under session2(interactive user account). This looks like another point that Office application does not support server side automation very well.
You can read the case log from this link,
https://office-outlook.com/outlook-forum/index.php/m/643633/#msg_643633
Comments
Anonymous
August 07, 2010
Office automation doesn't work in server environment, because it is designed as a GUI application and needs so called "window station" ,etc. There is an explanation: support.microsoft.com/.../257757Anonymous
January 02, 2015
In the second example you are defining an object but not assigning it to nothing: Workbooks workbooks = excel.Workbooks; so if you then use this: Workbook workbook = workbooks.Add(Type.Missing); you will get a null reference error. I´m right?