当经典ASP使用时，如何终止WINWORD.EXE？

Question

I have a user who has to use Microsoft Word 2007 to create and manipulate word documents in his ASP web application. I'm well aware of the ' Considerations for server-side Automation of Office ' KB article and the many third party components available to do this kind of thing, but they've gone a fair bit down this road already.

The problem he's having is that the WINWORD.EXE process never terminates even though he calls Quit on the application object.

For example:

Set objWord = Server.CreateObject("Word.Application")
'' Do work
objWord.Quit
Set objWord = Nothing

As you would expect, his server ends up littered with orphaned WINWORD.EXE processes requiring manual intervention to terminate.

Is there a way to terminate these WINWORD.EXE processes explicitly in the script?

Update:

I've made some progress with this and I think I have a handle on what the problem is. When an Office application runs for the first time under a new Windows account it asks for your name and initials. Now because there is no visible GUI, there is no-one there to push all the right buttons. I've tried starting WINWORD.EXE as the website anonymous account identity using RUNAS , but there's some permission issue that's preventing Word or Office performing some other kind of initial setup routine it wants to do.

Answer 1

There are two things I can think of:

MyWorkBook .Saved has not been set to true. As a result the Quit call results in WinWord displaying a "Do you wish to save" dialog. On a server. Under a session with no desktop. Needless to say Word never manages to quit as it is waiting for the user.

Your user's script is not always making it to the Quit line. This is a frequent and perhaps biggest reasons against using the Office Automation, as you really need multiple layers of exception handling and finally statements (which isn't VBScript or the ASP classic engines strong point) to ensure that the instance is properly cleaned up.

Answer 2

This question is now no longer relevant. Almost all the issues were related to WINWORD.EXE requiring elevated privileges (higher than we allow for web site anonymous user accounts) to be able to perform certain tasks.

Customer has wisely decided to use ASPOSE.Words for .NET which also has a COM callable wrapper so classic ASP code can use it too.