在我的VSTO插件中新建应用程序对象后，我在关闭PowerPoint时遇到了同样的问题。我在这里尝试了所有的答案，但收效甚微。

这是我为我的案例找到的解决方案-不要使用“新应用程序”，ThisAddIn的AddInBase基类已经有了“应用程序”的句柄。如果你在需要的地方使用这个手柄（如果必须的话，让它保持静态），那么你不必担心清理它，PowerPoint也不会挂在近处。

我的回答很晚，其唯一目的是支持戈弗特提出的解决方案。

简短版本：

编写一个没有全局变量和参数的局部函数执行COM内容。在调用COM的包装函数中调用COM函数功能，然后进行清洁。

长版本：

您没有使用.Net来计算COM对象的引用数，并以正确的顺序自行释放它们。即使C++程序员也不再使用智能指针来实现这一点。所以，忘掉Marshal.ReleaseComObject和有趣的一点好两点坏规则吧。如果您对不再需要的COM对象的所有引用都为空，GC很乐意做释放COM对象的工作。最简单的方法是在一个局部函数中处理COM对象，COM对象的所有变量在最后自然地超出了范围。由于Hans Passant的精彩回答中指出了调试器的一些奇怪特性，在Post-Mortem的公认答案中提到，清理应该委托给一个包装函数，该包装函数也调用执行函数。因此，像Excel或Word这样的COM对象需要两个函数，一个执行实际任务，一个包装器调用此函数，然后像Govert那样调用GC，这是本线程中唯一正确的答案。为了说明这个原理，我使用了一个适合所有做COM的函数的包装器。除了这个扩展，我的代码只是Govert代码的C#版本。此外，我停止了该过程6秒，以便您可以在任务管理器中检查Excel在Quit（）之后不再可见，而是一直保持僵尸状态，直到GC结束它。

using Excel = Microsoft.Office.Interop.Excel;
public delegate void WrapCom();
namespace GCTestOnOffice{
  class Program{
    static void DoSomethingWithExcel(){
      Excel.Application ExcelApp = new();
      Excel.Workbook Wb = ExcelApp.Workbooks.Open(@"D:\\Sample.xlsx");
      Excel.Worksheet NewWs = Wb.Worksheets.Add();
      for (int i = 1; i < 10; i++){ NewWs.Cells[i, 1] = i;}
      Wb.Save();
      ExcelApp.Quit();
    } 

    static void TheComWrapper(WrapCom wrapCom){
      wrapCom();
      //All COM objects are out of scope, ready for the GC to gobble
      //Excel is no longer visible, but the process is still alive,
      //check out the Task-Manager in the next 6 seconds
      Thread.Sleep(6000);
      GC.Collect();
      GC.WaitForPendingFinalizers();
      GC.Collect();
      GC.WaitForPendingFinalizers();
      //Check out the Task-Manager, the Excel process is gone
    }

    static void Main(string[] args){
      TheComWrapper(DoSomethingWithExcel);
    }
  }
}

实际上，您可以干净地释放Excel应用程序对象，但您必须小心。

建议为您访问的每个COM对象维护一个命名引用，然后通过Marshal.FinalReleaseComObject（）显式释放它，这在理论上是正确的，但不幸的是，在实践中很难管理。如果有人在任何地方滑动并使用“两点”，或者通过for each循环或任何其他类似类型的命令来迭代单元格，那么您将拥有未引用的COM对象并面临挂起的风险。在这种情况下，将无法在代码中找到原因；您必须仔细检查所有代码，并希望找到原因，这对于一个大型项目来说几乎是不可能的。

好消息是，实际上不必维护对所使用的每个COM对象的命名变量引用。相反，先调用GC.Collect（），然后调用GC.WaitForPendingFinalizers（），释放所有未持有引用的对象（通常是次要的），然后显式释放持有命名变量引用的对象。

您还应该按照相反的重要性顺序释放命名引用：首先是范围对象，然后是工作表、工作簿，最后是Excel应用程序对象。

例如，假设您有一个名为xlRng的Range对象变量、一个名名为xlSheet的工作表变量、名为xlBook的工作簿变量和名为xlApp的Excel应用程序变量，则清理代码可能如下所示：

// Cleanup
GC.Collect();
GC.WaitForPendingFinalizers();

Marshal.FinalReleaseComObject(xlRng);
Marshal.FinalReleaseComObject(xlSheet);

xlBook.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.FinalReleaseComObject(xlBook);

xlApp.Quit();
Marshal.FinalReleaseComObject(xlApp);

在大多数从.NET清理COM对象的代码示例中，GC.Collect（）和GC.WaitForPendingFinalizers（）调用两次，如下所示：

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

但是，除非您使用的是Visual Studio Tools for Office（VSTO），该工具使用的终结器会导致整个对象图在终结队列中升级，否则这不应该是必需的。在下一次垃圾收集之前，不会释放此类对象。但是，如果您不使用VSTO，则应该能够调用GC.Collect（）和GC.WaitForPendingFinalizers（）一次。

我知道显式调用GC.Collect（）是一个不允许的做法（当然，重复两次听起来很痛苦），但老实说，没有办法解决这个问题。通过正常操作，您将生成隐藏对象，这些对象没有引用，因此，除了调用GC.Collect（）之外，您无法通过任何其他方式释放这些对象。

这是一个复杂的主题，但这确实是它的全部内容。一旦为清理过程建立了这个模板，您就可以正常编码，而不需要包装器等：-）

我在这里有一个教程：

用VB.Net／COM Interop实现Office程序的自动化

它是为VB.NET编写的，但不要因此而延迟，其原理与使用C#时完全相同。

普通开发人员，你的解决方案都不适合我，所以我决定实施一个新的技巧。

首先，让我们指定“我们的目标是什么？”=>“在任务管理器中完成任务后不要看到excel对象”

好的。让no挑战并开始销毁它，但考虑不要销毁并行运行的其他Excel实例。

因此，获取当前处理器的列表并获取EXCEL进程的PID，然后一旦完成任务，我们将在进程列表中创建一个具有唯一PID的新访客，找到并销毁该访客。

<请记住，在excel工作过程中，任何新的excel流程都将被检测为新的并被销毁><更好的解决方案是捕获新创建的excel对象的PID并销毁它>

Process[] prs = Process.GetProcesses();
List<int> excelPID = new List<int>();
foreach (Process p in prs)
   if (p.ProcessName == "EXCEL")
       excelPID.Add(p.Id);

.... // your job 

prs = Process.GetProcesses();
foreach (Process p in prs)
   if (p.ProcessName == "EXCEL" && !excelPID.Contains(p.Id))
       p.Kill();

这解决了我的问题，也希望你的问题。

我的解决方案

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

private void GenerateExcel()
{
    var excel = new Microsoft.Office.Interop.Excel.Application();
    int id;
    // Find the Excel Process Id (ath the end, you kill him
    GetWindowThreadProcessId(excel.Hwnd, out id);
    Process excelProcess = Process.GetProcessById(id);

try
{
    // Your code
}
finally
{
    excel.Quit();

    // Kill him !
    excelProcess.Kill();
}

我目前正在研究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;
                    }
                }
            }
}