To begin, I agree with Arthur and Ivo: don t use Word automation on the server... it s not supported and it s painful.

1. If you can, try supporting Word input/output via the DOCX format (fully documented XML format packaged using compression that s supported by the .NET Framework and supported by pre-Office 2007 with a plugin)
2. If not create a service that handles the requests in a queue to prevent multiple threads using it at the same time (ala Ivo s answer)

If you must use Word automation:

1. Make sure you are setting as many Application options as possible to prevent dialogs
   • Options.ConfirmConversions = false
   • DisplayAlerts = wdAlertsNone
   • FeatureInstall = msoFeatureInstallNone
2. Make sure you are passing in WdSaveOptions.wdDoNotSaveChanges to Document.Close
3. Have a look through this document: How To: Dismiss a Dialog Box Displayed by an Office Application with Visual Basic .NET (also applies to C#, obviously)
4. Make sure you call Marshal.ReleaseComObject on both the Document and Application objects, and make sure it s in a finally block.

The winword.exe should go away if you follow the above, you should not need to kill the process.

Edit: Not really an answer to your question, but on topic nonetheless. Keep in mind that you re also going to have problems on the server with permissions. Make sure you create a specific user for it and use that user as your AppPool identity (or service identity). You ll then need to do the following:

1. Make sure you ve installed the automation components, obviously
2. Run "dcomcnfg"
3. Component Services -> Computers -> My Computers -> COM+ Applications
4. "Microsoft Word document" (or "{000209FF-0000-0000-C000-000000000046}") -> Properties
5. Security tab -> Launch and Activation permissions -> Customize
6. Click "Edit" and add your AppPool user from above
7. Repeat steps 5-6 but select "Access Permissions"

On top of all that, you still might need to run winword.exe once as your AppPool user directly from the server, despite the dialog options above, to initially setup the profile.

Office apps do not "destroy" the first instance created. You will find the same issue when using excel.

See this and others

50 Ways to Kill Excel

How to kill a process given a name

Look into System.Diagnostics.Process.GetProcessesByName and System.Diagnostics.Process.Kill

Try something like

string processName = "ProcessName";
Process[] processes = Process.GetProcessesByName(processName);

foreach(Process process in processes)
{
    process.Kill();
}

You should be able to grab each process of word and kill it:

foreach(Process p in System.Diagnostics.Process.GetProcessesByName("winword"))
 {
   p.kill();
   p.WaitForExit();
 }

Also you should try seeing the document object to null?

Most safe approach for using (Microsoft) Office on the server is to create a service that can accept streams and creates an instance of Word (or any other Office app) do it s thing and then kills the app. If you do not do this a reference to the running office app will remain within your asp worker process. This means that a lot of processes will keep running until your asp worker process is recycled. This is a large potential memory leak.

This is how we did it. Costs a lot of time to build this correctly but is the most safe way.

This was driving me crazy until I found this post on this site. The second solution on that page worked for me - the first one looks simpler, but it actually can get difficult to keep track of all the hidden COM objects you have a reference to. The second method always works - you don t have to track every object.

Just to be said: Office Applications are not supposed to run on a server. They are also not to supposed to be uses from a Service or WebApplication.

Yes - we also had requirements that forced us to use Office Products at the Server. And we always hat troubles.

If there is a chance not to use Office (dealing with WordML, the new Office XML format) then do that.