Why does Microsoft.Office.Interop.Excel.Application.Quit() leave the background process running?

Question

The following code leaves a Microsoft Excel background process running, until after my program has exited:

var excelApplication = new Application();
var workbooks = excelApplication.Workbooks;
var workbook = excelApplication.Workbooks.Open(file.FullName);

workbook.Close();
excelApplication.Workbooks.Close();
excelApplication.Quit();

Marshal.ReleaseComObject(workbook);
Marshal.ReleaseComObject(workbooks);
Marshal.ReleaseComObject(excelApplication);

Why? What am I missing?

Did you try with everything in `// do stuff` removed? The primary reason for this is some remaining references, allocated objects and so forth. — DrKoch, Jan 13 '15 at 19:53
See http://stackoverflow.com/questions/9962157/safely-disposing-excel-interop-objects-in-c — David P, Jan 13 '15 at 20:01
In my test there was nothing there but the comment. The code I posted was the full/exact code. — skinnysoftware, Jan 13 '15 at 20:09
I've updated the question. I just realized that my original test was producing deceiving results. — skinnysoftware, Jan 13 '15 at 20:34

score 33 · Accepted Answer · answered Jan 13 '15 at 20:46

33

Got it!

application.Workbooks != application.Workbooks

This property doesn't expose a variable, it generates a value. So every time I access the Workbooks property I create a new COM object.

I fixed the code and all is well. Thanks, everybody.

var excelApplication = new Application();
var workbooks = excelApplication.Workbooks;
var workbook = workbooks.Open(pathToExcelWorkbook); // Fixed

workbook.Close();
workbooks.Close();
excelApplication.Quit();

Marshal.ReleaseComObject(workbook);
Marshal.ReleaseComObject(workbooks);
Marshal.ReleaseComObject(excelApplication);

answered Jan 13 '15 at 20:46

skinnysoftware

889
1
9
14

2

Hi @eugene - Your answer certainly led me in the right direction, but I didn't find it to be specific enough to solve the entire problem. If you compare line 3 in my two code samples you will see that the problem was my failure to understand that the Workbooks property will always return a new object. – skinnysoftware Feb 09 '16 at 00:11
Right! And if man use worksheet, man shall release this object too! – Jerome Mar 13 '18 at 09:28
What did you do differently? The answer above is no different – Fandango68 Oct 09 '18 at 04:33
1

@Fandango68 - The fix is on line 3, as commented. – skinnysoftware Jan 09 '19 at 23:31

score 10 · Answer 2 · answered Jan 13 '15 at 20:12

10

This is a widely-spread issue with Office applications. All Excel add-ins/automation applications should systematically release their references to Excel objects when they are no longer needed. Failing to systematically release reference to Excel objects can prevent Microsoft Office Excel from shutting down properly. See Systematically Releasing Objects for more information. It is related to Outlook, but the same principles can be applied to all Office applications.

Use System.Runtime.InteropServices.Marshal.ReleaseComObject to release an Excel object when you have finished using it. Then set a variable to Nothing in Visual Basic (null in C#) to release the reference to the object.

answered Jan 13 '15 at 20:12

Eugene Astafiev

47,483
3
24
45

2

Seems like a reasonable response, not sure why you were downvoted – keeehlan Jan 13 '15 at 20:14
1

Is this still the case in the newer Office versions? The link you posted links to the 2007 information. And if I change the version of the documentation ("Other versions" dropdown) there is no info about System.Runtime.InteropServices.Marshal.ReleaseComObject for 2010 or 2013. – Mitja Bezenšek Jan 13 '15 at 22:56
1

The same can be applied to newer Office versions. – Eugene Astafiev Mar 01 '16 at 11:25
This still leaves the object in the task list. Setting it to NULL did not help (in C#) – Fandango68 Oct 09 '18 at 04:32

score 5 · Answer 3 · answered Jul 09 '16 at 14:50

THIS IS WRONG WAY TO DO LIKE THIS, but this is most easy way to fix the issue:

    [DllImport("user32.dll")]
    private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

    private Application _excelApp;
    private Workbook _excelWorkBook;
    private Worksheet _excelSheet;

    private void CloseExcelApp()
    {
        int hWnd = _excelApp.Application.Hwnd;
        uint processID;

        GetWindowThreadProcessId((IntPtr)hWnd, out processID);
        Process.GetProcessById((int)processID).Kill();

        _excelWorkBook = null;
        _excelApp = null;
        _excelSheet = null;
    }

all you need is to init all uninitialized variables when you need to work with it, and call CloseExcelApp() when you need to close app.

Why does Microsoft.Office.Interop.Excel.Application.Quit() leave the background process running?

3 Answers3

Linked

Related