Почему после работы с Excel из C# остаётся EXCEL.EXE — освобождение COM-ссылок и решение о замене

«Сделали выгрузку отчётов в Excel — и в диспетчере задач выстроилась очередь процессов EXCEL.EXE». «Приложение закрыли, а при следующей попытке открыть файл система сообщает, что он занят другим процессом». «На сервере ночного пакетного задания накопилось несколько сотен процессов Excel, они съели всю память, и всё встало». Почти каждый, кто писал на C# код, управляющий Excel через Microsoft.Office.Interop.Excel, хотя бы раз с этим сталкивался. К нам тоже регулярно приходят с жалобой: «вызываю Quit(), а Excel не завершается».

Неприятность в том, что проблема выглядит так, будто возникает лишь иногда. На машине разработчика процесс исчезает, в продакшене остаётся; под отладчиком остаётся, в релизной сборке исчезает. Из-за плавающих условий воспроизведения в рабочий код то и дело просачивается симптоматический Process.Kill. Но дело не в везении: причину полностью объясняют счётчик ссылок COM и устройство RCW (Runtime Callable Wrapper) в .NET. В статье с практической стороны разберём, почему процесс остаётся, классическую ловушку «правила двух точек», два подхода к освобождению и нашу рекомендацию, как правильно завершать процесс как крайнюю меру и когда стоит уйти на библиотеки семейства Open XML.

1. Короткий вывод

Если в одну фразу: Quit() — это не освобождение, и EXCEL.EXE не завершится, пока RCW не вернёт все удерживаемые COM-ссылки. Ниже — из чего это складывается и что с этим делать.

• EXCEL.EXE остаётся не из-за бага, а потому что сторона .NET всё ещё удерживает COM-ссылку. Quit() — лишь запрос «завершиться, когда все ссылки будут освобождены»; пока ссылка есть, Excel исправно ждёт.
• .NET работает с COM-объектами через обёртку RCW (Runtime Callable Wrapper) и продолжает удерживать ссылку на COM-объект, пока сам RCW не будет собран GC (или явно освобождён).¹
• Если поставить две и более точки подряд, как в book.Worksheets[1].Range["A1"], RCW промежуточных объектов создаются, не попадая ни в одну переменную, и их уже нельзя освободить. Это и есть «правило двух точек» — главная причина проблемы.
• Есть два подхода к освобождению. (a) дисциплинированно вызывать Marshal.ReleaseComObject для каждого COM-объекта и (b) держать ссылки в локальных переменных и отдавать их GC (GC.Collect + WaitForPendingFinalizers). Официальная документация относит ReleaseComObject к средствам, которые следует «использовать только когда это абсолютно необходимо».²
• Наша рекомендация — по умолчанию брать GC-паттерн с изоляцией работы в одном методе, а небольшую using-обёртку, которая дисциплинирует освобождение, вводить только когда действительно нужен контроль порядка (раздел 4).
• Как страховку на случай, если процесс всё же не завершится, используйте дескриптор окна из Application.Hwnd, PID через GetWindowThreadProcessId и принудительное завершение именно этого процесса. Не ищите «свой» Excel по разнице списков процессов до и после запуска: так легко задеть книгу, которую открыл пользователь.³⁴
• И важнее приёмов: Microsoft не поддерживает автоматизацию Office на сервере и в средах без участия пользователя.⁵ Для формирования отчётов без участия пользователя сначала рассмотрите переход на Open XML SDK / ClosedXML, которые Excel вообще не запускают (разделы 6–7).⁶⁷

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 24, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему остаётся EXCEL.EXE — счётчик ссылок и RCW

Сначала принцип на стороне COM. Время жизни COM-объекта задаёт счётчик ссылок, и сервер автоматизации Excel (EXCEL.EXE) не завершается, пока не вернутся все ссылки, выданные внешним клиентам. Ещё во времена VB6 забытый вызов Release точно так же оставлял процесс (повторение COM — в статье «Что такое COM / ActiveX / OCX»).

Теперь сторона .NET. Код на C# не трогает COM-объект напрямую: CLR подставляет прокси RCW. На каждый COM-объект внутри процесса создаётся ровно один RCW; он кэширует указатель на COM-интерфейс и освобождает ссылку на COM-объект, когда сам собирается GC.¹ То есть управление временем жизни смещается с «считать ссылки самому» на «положиться на GC».

Сложите эти два факта — и причина, по которой остаётся EXCEL.EXE, следует сразу. Цепочку ссылок удобно видеть на схеме.

flowchart LR
    subgraph NET["Внутри процесса .NET"]
        V["Переменные<br/>excel / book / sheet"]
        A["Анонимные промежуточные объекты<br/>возвращаемые значения вроде book.Worksheets<br/>без переменной вручную не освободить (раздел 3)"]
        R["RCW<br/>один на каждый COM-объект<br/>отдаёт COM-ссылку, когда его собирает GC"]
    end
    subgraph EXE["Внутри EXCEL.EXE"]
        CNT["Счётчик ссылок COM<br/>не уменьшается, пока не вернутся все выданные наружу ссылки"]
        PROC["EXCEL.EXE не завершается"]
    end
    REL["Marshal.ReleaseComObject<br/>или сборка через GC (раздел 4)"]
    QUIT["excel.Quit()<br/>только сообщает, что можно завершиться<br/>ни одна ссылка при этом не освобождается"]

    V --> R
    A --> R
    R -->|"продолжает удерживать COM-ссылку"| CNT
    CNT --> PROC
    REL -.->|"срабатывает здесь"| R
    QUIT -.->|"действует сюда, но не освобождает"| PROC

Идёт ли ссылка от «переменной» слева или от «анонимного промежуточного объекта», правый край не завершится, пока RCW держит COM-ссылку. Из двух нижних стрелок работает только та, что идёт от REL к R. По шагам это выглядит так.

Важны два момента. Во-первых, Quit() — это не освобождение. Пока ссылка есть, Excel ждёт. Если процесс-хост полностью завершается, ссылка обрывается, и Excel обычно уходит вместе с ним. Но в постоянно работающем приложении или в веб-приложении родительский процесс живёт дальше, и это «когда-нибудь» не наступает. Во-вторых, момент освобождения не определён: он зависит от GC. Если памяти достаточно, GC может не запускаться десятки минут, и всё это время EXCEL.EXE остаётся зомби. «Иногда остаётся», «остаётся только в продакшене» — это не отдельная магия, а видимые колебания момента, когда срабатывает GC.

Отдельно: Excel, запущенный с Visible = false, окна не показывает, поэтому оставшийся экземпляр пользователь не видит. Типичные симптомы — «ошибка „файл занят“ при повторном сохранении» или «компьютер тормозит»; очередь EXCEL.EXE замечают, только открыв диспетчер задач. Первый шаг расследования — посчитать процессы командой tasklist | findstr EXCEL.

3. Классическая ловушка «правило двух точек» — невидимые промежуточные объекты

В коде за жалобой «я аккуратно освобождаю все переменные, а процесс всё равно остаётся» почти всегда есть такая строка.

// На первый взгляд аккуратно, но здесь рождаются RCW, которые нельзя освободить
excel.Workbooks.Open(path);
book.Worksheets[1].Range["A1"].Value2 = "hello";

excel.Workbooks создаёт и возвращает RCW коллекции Workbooks. Если вызвать .Open(...), не сохранив это значение в переменную, RCW для Workbooks остаётся в куче как анонимный объект: на него никто не ссылается, но он ещё жив. Переменной нет, поэтому вызвать Marshal.ReleaseComObject тоже нельзя. Вторая строка тяжелее: за одну строку она создаёт три анонимных RCW — Worksheets (коллекция), Worksheets[1] (лист) и Range["A1"] (диапазон).

Эмпирическое правило, которым в сообществе автоматизации Office пользуются давно, — «правило двух точек». Иначе: на COM-объекте не ставьте две и более точки подряд; каждый промежуточный объект сначала кладите в переменную.

// Даём имя каждому промежуточному объекту
Excel.Workbooks books = excel.Workbooks;
Excel.Workbook book = books.Open(path);
Excel.Sheets sheets = book.Worksheets;
Excel.Worksheet sheet = (Excel.Worksheet)sheets[1];
Excel.Range cell = sheet.Range["A1"];
cell.Value2 = "hello";

Выглядит многословно, но смысл в том, чтобы всё, что нужно освободить, можно было перечислить. Легко упустить и такие варианты того же паттерна.

• foreach: foreach (Excel.Worksheet s in book.Worksheets) создаёт RCW и для коллекции, и для перечислителя, и для каждого элемента. В подходе с ReleaseComObject обычный приём — индексированный цикл for, в котором каждый элемент кладут в переменную по одному.
• Отброшенное значение внутри условия: RCW появляется даже внутри выражения вроде if (excel.Workbooks.Count > 0).
• Составное выражение в аргументе: sheets.Add(After: sheets[sheets.Count]) за одну строку создаёт несколько анонимных RCW.
• Подписка на события: обработчик события Application или Workbook удерживает ссылку через это соединение. Перед завершением обязательно отписывайтесь.

Напоследок про источник названия. Само имя «правило двух точек» — из сообщества, это не официальный термин Microsoft. Содержание правила при этом опирается на первичные источники. В статье поддержки Microsoft про Office-приложение, которое не завершается после автоматизации, первым условием завершения названо «объявлять каждый объект новой переменной»: не писать цепочкой oExcel.Workbooks.Add(), а один раз вставить oBooks = oExcel.Workbooks.⁸ Если рядом положить факт, что «на каждый COM-объект создаётся один RCW и ссылка освобождается, когда его собирает GC»¹, почему протекают промежуточные объекты, видно уже по первичным документам. Тот же документ для случая «освободили, а процесс всё равно жив» упоминает вызовы GC.Collect и GC.WaitForPendingFinalizers.⁸ Два подхода из следующего раздела оба лежат на продолжении этой статьи.

4. Два подхода к освобождению — ReleaseComObject и GC

Код, который надёжно завершает EXCEL.EXE, пишут двумя способами. Оба работают, если написаны правильно. Практический вопрос — удастся ли писать их правильно и дальше; здесь и появляется разница.

4.1 (a) Дисциплинированно вызывать Marshal.ReleaseComObject

Marshal.ReleaseComObject уменьшает внутренний счётчик ссылок RCW и в момент нуля сразу освобождает COM-ссылку, которую RCW держал.² Плюс в том, что момент детерминирован: GC ждать не нужно.

Код получается длинным, поэтому сначала скелет. Делать нужно одно: «все использованные объекты положить в переменные и освободить в порядке, обратном созданию». Но сами Close и Quit — тоже COM-вызовы и могут завершиться ошибкой. Значит, даже если посередине вылетит исключение, до последующего освобождения всё равно нужно дойти: вкладывайте try/finally.

try
    Application → Workbooks → Workbook → Sheets → Worksheet → Range  ← порядок создания
finally
    освободить Range, Worksheet, Sheets                            ← обратный порядок
    try   book.Close()
    finally
        освободить Workbook, Workbooks
        try   excel.Quit()
        finally
            освободить Application

В C# это выглядит так. Длинно — потому что вложенность и проверки на null нигде не сокращены.

using Excel = Microsoft.Office.Interop.Excel;
using System.Runtime.InteropServices;

Excel.Application excel = null;
Excel.Workbooks books = null;
Excel.Workbook book = null;
Excel.Sheets sheets = null;
Excel.Worksheet sheet = null;
Excel.Range cell = null;
try
{
    // Не используйте инициализатор объекта (new ... { DisplayAlerts = false }).
    // Если COM-вызов сеттера завершится ошибкой, excel останется не присвоенным
    // к моменту входа в finally, и для уже запущенного EXCEL.EXE нельзя будет
    // ни вызвать Quit, ни освободить ссылку
    excel = new Excel.Application();
    excel.DisplayAlerts = false;
    books = excel.Workbooks;
    book = books.Open(templatePath);
    sheets = book.Worksheets;
    sheet = (Excel.Worksheet)sheets[1];
    cell = sheet.Range["A1"];
    cell.Value2 = "hello";
    book.SaveAs(outputPath);
}
finally
{
    // Освобождаем в порядке, обратном созданию. Сами Close и Quit — тоже COM-вызовы
    // и могут завершиться ошибкой, поэтому вкладываем try/finally: даже если
    // посередине вылетит исключение, до Quit и освобождения всё равно дойдём
    if (cell   != null) Marshal.ReleaseComObject(cell);
    if (sheet  != null) Marshal.ReleaseComObject(sheet);
    if (sheets != null) Marshal.ReleaseComObject(sheets);
    try
    {
        if (book != null) book.Close(SaveChanges: false);
    }
    finally
    {
        if (book  != null) Marshal.ReleaseComObject(book);
        if (books != null) Marshal.ReleaseComObject(books);
        try
        {
            if (excel != null) excel.Quit();
        }
        finally
        {
            if (excel != null) Marshal.ReleaseComObject(excel);
        }
    }
}

Слабость этого способа, как видно, в том, что дисциплина обходится дорого. Каждый затронутый COM-объект без исключения нужно положить в переменную и освободить в обратном порядке, включая пути с исключениями. А если учесть, что сам Close или Quit может завершиться ошибкой (ошибка COM, уже отключённая книга, не отвечающий Excel), приходится гарантировать — как во вложенных try/finally выше — что сбой посередине всё равно доводит выполнение до последующих освобождений. По опыту требовать этого от всей команды при каждой правке очень трудно. Стоит одной составной строке с двумя точками проскользнуть в код — и утечка возвращается.

Ещё важнее: сама официальная документация предупреждает от злоупотребления. В справке по Marshal.ReleaseComObject прямо сказано, что это средство для случаев, когда ресурс нужно освободить вовремя или когда важен порядок, и что «использовать ReleaseComObject следует только тогда, когда это абсолютно необходимо (use the ReleaseComObject only if it is absolutely required)».² RCW в процессе один на COM-объект и разделяется: если код в одном месте освободил RCW, которым в другом месте ещё пользуются, получается InvalidComObjectException или, в худшем случае, нарушение доступа и порча памяти процесса.² В приложении, где с Excel работают несколько модулей, такой инцидент вполне реален.

Ещё деталь: если один и тот же указатель интерфейса многократно попадает в CLR, внутренний счётчик RCW может стать больше 1, и одного вызова недостаточно. Есть Marshal.FinalReleaseComObject, который принудительно обнуляет счётчик,² но сам факт, что этот API понадобился, — знак, что время жизни уже не контролируется; мы в таком случае советуем пересмотреть устройство кода.

Отдельное замечание по безопасности, не про оставшийся процесс. Книга, открытая через Workbooks.Open в COM-автоматизации, может выполнить VBA без предупреждения о макросах. Пример в статье предполагает доверенный шаблон, которым управляет само приложение. Но если есть шанс открыть книгу извне — файл из общей папки, файл, который загрузил пользователь, — перед Open задайте excel.AutomationSecurity = MsoAutomationSecurity.msoAutomationSecurityForceDisable (пространство имён Microsoft.Office.Core), чтобы макросы были принудительно выключены.⁹ Так закрывается атака, в которой подмена шаблона сразу становится выполнением произвольного кода. То же замечание относится и к примеру с GC ниже.

4.2 (b) Держать ссылки внутри метода и отдать их GC

Второй способ — оставить освобождение RCW сборщику мусора, как и задумано, и запустить этот GC в определённый момент. RCW освобождает COM-ссылку, когда его собирает GC,¹ поэтому можно завершить EXCEL.EXE, ни разу не вызвав ReleaseComObject: «после того как все ссылки, которые трогали Excel, вышли из области видимости, выполнить полную сборку и дождаться финализаторов».

using System.Runtime.CompilerServices;
using Excel = Microsoft.Office.Interop.Excel;

public void ExportReport(string templatePath, string outputPath)
{
    try
    {
        // Всю работу с Excel полностью изолируем в отдельном методе
        ExportReportCore(templatePath, outputPath);
    }
    finally
    {
        // Именно на пути исключения EXCEL.EXE чаще всего остаётся,
        // поэтому это обязательно выполняется в finally.
        // После выхода из метода ссылок на RCW уже нигде нет
        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();   // Второй проход: собираем RCW, которые отсоединил финализатор
    }
}

[MethodImpl(MethodImplOptions.NoInlining)]
private void ExportReportCore(string templatePath, string outputPath)
{
    var excel = new Excel.Application();
    try
    {
        excel.DisplayAlerts = false;
        Excel.Workbooks books = excel.Workbooks;
        Excel.Workbook book = books.Open(templatePath);
        Excel.Sheets sheets = book.Worksheets;
        Excel.Worksheet sheet = (Excel.Worksheet)sheets[1];
        Excel.Range cell = sheet.Range["A1"];
        cell.Value2 = "hello";
        book.SaveAs(outputPath);
        book.Close(SaveChanges: false);
    }
    finally
    {
        excel.Quit();
    }
}

Нужны три условия.

1. Код, который трогает Excel, изолировать в одном методе. Пока JIT держит ссылку живой на стеке, GC не может её собрать, поэтому GC вызывают строго снаружи метода, работавшего с Excel. NoInlining нужен, чтобы встраивание не уничтожило эту изоляцию.
2. Не выпускать RCW в поле или возвращаемое значение. Стоит одному уйти за пределы метода — Excel останется, пока жива эта ссылка.
3. Связка из трёх шагов: GC.Collect → GC.WaitForPendingFinalizers → GC.Collect. Зачистка RCW идёт через финализатор, поэтому обычный приём — два круга: первый Collect находит объект, затем ждём завершения финализатора, второй Collect подбирает остатки.

Нюанс: при подключённом отладчике время жизни переменной продлевается до конца метода, и даже этот способ может не собрать RCW. В этом и есть природа явления «под отладчиком остаётся, в релизе исчезает». Проверяйте поведение на релизной сборке без отладчика.

Плюс этого способа: нарушение правила двух точек не даёт утечку. Всё, чья ссылка оборвалась, включая анонимные промежуточные RCW, GC собирает разом. На ревью остаётся один вопрос — «закрыта ли работа с Excel внутри этого метода», — и стоимость дисциплины резко падает. Минусы — запах кода от явного GC.Collect (пауза полной сборки по всему приложению) и риск, что коллега, не зная причины, сломает это благим рефакторингом. У связки из трёх вызовов обязательно оставляйте комментарий, зачем она нужна.

4.3 Наша рекомендация — изоляция и GC по умолчанию, обёртка при необходимости

Сравним оба подхода практически.

Наша рекомендация — по умолчанию брать паттерн (b): изоляция плюс GC. Выгрузка отчётов естественно закрывается в одном методе; стоит придать ей такую форму — и утечки структурно перестают возникать. Риск злоупотребления ReleaseComObject тоже уходит, и это совпадает с тем, как метод позиционирует документация.

Подход (a) применяйте только когда порядок и немедленность освобождения действительно нужны. В этом случае сырые вызовы ReleaseComObject писать не давайте: введите небольшую using-обёртку, которая дисциплинирует освобождение.

using System.Runtime.InteropServices;

/// <summary>Обёртка, которая освобождает COM-объект при выходе из using</summary>
public readonly struct ComScope<T> : IDisposable where T : class
{
    public T Value { get; }
    public ComScope(T value) => Value = value;

    public void Dispose()
    {
        if (Value is not null && Marshal.IsComObject(Value))
            Marshal.ReleaseComObject(Value);
    }
}

using var books = new ComScope<Excel.Workbooks>(excel.Workbooks);
using var book  = new ComScope<Excel.Workbook>(books.Value.Open(templatePath));
using var sheets = new ComScope<Excel.Sheets>(book.Value.Worksheets);
using var sheet = new ComScope<Excel.Worksheet>((Excel.Worksheet)sheets.Value[1]);
using var cell  = new ComScope<Excel.Range>(sheet.Value.Range["A1"]);
cell.Value.Value2 = "hello";
book.Value.SaveAs(outputPath);
book.Value.Close(SaveChanges: false);

Dispose выполняется в порядке, обратном объявлениям using, поэтому «освобождение в порядке, обратном созданию» обеспечивает сам язык. Записей чуть больше из-за .Value, зато дисциплина сжимается до одного правила: «каждый COM-объект получать через ComScope». С другой стороны, составное выражение вроде books.Value.Open(...).Worksheets снова даёт утечку — так что правило двух точек всё равно нужно объяснять.

Две общие предосторожности для обоих паттернов. Во-первых, перед Quit() не давайте появиться диалогу подтверждения сохранения. Явно задавайте DisplayAlerts = false и вызывайте Close(SaveChanges: false). Если скрытый Excel завис в ожидании диалога, сам Quit() не завершится. Во-вторых, COM в Excel рассчитан на STA, поэтому не передавайте один и тот же Application между несколькими потоками. Связь потоков и апартаментов COM разобрана в статье «Основы STA/MTA в COM».

4.4 Как убедиться, что процесс действительно исчез

Когда паттерн освобождения уже в коде, заранее зафиксируйте и процедуру проверки «правда ли он исчез». У этой проблемы плавают условия воспроизведения: без фиксированной процедуры легко принять за успех «один раз случайно пропал».

1. Запускайте релизную сборку без отладчика. Как в разделе 4.2, при подключённом отладчике время жизни переменной тянется до конца метода, и даже правильно написанный GC-паттерн RCW не соберёт. В Visual Studio это «Запуск без отладки».
2. До старта посчитайте, сколько уже есть EXCEL.EXE. Выполните tasklist /FI "IMAGENAME eq EXCEL.EXE" и запишите число, включая Excel, который пользователь открыл руками. В PowerShell достаточно @(Get-Process EXCEL -ErrorAction SilentlyContinue).Count.
3. Прогоните ту же операцию подряд не меньше 10 раз. Одного запуска мало: в зависимости от момента GC процесс может исчезнуть случайно.
4. Подождите несколько секунд после окончания и посчитайте снова. Если число вернулось к шагу 2 — успех. Если выросло, прирост и есть число утечек.
5. Тот же прогон сделайте на пути исключения. Подставьте несуществующий путь шаблона, сделайте каталог сохранения только для чтения — намеренно сломайте сценарий посередине и убедитесь, что число всё равно возвращается. Большинство аварий с оставшимся EXCEL.EXE случается не на успешном пути, а на исключении; пропустить этот шаг значит не проверить ничего.
6. Для постоянно работающего приложения считайте, не закрывая само приложение. Когда процесс приложения завершается, ссылки обрываются и Excel тоже падает; посчитать после закрытия приложения — ничего не проверить (раздел 2).

Числа из шагов 2 и 4 стоит писать в лог: так заметите регрессию в коде освобождения. Если уже стоит страховка Kill из раздела 5, «освобождение работает» можно сказать только после того, как Kill не срабатывал (нет предупреждающего лога о срабатывании).

5. Крайняя мера — надёжно завершить процесс, определив PID по Hwnd

Даже при корректно реализованном паттерне освобождения остаются случаи вроде «Excel не завершается из-за надстройки» или «на аварийном пути с исключением иногда остаётся один процесс». В пакетном задании без участия пользователя один оставшийся процесс на следующий день блокирует файл, поэтому принудительное завершение как последнюю страховку имеет смысл заложить. Вопрос — как понять, какой именно EXCEL.EXE завершать.

Частая ошибка — искать его по разнице списков процессов до и после запуска: сравнить Process.GetProcessesByName("EXCEL") до и после и считать своим то, что появилось. Это ломается при параллелизме. Если пользователь вручную откроет Excel в момент снятия разницы, будет ложное срабатывание; если такие же задания идут параллельно, они перепутают процессы друг друга. Худший сценарий — завершить несохранённый Excel, который пользователь как раз редактирует, и уничтожить его данные. Такой случай к нам уже приносили как обращение.

Правильный способ — взять дескриптор окна верхнего уровня через свойство Hwnd объекта Application, который запустили вы, и через Win32 API GetWindowThreadProcessId получить ID процесса, создавшего это окно.³⁴ Дескриптор уникален для вашего экземпляра, перепутать его с другим Excel нельзя.

using System.Diagnostics;
using System.Runtime.InteropServices;
using Excel = Microsoft.Office.Interop.Excel;

internal static class NativeMethods
{
    [DllImport("user32.dll")]
    internal static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint processId);
}

public void ExportReport(string templatePath, string outputPath)
{
    // out-параметр оставляет дескриптор у вызывающего кода даже тогда,
    // когда исключение вылетело посреди работы с Excel, поэтому GC и Kill
    // гарантированно выполняются и на пути исключения (там эта страховка и нужна)
    Process excelProcess = null;
    try
    {
        ExportReportCore(templatePath, outputPath, out excelProcess);
    }
    finally
    {
        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
        if (excelProcess != null)
        {
            KillIfStillAlive(excelProcess);   // Если процесс уже завершился штатно, страховка ничего не делает
            excelProcess.Dispose();
        }
    }
}

[MethodImpl(MethodImplOptions.NoInlining)]
private void ExportReportCore(string templatePath, string outputPath, out Process excelProcess)
{
    excelProcess = null;
    var excel = new Excel.Application();
    // Сразу после успешного запуска оборачиваем в try/finally, чтобы даже при
    // сбое получения Hwnd или открытия дескриптора всё равно дойти до Quit()
    try
    {
        // Берём сразу после запуска: после Quit() окно уничтожается
        // и получить его уже нельзя. GetProcessById только сопоставляет PID;
        // дескриптор процесса ОС открывается лениво при первом обращении —
        // например через WaitForExit / Kill. Поэтому здесь, пока Excel ещё жив,
        // трогаем SafeHandle и принудительно открываем дескриптор
        // (пока дескриптор открыт, этот PID другому процессу не отдадут)
        NativeMethods.GetWindowThreadProcessId((IntPtr)excel.Hwnd, out uint pid);
        excelProcess = Process.GetProcessById((int)pid);
        _ = excelProcess.SafeHandle;

        excel.DisplayAlerts = false;
        // …… операции с Excel ……
    }
    finally
    {
        excel.Quit();
    }
}

private void KillIfStillAlive(Process excelProcess)
{
    if (!excelProcess.WaitForExit(5000))   // В норме исчезает за несколько секунд
    {
        logger.LogWarning("EXCEL.EXE (PID {Pid}) не завершился, принудительно останавливаем", excelProcess.Id);
        excelProcess.Kill();
    }
}

Замечания по реализации.

• Hwnd снимайте сразу после запуска. После Quit() окно уничтожается, получить его уже нельзя. Application.Hwnd доступен и при Visible = false.³
• Kill — страховка поверх уже сделанного освобождения, а не замена ему. Если полагаться на него с самого начала, Excel не чистит временные файлы, и к следующему запуску копятся файлы автовосстановления. Порядок всегда такой: «освобождение → Quit → ожидание → Kill только если процесс всё ещё жив».
• Учитывайте повторное использование PID. PID в Windows переиспользуются. Если запомнить только число и разрешить его позже, Excel за это время может завершиться, тот же PID отдадут другому процессу — и вы завершите посторонний процесс. Одного Process.GetProcessById недостаточно: дескриптор процесса ОС открывается лениво при первом обращении, например через WaitForExit / Kill. Только тронув SafeHandle, пока Excel ещё жив, и тем самым явно открыв дескриптор заранее, как в коде выше, можно избежать путаницы (пока дескриптор открыт, этот PID не отдадут другому).
• Эта страховка покрывает случай, когда метод уже вернул управление, а EXCEL.EXE всё ещё жив. Если зависает сам COM-вызов — Workbooks.Open, SaveAs, Quit ждут скрытого модального диалога или не отвечающей надстройки, — до finally выполнение не доходит, и этот Kill тоже не сработает. Меры лучше думать в два слоя. Сначала закрыть источники диалогов через DisplayAlerts = false и уже упомянутый AutomationSecurity. Сверх этого в пакетном задании без участия пользователя вынесите работу с Excel в отдельный процесс, чтобы его можно было целиком завершить снаружи по таймеру — настройкой планировщика заданий «время до остановки» или завершением дочернего процесса из родителя. Таймаут внутри процесса зависший COM-вызов не прервёт, поэтому границу надёжнее ставить на процесс.
• Когда Kill сработал, обязательно пишите это в лог и смотрите частоту. Рост частоты — сигнал либо регрессии в коде освобождения, либо повод пересмотреть решение из раздела 7.

6. Если шире: серверная автоматизация Office не поддерживается

Приёмы выше почти закрывают оставшийся EXCEL.EXE в клиентском приложении. Но в сценарии, где проблема проявляется сильнее всего — автоматизация Excel на сервере или в среде без участия пользователя, — до приёмов стоит свериться с официальной позицией.

В документе «Considerations for server-side Automation of Office» Microsoft прямо пишет, что не рекомендует и не поддерживает автоматизацию Office из неинтерактивных клиентских приложений и компонентов без участия пользователя (включая ASP, ASP.NET, DCOM и службы NT).⁵ Office рассчитан на интерактивного пользователя. Предпосылки, которые на рабочем столе не мешают — диалог подтверждения при ошибке и ожидание ответа, компоненты, завязанные на профиль выполняющего пользователя, архитектура на STA без повторного входа, — в службе или в рабочем процессе IIS оборачиваются против вас.¹⁰ Обращения вроде «из службы Windows в продакшене Open не возвращает управление» или «раз в месяц на IIS зависает в ожидании диалога» сводились именно к этой неподдерживаемой конфигурации. Оставшийся EXCEL.EXE здесь уже не про зачистку, а про эксплуатацию: зависшие процессы накапливаются без конца.

Как альтернативы Microsoft называет редактирование файла напрямую в формате Open XML, без установки и запуска Office, и Microsoft Graph API, который обрабатывает данные в облаке.¹⁰ Open XML SDK — библиотека Microsoft, которая читает и пишет файловые форматы Office (например, .xlsx), стандартизированные как ECMA-376 / ISO/IEC 29500, через строго типизированные классы; она построена поверх ZIP и XML, поэтому сам Excel не нужен.⁶ Проблемы оставшихся процессов, лицензий и неподдерживаемой конфигурации уходят разом.

Но Open XML SDK — библиотека, которая «редактирует файловый формат напрямую», и поведения самого приложения Excel она не даёт. В официальных проектных соображениях прямо сказано: пересчёт формул, обновление данных и конвертацию в другие форматы (например, PDF) SDK не предоставляет.¹¹ API к тому же верен структуре формата, поэтому даже запись одной ячейки через «голый» SDK требует понимания SpreadsheetML. Этот пробел закрывает ClosedXML — OSS-библиотека с лицензией MIT, которая над Open XML API надстраивает привычный интерфейс «книга, лист, ячейка». Она работает с .xlsx / .xlsm без установленного Excel (старый .xls не поддерживается).⁷ Как выбирать между этими подходами для отчётов и как проектировать шаблонный способ, подробно написано в статье «Как построить вывод отчётов Excel».

Отметим, что в Microsoft 365 есть лицензия для RPA без участия пользователя (unattended license), но она делает такое выполнение возможным лишь с точки зрения лицензии. Поведение по-прежнему «как есть» (AS IS): неожиданности от использования вне проектных предпосылок должно поглощать само приложение.¹⁰ Частая ошибка: «купили лицензию — значит, конфигурация стала поддерживаемой». Это не так.

7. Таблица решений: оставаться на COM или переходить на Open XML

С учётом сказанного вопрос «продолжать управлять Excel через COM или уходить» сводится к трём вариантам.

Ось решения — четыре вопроса.

1. Нужно ли взаимодействовать с Excel, который стоит перед пользователем? Функцию «записать в открытую пользователем книгу и отдать управление обратно» можно сделать только через COM Interop. Тогда вариант (1) безальтернативен — вкладывайтесь в дисциплину из раздела 4. Интерактивное настольное приложение под неподдерживаемую конфигурацию тоже не попадает.
2. Нужны ли возможности самого приложения Excel — макросы, пересчёт, печать, вывод в PDF? Семейство Open XML это не заменяет.¹¹ Сочетание таких требований с выполнением без участия пользователя — самый тяжёлый случай, поэтому сначала посмотрите, нельзя ли сдвинуть сами требования (перенести логику макроса на C#, записывать уже посчитанные значения и т. п.). Отдельно проверьте «сохранение» шаблона с макросами (.xlsm). При низкоуровневых операциях Open XML SDK VBA-проект сохраняется, пока вы не трогаете соответствующую часть пакета. Высокоуровневая библиотека вроде ClosedXML загружает книгу в объектную модель и пересобирает пакет при сохранении, поэтому VBA-проект может пропасть. Если переносите шаблон с макросами на семейство Open XML, обязательно проверьте на реальном шаблоне, что «после открытия, записи и сохранения макрос остаётся и работает». Если гарантировать это нельзя — оставьте именно этот отчёт на COM. Для работы с активами VBA применима логика из статьи «Что такое VBA».
3. Это выполнение без участия пользователя? Если запуск идёт из службы, планировщика заданий или веб-приложения, ответ по умолчанию — (2). Большая часть требований к отчётам сводится к «сделать .xlsx со значениями и стилями», и это полностью закрывается ClosedXML.
4. Какой формат входа и выхода? Если нужно как есть обрабатывать .xls от контрагентов, семейство Open XML не подойдёт. Посмотрите, нельзя ли на входе вставить конвертацию в .xlsx.

То, что мы часто предлагаем в реальных проектах, — разделение: «формирование — через ClosedXML, а работу, для которой нужен сам Excel, изолировать в COM». Ежедневные сотни отчётов считаются на сервере через ClosedXML, а COM — например, ежемесячное «обновление книги с макросами» — оставляют для запуска по кнопке на рабочем столе ответственного сотрудника. Тогда COM исчезает из среды без участия пользователя, а оставшаяся COM-часть оказывается интерактивным приложением и укладывается в поддерживаемую конфигурацию. Это реалистичнее полной переработки и позволяет убирать риск начиная с самой опасной части.

8. На что обратить внимание в эпоху .NET (Core)

Ниже — в пределах того, что удалось проверить, — замечания для приложения, которое перешло с .NET Framework на .NET (.NET 6/8 и т. д.) и продолжает работать с Excel через COM.

• COM-взаимодействие по-прежнему только для Windows. .NET работает и в Linux, но встроенная поддержка COM ограничена Windows.¹² Для проекта с операциями над Excel явно указывайте целевую платформу вроде net8.0-windows и не рассчитывайте на кроссплатформенность. То, что его нельзя положить в контейнер Linux, напрямую связано с решением из раздела 7 (ClosedXML, напротив, в контейнере Linux работает).
• Обычный способ подключения — «COM-ссылка плюс встраивание типов взаимодействия». Если в Visual Studio добавить библиотеку объектов Microsoft Excel как COM-ссылку, по умолчанию используется встраивание типов взаимодействия (Embed Interop Types). В свою сборку попадают только реально использованные типы, поэтому PIA (основную сборку взаимодействия) в среду выполнения раздавать не нужно, и устойчивость к разным версиям Office выше.¹³
• dynamic и необязательные аргументы по-прежнему работают. Возможности C# для взаимодействия с Office (именованные и необязательные аргументы, упрощение COM-вызовов через dynamic) есть и в текущем .NET.¹³ Но запись через dynamic ещё сильнее прячет анонимные RCW, поэтому в коде, где важна дисциплина освобождения, лучше писать явные типы.
• Смотрите на API, привязанные к платформе. COM-связанные API вроде Marshal.ReleaseComObject помечены атрибутом «только для Windows»; вызов из кроссплатформенного проекта даёт предупреждение анализатора (CA1416). Вынести операции с Excel в отдельный проект проще.
• Обратное направление (вызов .NET из VBA) — отдельная тема. Конфигурация, в которой DLL на .NET 8 публикуется как COM и вызывается из VBA, по-прежнему возможна; шаги описаны в статье «Как использовать DLL на .NET 8 из VBA с типизацией». Если развернуть устройство наоборот — не «управлять Excel из C#», а «вызывать логику C# из макроса Excel», — временем жизни процесса начинает распоряжаться сам Excel, и в части случаев проблема оставшегося процесса структурно исчезает.

Итого: даже в эпоху .NET (Core) способ писать операции с Excel через COM и связанные ловушки почти те же, что во времена .NET Framework. Изменилось то, что принадлежность только к Windows нужно объявлять явно, а ссылки сместились к встраиванию типов взаимодействия. Рассуждение про RCW и паттерны освобождения (разделы 2–5) остаётся в силе.

9. Итог

Проблема оставшегося EXCEL.EXE перестаёт быть вопросом везения, как только понятна связка двух разных систем времени жизни: «COM живёт по счётчику ссылок, RCW в .NET умирает через GC». В виде чек-листа это выглядит так.

• Quit() — не освобождение. Excel не завершится, пока RCW не вернёт все COM-ссылки
• Составное выражение с двумя и более точками создаёт анонимный RCW. Промежуточные объекты кладите в переменные
• Освобождение по умолчанию — «изоляция метода + связка из трёх вызовов GC»; если нужен контроль порядка, дисциплинируйте ReleaseComObject через using-обёртку. Сырые вызовы ReleaseComObject по коду не разбрасывайте
• Страховочный Kill определяет только свой экземпляр через Application.Hwnd → GetWindowThreadProcessId и срабатывает только по схеме «Quit → ожидание → только по тайм-ауту»
• Автоматизация Excel на сервере, без участия пользователя, — неподдерживаемая конфигурация. Формирование отчётов без участия пользователя переносите на ClosedXML / Open XML SDK, а работу, которой нужны макросы или пересчёт, изолируйте в COM в интерактивной среде

Если в диспетчере задач выстроилась очередь EXCEL.EXE, это сигнал либо проблемы в приёмах (разделы 4–5), либо проблемы в конфигурации (разделы 6–7). Если неясно, к какой категории относится ваш код, или с какой части начинать замену, можем помочь начать с разбора обрабатываемых операций.

Похожие статьи

• Как построить вывод отчётов Excel — COM / Open XML / шаблоны
• Что такое VBA — ограничения, перспективы, когда стоит заменить и реалистичные паттерны миграции
• Что такое COM / ActiveX / OCX — различия и связь между ними
• Руководство по проверке VBA и внутренних инструментов перед прекращением поддержки VBScript

Смежные области консультаций

KomuraSoft LLC (合同会社小村ソフト) занимается расследованием проблем Windows-приложений, связанных с автоматизацией Excel/Office (оставшиеся процессы, зависания, блокировки файлов), сопровождением и дисциплинированием COM-активов, а также проектированием перехода обработки отчётов на библиотеки семейства Open XML.

• Техническая консультация / ревью архитектуры
• Использование и миграция существующих активов
• Разработка Windows-приложений
• Контакты

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему EXCEL.EXE не завершается, хотя я вызываю Quit()?

Потому что Quit() — это не освобождение, а лишь запрос «можно завершиться, когда все ссылки будут освобождены». .NET работает с COM-объектами через обёртку RCW (Runtime Callable Wrapper), и RCW продолжает удерживать COM-ссылку, пока сам не будет собран сборщиком мусора (или явно освобождён). Пока ссылка остаётся, Excel исправно ждёт. Момент освобождения зависит от GC, поэтому нестабильное воспроизведение — «на машине разработчика исчезает, а в продакшене остаётся» — тоже объясняется тем, что GC срабатывает в разное время.

Что такое «правило двух точек» при работе с Excel через COM?

Эмпирическое правило: не ставить на COM-объекте две и более точки подряд; каждый промежуточный объект сначала класть в переменную. Составное выражение вроде book.Worksheets[1].Range["A1"] за одну строку создаёт несколько анонимных RCW — для Worksheets (коллекции), Worksheets[1] (листа) и Range["A1"] (диапазона). Их нет ни в одной переменной, поэтому вызвать Marshal.ReleaseComObject нельзя — это главная причина утечки. Та же ловушка есть в foreach, в отброшенном значении внутри условия и в аргументах составного выражения: там тоже появляются анонимные RCW.

Как написать код, который надёжно завершает EXCEL.EXE?

Рекомендуемый способ — полностью изолировать работу с Excel в одном методе, а после выхода из него выполнить связку GC.Collect → GC.WaitForPendingFinalizers → GC.Collect. RCW как раз освобождает COM-ссылку в момент сборки GC, поэтому так подбираются и анонимные RCW, даже если правило двух точек нарушено. Есть и подход с Marshal.ReleaseComObject на каждом объекте, но официальная документация относит его к средствам, которые следует использовать «только когда это абсолютно необходимо»: обращение к уже освобождённому RCW даёт InvalidComObjectException или повреждение памяти. using-обёртку, которая дисциплинирует освобождение, вводите только когда действительно нужен контроль порядка.

Можно ли автоматизировать Excel с сервера или из пакетного задания?

Microsoft прямо пишет, что не рекомендует и не поддерживает автоматизацию Office из неинтерактивных клиентских приложений и компонентов (включая ASP.NET, DCOM и службы NT), которые работают без участия пользователя. Office рассчитан на интерактивного пользователя, поэтому в службе или на IIS процесс зависает в ожидании диалога, а экземпляры накапливаются без конца. Для формирования отчётов без участия пользователя рекомендуемая альтернатива — Open XML SDK или ClosedXML: они работают с файлом напрямую и не запускают Excel. Обработку, которой нужны возможности самого Excel — выполнение макросов, пересчёт формул, — лучше оставить в COM-коде, который работает в интерактивной среде.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.