"How do I kill Excel" is a very common question asked in development forums and answered hundreds of times. Web developers often ask about dozens of Excel.exe processes stacking up in Task Manager. A google search for "kill excel" yields nearly 5,000,000 hits. Oddly the question is also answered in several different ways—each guru mentioning his or her pet solution to the problem. In this article, we won't see 50 ways, but we'll investigate various possibilities. We'll politely ask Excel to quit, we'll close and de-reference COM interfaces, manage garbage collection (GC), and ultimately grab a process that just refuses to go -- and kill it.
The most complex situation is undoubtedly in ASP.NET where the server process is running Excel in one of many security scenarios (ASPNET user, IUser, impersonated end user, etc.); and without a desktop user session. Hence we'll use this as our illustration to cover all bases. But keep in mind that you may need to simplify the solutions to your particular needs. For example, you may wish to kill all running instances of Excel, which is a far simpler problem than targeting a particular process.
If you're already knee-deep in this problem, and only interested in force-killing Excel, then skip to page 4 now.
For the interested student this article will explore several important Windows concepts that apply well beyond the Excel application:
COM interop/config./management, the .NET Process class, and how to use “PInvoke” to call Windows API methods not implemented in the .NET Frameworks.
There are certainly many thorny patches to walk through when involving Office automation in any of your applications (Fig. 1). This article really only attempts to address one of them, namely how to close the Office app from your calling app.
Figure 1: Note to self ... Office doesn't work
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when run in this environment.
Besides the technical problems, you must also consider the feasibility of such a design with respect to licensing. Current licensing guidelines prevent Office Applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
-- taken from http://support.microsoft.com/kb/257757