Excel interop from ASP.NET - Process can't be killed

[Lars-Erik Aabech]

Hi!

This issue have been discussed a lot, but I haven't found a solution that
applies to ASP.NET. I have a library which does some operations on Excel
documents, and it will be used in an ASP.NET application. If I use the
library in a Forms application, the Excel process is removed when the
cleanup operations are done, but with ASP.NET all possible ways to clean up
fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone, but when
called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to the Win32
api to find some functions. Et voila, we find GetWindowThreadProcessId. But
what do you know? When the method is called from a windows app, the process
ID is filled and we can kill the process, but when called from ASP.NET, the
process ID is 0, the thread ID is 0, and Excel is still lingering about..

I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[Joyjit Mukherjee]

Hi,

try System.GC.Collect to cleanup all COM objects forcefully after you
finished off using them.

HTH
Regards
Joyjit

"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in
message news:OQ**************@tk2msftngp13.phx.gbl...

Hi!

This issue have been discussed a lot, but I haven't found a solution that
applies to ASP.NET. I have a library which does some operations on Excel
documents, and it will be used in an ASP.NET application. If I use the
library in a Forms application, the Excel process is removed when the
cleanup operations are done, but with ASP.NET all possible ways to clean up fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone, but when
called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to the Win32 api to find some functions. Et voila, we find GetWindowThreadProcessId. But what do you know? When the method is called from a windows app, the process ID is filled and we can kill the process, but when called from ASP.NET, the process ID is 0, the thread ID is 0, and Excel is still lingering about..

I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[Lars-Erik Aabech]

I did. Forgot to include it in the sample code.
Also tried GC.WaitForPendingFinalizers().

Still no cigar...

L-E

"Joyjit Mukherjee" <jo**************@hotmail.com> wrote in message
news:e6**************@TK2MSFTNGP12.phx.gbl...

Hi,

try System.GC.Collect to cleanup all COM objects forcefully after you
finished off using them.

HTH
Regards
Joyjit

"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in
message news:OQ**************@tk2msftngp13.phx.gbl...

Hi!

This issue have been discussed a lot, but I haven't found a solution that applies to ASP.NET. I have a library which does some operations on Excel
documents, and it will be used in an ASP.NET application. If I use the
library in a Forms application, the Excel process is removed when the
cleanup operations are done, but with ASP.NET all possible ways to clean

up

fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone, but when called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to the

Win32

api to find some functions. Et voila, we find GetWindowThreadProcessId.

But

what do you know? When the method is called from a windows app, the

process

ID is filled and we can kill the process, but when called from ASP.NET,

the

process ID is 0, the thread ID is 0, and Excel is still lingering about..
I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[bruce barker]

microsoft does not recommend this approach:

http://support.microsoft.com/default...b;EN-US;257757

here is the workaround to do the exit

http://support.microsoft.com/default...b;EN-US;317109

-- bruce (sqlwork.com)
"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in
message news:OQ**************@tk2msftngp13.phx.gbl...

Hi!

This issue have been discussed a lot, but I haven't found a solution that
applies to ASP.NET. I have a library which does some operations on Excel
documents, and it will be used in an ASP.NET application. If I use the
library in a Forms application, the Excel process is removed when the
cleanup operations are done, but with ASP.NET all possible ways to clean up fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone, but when
called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to the Win32 api to find some functions. Et voila, we find GetWindowThreadProcessId. But what do you know? When the method is called from a windows app, the process ID is filled and we can kill the process, but when called from ASP.NET, the process ID is 0, the thread ID is 0, and Excel is still lingering about..

I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[Lars-Erik Aabech]

I've tried all the workarounds. As you can see from my previous posts, the
..Net client releases excel when ran as a windows application or service.
Only when ran as ASP.NET Excel will stay around. Might be that I have to
create and release a reference to Worksheets too though, but I've allready
rewritten the code to use ADO for this problem. Anyway, thanks for the help
ppl - hope this issue will be resolved for office 2005 ;)

Lars-Erik
"bruce barker" <no***********@safeco.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...

microsoft does not recommend this approach:

http://support.microsoft.com/default...b;EN-US;257757

here is the workaround to do the exit

http://support.microsoft.com/default...b;EN-US;317109

-- bruce (sqlwork.com)
"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in
message news:OQ**************@tk2msftngp13.phx.gbl...

Hi!

This issue have been discussed a lot, but I haven't found a solution that applies to ASP.NET. I have a library which does some operations on Excel
documents, and it will be used in an ASP.NET application. If I use the
library in a Forms application, the Excel process is removed when the
cleanup operations are done, but with ASP.NET all possible ways to clean

up

fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone, but when called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to the

Win32

api to find some functions. Et voila, we find GetWindowThreadProcessId.

But

what do you know? When the method is called from a windows app, the

process

ID is filled and we can kill the process, but when called from ASP.NET,

the

process ID is 0, the thread ID is 0, and Excel is still lingering about..
I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[abillmeier]

Ever get this to work?
Having the exact same issue.
Excel continues to run, even after releasing the coms, and when I try
and get the process ID I am rewarded with a 0.


Lars-Erik Aabech wrote:

I've tried all the workarounds. As you can see from my previous posts, the .Net client releases excel when ran as a windows application or service. Only when ran as ASP.NET Excel will stay around. Might be that I have to create and release a reference to Worksheets too though, but I've allready rewritten the code to use ADO for this problem. Anyway, thanks for the help ppl - hope this issue will be resolved for office 2005 ;)

Lars-Erik
"bruce barker" <no***********@safeco.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...

microsoft does not recommend this approach:

http://support.microsoft.com/default...b;EN-US;257757

here is the workaround to do the exit

http://support.microsoft.com/default...b;EN-US;317109

-- bruce (sqlwork.com)
"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in

message news:OQ**************@tk2msftngp13.phx.gbl...

Hi!

This issue have been discussed a lot, but I haven't found a solution

that applies to ASP.NET. I have a library which does some operations

on Excel documents, and it will be used in an ASP.NET application. If I use the library in a Forms application, the Excel process is removed when the cleanup operations are done, but with ASP.NET all possible ways

to clean up

fails.

The following code has been tried:

Application app = new ApplicationClass();
Workbook wb = null;

// some code... no sheet reference done, only doing wb.load, x =
wb.Worksheets.Count, wb.close

// release workbook
ReleaseComObject(wb);
wb = null;

app.Quit();
ReleaseComObject(app);
app = null;

When the method is called from a windows app, Excel is now gone,

but

when called from ASP.NET the Excel process remains.

So we gathered that the process had to be killed manually. Off to

the Win32

api to find some functions. Et voila, we find

GetWindowThreadProcessId. But

what do you know? When the method is called from a windows app,

the process

ID is filled and we can kill the process, but when called from

ASP.NET, the

process ID is 0, the thread ID is 0, and Excel is still lingering

about..
I for one am ready to be committed to the local asylum...

Any help greatly appreciated......

Lars-Erik

[Johnny Fugazzi]

Here is a code snippit of what I am trying to do. In general I am doing
the following.

1. creating an excel object
2. loading an xls file into the object
3. reading a value from the file and then updating a value in the file.
4. saving and closing the file.
5. quiting the excel object.
6. attempting to determine the Process ID of the hanging Excel object and
then terminate it. So far I only get a ProcessID of Zero, however.

***********************
Dim xExcel As New Excel.Application

Dim xBook As Object

Dim xBooks As Object

Dim xSheets As Object

Dim xSheet As Object

Dim xRange As Object

xBooks = xExcel.Workbooks

xBook = xBooks.Open(Filename:=strExcelFile, UpdateLinks:=False,
ReadOnly:=False)

Dim objPtr As New IntPtr

Dim intID As Integer = 0

Dim i As Integer = 0

objPtr = New System.IntPtr(xExcel.Hwnd)

i = GetWindowThreadProcessId(objPtr, intID)

If intID > 0 Then

Dim pExcel As New System.Diagnostics.Process

pExcel = System.Diagnostics.Process.GetProcessById(intID)

pExcel.Kill()

End If

[David Jessee]

Run....Run fast!

If you look at Microsoft's web site, they strongly discourage anyone from
using office applications from inside of asp.net. If there is any way
around it, then do it. One option would be to use Sql Reporting Services to
create a report and then export that report to an Excel file (file stream
you send back to the client).
"abillmeier" <ab********@ldmkusa.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Ever get this to work?
Having the exact same issue.
Excel continues to run, even after releasing the coms, and when I try
and get the process ID I am rewarded with a 0.


Lars-Erik Aabech wrote:

I've tried all the workarounds. As you can see from my previous

posts, the

.Net client releases excel when ran as a windows application or

service.

Only when ran as ASP.NET Excel will stay around. Might be that I have

to

create and release a reference to Worksheets too though, but I've

allready

rewritten the code to use ADO for this problem. Anyway, thanks for

the help

ppl - hope this issue will be resolved for office 2005 ;)

Lars-Erik
"bruce barker" <no***********@safeco.com> wrote in message
news:Os**************@tk2msftngp13.phx.gbl...

microsoft does not recommend this approach:

http://support.microsoft.com/default...b;EN-US;257757

here is the workaround to do the exit

http://support.microsoft.com/default...b;EN-US;317109

-- bruce (sqlwork.com)
"Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK> wrote in message news:OQ**************@tk2msftngp13.phx.gbl...
> Hi!
>
> This issue have been discussed a lot, but I haven't found a solution

that

> applies to ASP.NET. I have a library which does some operations

on Excel > documents, and it will be used in an ASP.NET application. If I use the > library in a Forms application, the Excel process is removed when the > cleanup operations are done, but with ASP.NET all possible ways to clean up
> fails.
>
> The following code has been tried:
>
> Application app = new ApplicationClass();
> Workbook wb = null;
>
> // some code... no sheet reference done, only doing wb.load, x =
> wb.Worksheets.Count, wb.close
>
> // release workbook
> ReleaseComObject(wb);
> wb = null;
>
> app.Quit();
> ReleaseComObject(app);
> app = null;
>
> When the method is called from a windows app, Excel is now gone, but

when

> called from ASP.NET the Excel process remains.
>
> So we gathered that the process had to be killed manually. Off to

the Win32
> api to find some functions. Et voila, we find GetWindowThreadProcessId. But
> what do you know? When the method is called from a windows app, the process
> ID is filled and we can kill the process, but when called from ASP.NET, the
> process ID is 0, the thread ID is 0, and Excel is still lingering

about..

>
> I for one am ready to be committed to the local asylum...
>
> Any help greatly appreciated......
>
> Lars-Erik
>
>

[Johnny Fugazzi]

Yeah. I know it is STRONGLY discouraged, but it is a request from above and
I need to find out if/how to do it regardless of the warnings.

In theory the code should work. I know it's not elegant.

The Excel part works great, except for leaving a hanging process. After
trying all of the MS reccomendations, I figured it might be best to just
identify the process ID of the hanger and then outright kill it. It is the
identification of the process ID that I am having a problem with at the
moment as it always comes back 0.

Any idea what is wrong?

Are there permissions retrictions that would stop the page from lookingup a
process id. Are there permission restrictions that will also stop me from
killing a process that was started by the page?


"David Jessee" <dj*****@houston.rr.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

Run....Run fast!

If you look at Microsoft's web site, they strongly discourage anyone from
using office applications from inside of asp.net. If there is any way
around it, then do it. One option would be to use Sql Reporting Services
to
create a report and then export that report to an Excel file (file stream
you send back to the client).
"abillmeier" <ab********@ldmkusa.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Ever get this to work?
Having the exact same issue.
Excel continues to run, even after releasing the coms, and when I try
and get the process ID I am rewarded with a 0.


Lars-Erik Aabech wrote:

> I've tried all the workarounds. As you can see from my previous

posts, the

> .Net client releases excel when ran as a windows application or

service.

> Only when ran as ASP.NET Excel will stay around. Might be that I have

to

> create and release a reference to Worksheets too though, but I've

allready

> rewritten the code to use ADO for this problem. Anyway, thanks for

the help

> ppl - hope this issue will be resolved for office 2005 ;)
>
> Lars-Erik
>
>
> "bruce barker" <no***********@safeco.com> wrote in message
> news:Os**************@tk2msftngp13.phx.gbl...
> > microsoft does not recommend this approach:
> >
> > http://support.microsoft.com/default...b;EN-US;257757
> >
> > here is the workaround to do the exit
> >
> > http://support.microsoft.com/default...b;EN-US;317109
> >
> >
> >
> > -- bruce (sqlwork.com)
> >
> >
> > "Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK>

wrote in

> > message news:OQ**************@tk2msftngp13.phx.gbl...
> > > Hi!
> > >
> > > This issue have been discussed a lot, but I haven't found a

solution

> that
> > > applies to ASP.NET. I have a library which does some operations

on Excel

> > > documents, and it will be used in an ASP.NET application. If I

use the

> > > library in a Forms application, the Excel process is removed when

the

> > > cleanup operations are done, but with ASP.NET all possible ways

to clean

> > up
> > > fails.
> > >
> > > The following code has been tried:
> > >
> > > Application app = new ApplicationClass();
> > > Workbook wb = null;
> > >
> > > // some code... no sheet reference done, only doing wb.load, x =
> > > wb.Worksheets.Count, wb.close
> > >
> > > // release workbook
> > > ReleaseComObject(wb);
> > > wb = null;
> > >
> > > app.Quit();
> > > ReleaseComObject(app);
> > > app = null;
> > >
> > > When the method is called from a windows app, Excel is now gone,

but

> when
> > > called from ASP.NET the Excel process remains.
> > >
> > > So we gathered that the process had to be killed manually. Off to

the

> > Win32
> > > api to find some functions. Et voila, we find

GetWindowThreadProcessId.

> > But
> > > what do you know? When the method is called from a windows app,

the

> > process
> > > ID is filled and we can kill the process, but when called from

ASP.NET,

> > the
> > > process ID is 0, the thread ID is 0, and Excel is still lingering
> about..
> > >
> > > I for one am ready to be committed to the local asylum...
> > >
> > > Any help greatly appreciated......
> > >
> > > Lars-Erik
> > >
> > >
> >
> >

[Martin Dechev]

"Johnny Fugazzi" <re*******************@ldmkusa.com> wrote in message
news:Oc**************@TK2MSFTNGP14.phx.gbl...

<snip>

objPtr = New System.IntPtr(xExcel.Hwnd)

The excel application is run from a non-interactive user acount in this
case, so it doesn't interact with the desktop and doesn't have a window.

Your best shot would be to use platform invoke to find and exit the
process - EnumProcesses (psapi.dll), OpenProcess (kernel32.dll),
GetModuleBaseName (psapi.dll), ExitProcess (kernel32.dll) and CloseHandle
(kernel32.dll).

Hope this helps
Martin Dechev
ASP.NET MVP

[David Jessee]

Then do 2 things.

First, research finding processes and how to kill them (you'll be looking
for Excel.exe...its case sensitive)

Secondly, tell the client that the solution will be unstable, as per
Microsoft's warnings unless they choose to invest in a 3rd party product
that can perform this functionality. You need to keep your posterior
covered because when the server locks up, they need to know that it was
their decision that made it happen.
"Johnny Fugazzi" <re*******************@ldmkusa.com> wrote in message
news:uy****************@TK2MSFTNGP12.phx.gbl...

Yeah. I know it is STRONGLY discouraged, but it is a request from above and I need to find out if/how to do it regardless of the warnings.

In theory the code should work. I know it's not elegant.

The Excel part works great, except for leaving a hanging process. After
trying all of the MS reccomendations, I figured it might be best to just
identify the process ID of the hanger and then outright kill it. It is the identification of the process ID that I am having a problem with at the
moment as it always comes back 0.

Any idea what is wrong?

Are there permissions retrictions that would stop the page from lookingup a process id. Are there permission restrictions that will also stop me from
killing a process that was started by the page?


"David Jessee" <dj*****@houston.rr.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...

Run....Run fast!

If you look at Microsoft's web site, they strongly discourage anyone from using office applications from inside of asp.net. If there is any way
around it, then do it. One option would be to use Sql Reporting Services to
create a report and then export that report to an Excel file (file stream you send back to the client).
"abillmeier" <ab********@ldmkusa.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Ever get this to work?
Having the exact same issue.
Excel continues to run, even after releasing the coms, and when I try
and get the process ID I am rewarded with a 0.


Lars-Erik Aabech wrote:
> I've tried all the workarounds. As you can see from my previous
posts, the
> .Net client releases excel when ran as a windows application or
service.
> Only when ran as ASP.NET Excel will stay around. Might be that I have
to
> create and release a reference to Worksheets too though, but I've
allready
> rewritten the code to use ADO for this problem. Anyway, thanks for
the help
> ppl - hope this issue will be resolved for office 2005 ;)
>
> Lars-Erik
>
>
> "bruce barker" <no***********@safeco.com> wrote in message
> news:Os**************@tk2msftngp13.phx.gbl...
> > microsoft does not recommend this approach:
> >
> > http://support.microsoft.com/default...b;EN-US;257757
> >
> > here is the workaround to do the exit
> >
> > http://support.microsoft.com/default...b;EN-US;317109
> >
> >
> >
> > -- bruce (sqlwork.com)
> >
> >
> > "Lars-Erik Aabech" <la**************@markedspartner.noSPAMBLOCK>
wrote in
> > message news:OQ**************@tk2msftngp13.phx.gbl...
> > > Hi!
> > >
> > > This issue have been discussed a lot, but I haven't found a
solution
> that
> > > applies to ASP.NET. I have a library which does some operations
on Excel
> > > documents, and it will be used in an ASP.NET application. If I
use the
> > > library in a Forms application, the Excel process is removed when
the
> > > cleanup operations are done, but with ASP.NET all possible ways
to clean
> > up
> > > fails.
> > >
> > > The following code has been tried:
> > >
> > > Application app = new ApplicationClass();
> > > Workbook wb = null;
> > >
> > > // some code... no sheet reference done, only doing wb.load, x =
> > > wb.Worksheets.Count, wb.close
> > >
> > > // release workbook
> > > ReleaseComObject(wb);
> > > wb = null;
> > >
> > > app.Quit();
> > > ReleaseComObject(app);
> > > app = null;
> > >
> > > When the method is called from a windows app, Excel is now gone,
but
> when
> > > called from ASP.NET the Excel process remains.
> > >
> > > So we gathered that the process had to be killed manually. Off to
the
> > Win32
> > > api to find some functions. Et voila, we find
GetWindowThreadProcessId.
> > But
> > > what do you know? When the method is called from a windows app,
the
> > process
> > > ID is filled and we can kill the process, but when called from
ASP.NET,
> > the
> > > process ID is 0, the thread ID is 0, and Excel is still lingering
> about..
> > >
> > > I for one am ready to be committed to the local asylum...
> > >
> > > Any help greatly appreciated......
> > >
> > > Lars-Erik
> > >
> > >
> >
> >