Excel does not die using automation

[Terry Holland]

I have a vb.net app that opens an excel worksheet, reads data and then closes
the sheet. Im noticing that the Excel process is still running after I have
closed and disposed of my excel objects.

The following code (Test1) demonstrates the essence of what I am doing.
When I check the processes while ruinning the method, I notice that the Excel
process remains after exiting the sub (and until I exit the application)

Sub Test1
Dim objExcelApp As New Excel.Application

Dim objExcelWorkBook As Excel.Workbook =
objExcelApp.Workbooks.Open("C:\Test.xls")
Dim objExcelWorksheet As Excel.Worksheet = objExcelWorkBook.Sheets(1)

Dim objRange As Excel.Range
objRange = objExcelWorksheet.Range("A1")
MsgBox(objRange.Text)
''http://www.vbforums.com/archive/index.php/t-396405.html
objRange = Nothing
objExcelWorksheet = Nothing
objExcelWorkBook.Close()
objExcelWorkBook = Nothing
objExcelApp.Workbooks.Close()
objExcelApp.Quit()

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

objExcelApp = Nothing

End Sub

When I strip the code dow to this (Test2) I notice that the process is
created on line
Dim objExcelApp As New Excel.Application
and killed on line
System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

Sub Test2
Dim objExcelApp As New Excel.Application

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

objExcelApp = Nothing
End Sub


What is it that is keeping a reference to the Excel process and how do I
kill the process?

 

[Scott M.]

You must call ReleaseComObject(obj) on EACH COM object you've created.

That means on the Range, Worksheet, Workbook, Chart, PivotTable, etc.
objects one might instantiate within the Excel.Application.

 

[Terry Holland]

Using the following as test code, the Excel process remains. Can you see a
reason for this?

Sub Test
Dim objExcelApp As New Excel.Application
Dim objExcelWorkBook As Excel.Workbook =
objExcelApp.Workbooks.Open("C:\Test.xls")
Dim objExcelWorksheet As Excel.Worksheet = objExcelWorkBook.Sheets(1)
Dim objRange As Excel.Range

objRange = objExcelWorksheet.Range("A1")
MsgBox(objRange.Text)

objExcelWorkBook.Close()
objExcelApp.Quit()

System.Runtime.InteropServices.Marshal.ReleaseComObject(objRange)

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelWorksheet)

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelWorkBook)
System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

objRange = Nothing
objExcelWorksheet = Nothing
objExcelWorkBook = Nothing
objExcelApp = Nothing
End Sub

 

[Scott M.]

Are you checking to see if Excel is running when you are debugging your code
in Visual Studio?

If so, you shouldn't as this isn't going to give you an accurate
representation of processes. When I compile your code into an .exe and run
that .exe directly with Task Manager open, Excel comes up and then drops off
the list after my method call to do the Excel stuff finishes and my console
sits open waiting for input via a Console.Read.

-Scott

 

[Terry Holland]

I was doing this in debug mode. I have done as you suggested and run the
compiled exe (winforms). The excel process is still running after executing
the code. The process is only killed when the form is closed. I have no
other code on this form other than a button_click event to execute the code.

I then tried the same thing as console app as you have done and in my case
the excel process is running until the console window closes

Imports Microsoft.Office.Interop

Module Module1

Sub Main()
Dim objExcelApp As New Excel.Application
Dim objExcelWorkBook As Excel.Workbook =
objExcelApp.Workbooks.Open("C:\Test.xls")
Dim objExcelWorksheet As Excel.Worksheet = objExcelWorkBook.Sheets(1)
Dim objRange As Excel.Range

objRange = objExcelWorksheet.Range("A1")
Console.WriteLine(objRange.Text)
'Console.Read()


objExcelWorkBook.Close()
objExcelApp.Quit()

System.Runtime.InteropServices.Marshal.ReleaseComObject(objRange)

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelWorksheet)

System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelWorkBook)
System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

objRange = Nothing
objExcelWorksheet = Nothing
objExcelWorkBook = Nothing
objExcelApp = Nothing

Console.WriteLine("Waiting")
Console.Read()
End Sub

End Module

 

[Scott M.]

What version of .NET are you using? Excel closes in my console app when I
try.

 

[Terry Holland]

im using .net 2.0

What version of .NET are you using? Excel closes in my console app when I
try.

 

[ZSvedic]

I have a vb.net app that opens anexcelworksheet, reads data and then closes
the sheet.  Im noticing that theExcelprocess is still running after I have
closed and disposed of myexcelobjects.

The following code (Test1) demonstrates the essence of what I am doing.  
When I check the processes while ruinning the method, I notice that theExcel
process remains after exiting the sub (and until I exit the application)

Sub Test1
           Dim objExcelApp As NewExcel.Application

        Dim objExcelWorkBook AsExcel.Workbook =
objExcelApp.Workbooks.Open("C:\Test.xls")
        Dim objExcelWorksheet AsExcel.Worksheet = objExcelWorkBook.Sheets(1)

        Dim objRange AsExcel.Range
        objRange = objExcelWorksheet.Range("A1")
        MsgBox(objRange.Text)
        ''http://www.vbforums.com/archive/index.php/t-396405.html
        objRange = Nothing
        objExcelWorksheet = Nothing
        objExcelWorkBook.Close()
        objExcelWorkBook = Nothing
        objExcelApp.Workbooks.Close()
        objExcelApp.Quit()

        System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

        objExcelApp = Nothing

End Sub

When I strip the code dow to this (Test2) I notice that the process is
created on line
         Dim objExcelApp As NewExcel.Application
and killed on line
        System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

Sub Test2
        Dim objExcelApp As NewExcel.Application

        System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcelApp)

        objExcelApp = Nothing
End Sub

What is it that is keeping a reference to theExcelprocess and how do I
kill the process?

I don't know if it works for you, but if you have small workbooks you
can use
our GemBox.Spreadsheet Free (http://www.gemboxsoftware.com/
GBSpreadsheetFree.htm)
Excel component for XLS/CSV/XLSX reading/writing/reporting.
Automation has many issues: http://www.gemboxsoftware.com/GBSpreadsheet.htm#Automation

--Zeljko

 

[Jeff Winn]

It looks to me like you've created a race condition. You need to call
objExcelApp.Quit() after you've released all of the COM objects you've been
using (except for the excel application instance), not before.

Also, as you've done below make sure you release the objects inversely from
the order they were instantiated. The last object you created becomes the
first object you're releasing.

Other than that, your application looks fine to me.

 

[Scott M.]

It looks to me like you've created a race condition. You need to call
objExcelApp.Quit() after you've released all of the COM objects you've
been
using (except for the excel application instance), not before.

I don't think this makes any difference whatsoever. The fact is that if you
explicitly create Excel objects and explictly release them (in the opposite
order you created them), you should have no trouble calling
ReleaseComObject() After quitting Excel.

As I said, I have the code working just fine:


Imports System.Runtime.InteropServices

Sub Test()
Dim objExcelApp As New Excel.Application
Dim objExcelWorkBook As Excel.Workbook =
objExcelApp.Workbooks.Open("C:\test.xls")
Dim objExcelWorksheet As Excel.Worksheet = objExcelWorkBook.Sheets(1)
Dim objRange As Excel.Range = objExcelWorksheet.Range("A1")
objExcelApp.Visible = True
objExcelWorkBook.Close()
objExcelApp.Quit()

Marshal.ReleaseComObject(objRange)
Marshal.ReleaseComObject(objExcelWorksheet)
Marshal.ReleaseComObject(objExcelWorkBook)
Marshal.ReleaseComObject(objExcelApp)

objRange = Nothing
objExcelWorksheet = Nothing
objExcelWorkBook = Nothing
objExcelApp = Nothing
End Sub

 

[Jeff Winn]

You don't think? The only reason it's working is because the process that
started the excel application instance has ended. Read a line from the
console in that test application you've written so the thread waits for
input and check your process list in task manager. Excel will not have
closed the process correctly. When Quit gets called, Excel should terminate
even if the application that started it is still open - if it doesn't
something is wrong.

I had a huge problem with this doing server side automation about 4 months
ago with the website (I know, you're not supposed to do it - we had no
choice in the matter) I was working on created a huge memory leak because I
wasn't releasing the COM objects correctly and Excel wasn't terminating.

The objects must be released before the Quit method is called on the excel
instance, otherwise the Excel process is going to hang in limbo until the
process that started it closes. In my case since it was a website they
wouldn't ever close, thus the memory leak I had to find.

 

[Scott M.]

You don't think? The only reason it's working is because the process that
started the excel application instance has ended. Read a line from the
console in that test application you've written so the thread waits for
input and check your process list in task manager. Excel will not have
closed the process correctly.

I don't think you've read my posts. I do have a Console.ReadLine() in there
for just that purpose and Excel has been terminated.

When Quit gets called, Excel should terminate even if the application that
started it is still open - if it doesn't something is wrong.

No, Excel should terminate when all the ReleaseComObject() calls have
completed, not when .Quit() is called. Since the ReleaseComObject() calls
come AFTER quit (as they should), you won't see Excel's process actually
terminate until then. What you will see immediately after Quit is the Excel
UI shutdown.

I had a huge problem with this doing server side automation about 4 months
ago with the website (I know, you're not supposed to do it - we had no
choice in the matter) I was working on created a huge memory leak because
I wasn't releasing the COM objects correctly and Excel wasn't terminating.

The objects must be released before the Quit method is called on the excel
instance, otherwise the Excel process is going to hang in limbo until the
process that started it closes. In my case since it was a website they
wouldn't ever close, thus the memory leak I had to find.

Again, I'm telling you that you calling RelaseComObject() prior to calling
Quit() will not have any bearing on Excel terminating.

In order for Excel to terminate, the CLR must relase all of its references
to the unmanaged object. It does that when you call ReleaseComObject(obj).
Now, you certainly wouldn't want to call that while your managed code is
still using your Runtime Callable Wrappers, so you hold off on calling
ReleaseComObject(obj) until you are DONE using your .NET object references.

So this:

objExcelApp.Quit()

Marshal.ReleaseComObject(objRange)
Marshal.ReleaseComObject(objExcelWorksheet)
Marshal.ReleaseComObject(objExcelWorkBook)
Marshal.ReleaseComObject(objExcelApp)

or this:

Marshal.ReleaseComObject(objRange)
Marshal.ReleaseComObject(objExcelWorksheet)
Marshal.ReleaseComObject(objExcelWorkBook)

objExcelApp.Quit()
Marshal.ReleaseComObject(objExcelApp)

Won't make any difference because it's not the Quit() that actually shuts
down Excel's process, it's shut down when there are zero references to the
COM object, and that only occurs via ReleaseComObject(obj), not Quit().

Again, the code I've shown works if you run it outside the debugger
(console.readline and all).

-Scott