powerpnt.exe remains running after OLE Quit()

[Andy Fish]

Hi,

I have office 2003 powerpoint with SP1 and I find that running the following
code causes powerpoint to remain in memory

Dim app As PowerPoint.Application
Dim pres As PowerPoint.Presentation
Set app = New PowerPoint.Application
Set pres = app.Presentations.Open("c:\small.ppt", msoTrue, msoFalse,
msoFalse)
pres.Close
app.Quit
Set app = Nothing

If I don't open a presentation, the app.Quit seems to quit the application
properly.

If I can explain why this is such a big deal to me, maybe someone can help
with the solution:

I absolutely *must* run a powerpoint ole process on a server (even though
microsoft don't like it). Because I had problems doing that with with Word,
I implemented a mechanism which identified the process ID of the winword.exe
so that if the OLE operation got stuck (usually because word was trying to
put up a dialog box) I could just kill the process from another thread.

The only safe way to find out the process ID of the word ole server was to
list all processes having the executable name "winword.exe" before and after
creating the application object, then just take the difference.

Now, the problem with powerpoint is that sometimes creating the application
object will start up a new powerpnt.exe and sometimes it won't. so there is
no simple way to identify the actual process.

is this behaviour by design, a bug, or is it something specific to my
installation?

Andy

 

[Austin Myers]

Andy,

You answered your own issue. PowerPoint is NOT a server application and if
you solve this issue I can all but promice you there are a truck load more
waiting for you. (BTDT) Sorry, MS is serious when they say it's not a
server app.

Austin Myers
MS PowerPoint MVP Team

PowerPoint Video and PowerPoint Sound Solutions www.pfcmedia.com

 

[Andy Fish]

well thanks for the reply but it's not particularly helpful

nothing in the world will stop me running powerpoint as a server. what I am
after is the most stable way of doing it.

 

[Austin Myers]

Andy,

You asked, I answered. In no way am I or anyone else going to try and stop
you and I wish you luck in the effort.

Austin Myers
MS PowerPoint MVP Team

PowerPoint Video and PowerPoint Sound Solutions www.pfcmedia.com

 

[Steve Rindsberg]

Hi,

I have office 2003 powerpoint with SP1 and I find that running the following
code causes powerpoint to remain in memory

Dim app As PowerPoint.Application
Dim pres As PowerPoint.Presentation
Set app = New PowerPoint.Application
Set pres = app.Presentations.Open("c:\small.ppt", msoTrue, msoFalse,
msoFalse)
pres.Close
app.Quit
Set app = Nothing

Is there other code around this, Andy?

When I run just this fragment (from Excel in this case, with a reference set to
PPT2003) it doesn't leave any open instances of PPT and PowerPnt.exe doesn't
appear in the task list. Office SP1, Windows 2000, logged in with Admin
privileges (which might have a bearing on the situation?)

 

[Mike M.]

I can chime in from the Windows 2000, System Admin, running PowerPoint 2003
from VB and C++ not having any problems getting it to quit.

 

[Brian Reilly, MVP]

So, we should support him on methods that MS says "Don't Do" and we
say "Don't Do". Must be some other bug in his code not capturing
errors which is why MS says "Don't Do".

Brian Reilly, MVP

 

[Steve Rindsberg]

So, we should support him on methods that MS says "Don't Do" and we
say "Don't Do".

My point, and I think Mike's too, is that the code Andy posted works standalone
in a non-server situation. If there's more to the code and if it can be made
to fail in a non-server situation, then sure, let's do what we can to help.

As to whether it can be made to work on a server, well ...

There'd need to be a LOT more code to examine before one could even begin to
guess what's going wrong. Then there's all the user permissions stuff and
we're still back to the "MS doesn't support it" problem.

 

[Andy Fish]

Thanks very much for these replies.

Although my original code is c# running as a windows service, the code I
posted was this was a straight cut and paste from a vb6 test program.

However, seeing these replies made me go back and re-test it, and I
discovered something a bit strange.

In the case of vb6, I put the code in the form_load event and I have
realised that powerpont.exe does indeed terminate but only when the form is
actually displayed, not when you call app.Quit. (I had just been
single-stepping it in the debugger so I never got as far as letting the form
actually display. Curiously this behaviour happens even if you don't call
app.Quit().

I tested similar code in a vbscript program with messageboxes in it, and
this time the powerpnt.exe only terminates when the script finishes
(presumably when cscript.exe terminates).

So as usual, it's not quite as simple as it seems. I don't know what it is
that makes powerpnt.exe decide to quit but it's definitely not the Quit
function. maybe it's some kind of windows message or OLE housekeeping?

Andy

 

[Steve Rindsberg]

You might want to search back a few months through this NG looking for messages
from Howard Kaikow. He's done quite a bit of testing on this issue of when and
how PPT is instantiated and released under automation.

 

[Mike M.]

Hi Andy, I use similar code in both VB and C++. My C++ app is a Windows
service that runs 7x24 with no user input. I crank up PowerPoint, generate
a bunch of presentations and then quit PowerPoint every few minutes. I know
MS says don't do this but I do it anyway. I have systems that have been
running this way or 4 years so I guess the customer test mode is over now.
Anyway, in either VB or C++ I don't see a problem. Prior to using
PowerPoint 2002 we did have some problems with the reference count for
PowerPoint 2000 and in some cases it wouldn't stop. It was before my time
but there were some comments in the code indicating this problem and when I
switch to 2002 I was able to put the code back.

Here is how my c++ app releases PowerPoint including previous comments about
issue:

// Something about COM would not allow reattachment to PowerPoint
// on the next run - just bail this out and leave everything
// running for now.

// I am going to re-instate this code with PPT 2002 they seem to have
// fixed their reference count problems.
if (m_pPowerPointActive) {
try {
m_pPowerPoint.Release();
} catch (_com_error e) {
_bstr_t message = e.Description();
}
m_pPowerPointActive = false;
}
}

Thanks very much for these replies.

Although my original code is c# running as a windows service, the code I
posted was this was a straight cut and paste from a vb6 test program.

However, seeing these replies made me go back and re-test it, and I
discovered something a bit strange.

In the case of vb6, I put the code in the form_load event and I have
realised that powerpont.exe does indeed terminate but only when the form is
actually displayed, not when you call app.Quit. (I had just been
single-stepping it in the debugger so I never got as far as letting the form
actually display. Curiously this behaviour happens even if you don't call
app.Quit().

I tested similar code in a vbscript program with messageboxes in it, and
this time the powerpnt.exe only terminates when the script finishes
(presumably when cscript.exe terminates).

So as usual, it's not quite as simple as it seems. I don't know what it is
that makes powerpnt.exe decide to quit but it's definitely not the Quit
function. maybe it's some kind of windows message or OLE housekeeping?

Andy

 

[Willy Denoyette [MVP]]

well thanks for the reply but it's not particularly helpful

nothing in the world will stop me running powerpoint as a server. what I
am after is the most stable way of doing it.

What you can do is to call Marshal.ReleaseComObject on all of the objects
for which you have a valid COM reference (a RCW), followed by 2 times (no
kidding) GC.Collect and WaitForPendingFinalizers.

Marshal.ReleaseComObject(app )
Marshal.ReleaseComObject(pres)
GC.Collect()
GC.WaitForPendingFinalizers()
GC.Collect()
GC.WaitForPendingFinalizers()

This works reliably in an STA thread, but might fail in an MTA, so watch out
for asp.net which by default runs in an MTA , the same goes for .NET
authored Windows Services, which have their threads running in MTA.

I have to agree with Austin, there is no reliable way to use Office
applications server side (automated from a service or asp like stuff) and
that's exactly why it's not supported.
Willy.

 

[Andy Fish]

Thanks, I've read the thread and it was very useful. It's interesting that
he doesn't mention the problem I have.

I have tested this on another PC and get exactly the same symptoms. For
vbscript and c# win forms application, powerpoint remains in memory until
the application exits. for a vb6 app with the test code in the form_Load,
powerpoint remains until the form is actually displayed. all this happens
regardless of whether you call quit or not.

I even incorporated Willy Denoyette's suggestions into my C# application but
it didn't seem to make any difference.

Now I've tested it on another PC I'm confident that my development
environment is representative of a normal powerpoint installation, so at
least I can engineer the solution and know that it stands a fighting chance
of working on a customer site.

Thanks also to Mike M for your encouraging comments about running it as a
server in a live environment.

Andy

You might want to search back a few months through this NG looking for
messages
from Howard Kaikow. He's done quite a bit of testing on this issue of
when and
how PPT is instantiated and released under automation.

<snip>

 

[Andy Fish]

Thanks Willy,

I incorporated this code into the form load event for a C# windows forms
test application but powerpoint still remained in memory until after I
closed the window (and hence exited the application).

Anyway, as I said in another post below, I am happy that the behaviour is
predictable so I will proceed with my development on this basis.

Andy

 

[Steve Rindsberg]

Good luck with it, Andy.

One other point that might prove useful - because PPT is single-instance, you
don't need to worry about inadvertently sucking up resources by firing off
multiple copies of it. If it's running already when you start an instance, you
get the running instance, not a new one.

 

[Andy Fish]

Thanks again to all who have helped.

as a final note, I now believe that powerpnt.exe is actually unloaded when
the last thread to invoke it dies (as long as there are no remaining
references to it of course)

 

[Steve Rindsberg]

Thanks again to all who have helped.

as a final note, I now believe that powerpnt.exe is actually unloaded when
the last thread to invoke it dies (as long as there are no remaining
references to it of course)

Depending on the version, mind you. In 2000, IIRC, the reference count could
get bunged and leave an orphan EXE in memory. When PPT was invoked again, PPT
being single instance would see an instance out there already and go back to
sleep. Until you killed the orphan instance, PPT wouldn't run.

You're using a later version so this shouldn't be an issue.