Excel does not die using automation

  • Thread starter Thread starter Terry Holland
  • Start date Start date
T

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?
 
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.
 
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
 
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
 
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
 
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?
Click to expand...

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
 
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.
 
Jeff Winn said:
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.
Click to expand...

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
 
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.
 
Jeff Winn said:
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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
 
Back
Top