当上面的所有内容都不起作用时，请尝试给Excel一些时间来关闭工作表：

app.workbooks.Close();
Thread.Sleep(500); // adjust, for me it works at around 300+
app.Quit();

...
FinalReleaseComObject(app);

这里有一个非常简单的方法：

[DllImport("User32.dll")]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out int lpdwProcessId);
...

int objExcelProcessId = 0;

Excel.Application objExcel = new Excel.Application();

GetWindowThreadProcessId(new IntPtr(objExcel.Hwnd), out objExcelProcessId);

Process.GetProcessById(objExcelProcessId).Kill();

当上面的所有内容都不起作用时，请尝试给Excel一些时间来关闭工作表：

app.workbooks.Close();
Thread.Sleep(500); // adjust, for me it works at around 300+
app.Quit();

...
FinalReleaseComObject(app);

首先，在执行Excel互操作时，您永远不必调用Marshal.ReleaseComObject（…）或Marshal.FinalReleaseComObject（.）。这是一个令人困惑的反模式，但任何有关此的信息（包括来自Microsoft的信息）都是不正确的，这些信息表明您必须从.NET手动释放COM引用。事实上，.NET运行时和垃圾收集器正确地跟踪和清理COM引用。对于您的代码，这意味着您可以删除顶部的整个`while（…）循环。

其次，如果要确保在进程结束时清理进程外COM对象的COM引用（以便Excel进程关闭），则需要确保垃圾收集器运行。您可以通过调用GC.Collect（）和GC.WaitForPendingFinalizers（）来正确地执行此操作。两次调用此操作是安全的，并且可以确保周期也被彻底清理（尽管我不确定是否需要，我希望能有一个示例来说明这一点）。

第三，当在调试器下运行时，本地引用将被人为地保持活动状态，直到方法结束（以便本地变量检查工作）。因此，GC.Collect（）调用对于从同一方法中清除rng.Cells等对象无效。您应该将执行GC清理中的COM互操作的代码拆分为单独的方法。（这是我的一个关键发现，来自@nightcoder在这里发布的答案的一部分。）

因此，一般模式为：

Sub WrapperThatCleansUp()

    ' NOTE: Don't call Excel objects in here... 
    '       Debugger would keep alive until end, preventing GC cleanup

    ' Call a separate function that talks to Excel
    DoTheWork()

    ' Now let the GC clean up (twice, to clean up cycles too)
    GC.Collect()    
    GC.WaitForPendingFinalizers()
    GC.Collect()    
    GC.WaitForPendingFinalizers()

End Sub

Sub DoTheWork()
    Dim app As New Microsoft.Office.Interop.Excel.Application
    Dim book As Microsoft.Office.Interop.Excel.Workbook = app.Workbooks.Add()
    Dim worksheet As Microsoft.Office.Interop.Excel.Worksheet = book.Worksheets("Sheet1")
    app.Visible = True
    For i As Integer = 1 To 10
        worksheet.Cells.Range("A" & i).Value = "Hello"
    Next
    book.Save()
    book.Close()
    app.Quit()

    ' NOTE: No calls the Marshal.ReleaseComObject() are ever needed
End Sub

关于这个问题有很多虚假信息和困惑，包括MSDN和Stack Overflow上的许多帖子（尤其是这个问题！）。

最终说服我仔细研究并找出正确建议的是博客文章Marshal.ReleaseComObject Considered Dangerous，以及发现在调试器下引用保持活动的问题，这让我之前的测试感到困惑。

我认为其中一些只是框架处理Office应用程序的方式，但我可能错了。在某些日子，一些应用程序会立即清理进程，而在其他日子，似乎要等到应用程序关闭。总的来说，我不再关注细节，只是确保一天结束时没有任何额外的流程。

还有，也许我过于简化了，但我想你可以。。。

objExcel = new Excel.Application();
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing));
DoSomeStuff(objBook);
SaveTheBook(objBook);
objBook.Close(false, Type.Missing, Type.Missing);
objExcel.Quit();

正如我之前所说，我不太关注Excel进程出现或消失的细节，但这通常对我有用。我也不喜欢在最短的时间内保持Excel进程，但我可能只是在这方面有点偏执。

我目前正在研究Office自动化，并偶然发现了一个每次都适用于我的解决方案。它很简单，不涉及杀死任何进程。

似乎只要在当前的活动进程中循环，并以任何方式“访问”一个开放的Excel进程，Excel的任何游离挂起实例都将被删除。下面的代码只是检查名称为“Excel”的进程，然后将进程的MainWindowTitle属性写入字符串。与进程的这种“交互”似乎使Windows赶上并中止了冻结的Excel实例。

我在开发退出的加载项之前运行下面的方法，因为它会触发卸载事件。它每次都会删除所有挂起的Excel实例。老实说，我不完全确定为什么这样做，但它对我来说很好，可以放在任何Excel应用程序的末尾，而不必担心双点、Marshal.ReleaseComObject或杀死进程。我很想知道为什么这是有效的。

public static void SweepExcelProcesses()
{           
            if (Process.GetProcessesByName("EXCEL").Length != 0)
            {
                Process[] processes = Process.GetProcesses();
                foreach (Process process in processes)
                {
                    if (process.ProcessName.ToString() == "excel")
                    {                           
                        string title = process.MainWindowTitle;
                    }
                }
            }
}