Завершение работы Windows со стороны приложения — уведомления, перезагрузка и отключение питания

«Ночная перезагрузка Windows Update испортила файл, в который мы писали измерения.» «Выход из системы на общем ПК стирает то, что я редактировал.» Чтобы такого не случалось, завершение работы нельзя считать исключением: запрос выйти, пришедший снаружи, нужно проектировать как штатное поведение приложения.

Одного кода, который принимает уведомление о выходе, недостаточно. Времени после уведомления мало, а внезапное отключение питания не несёт уведомления вовсе. Центральная идея статьи — сделать штатное сохранение, короткие завершающие действия и восстановление при следующем запуске одним непрерывным целым.

Для сотрудников ИТ малых и средних компаний и разработчиков Windows-приложений, особенно тех, кто работает с ПК оборудования и долгоживущими приложениями, статья проходит выбор пути уведомления, реализацию, восстановление после перезагрузки, подготовку к отключению питания и проверку результата. Техническая основа — первичные источники Microsoft Learn на август 2026 года, на которые опирался оригинал.

1. Сначала вывод — уменьшите объём, который нужно сохранить, до того как ждать уведомления

Держите приложение в состоянии, из которого за несколько секунд после уведомления можно выйти, и сделайте так, чтобы следующий запуск мог восстановиться даже когда уведомления нет. Это базовая политика обработки завершения работы.

Вместо того чтобы сохранять большой объём данных после уведомления о выходе, сохраняйте на каждой вехе работы и оставляйте на выходе небольшую дельту. Для GUI-приложений и закрытия консоли ключевая цифра — около 5 секунд. У служб другой льготный срок, но ни один из них не гарантирован целиком.¹²³

1.1. Выберите путь уведомления для своего приложения

В .NET не опирайтесь только на AppDomain.ProcessExit. Начиная с .NET 10 среда не даёт обработчик по умолчанию для CTRL_CLOSE_EVENT / CTRL_SHUTDOWN_EVENT. Этот путь внешнего сигнала отделён от обычного выхода вроде возврата из Main. Подробности — в разделе 5.2.⁴

1.2. Вне обработки уведомлений нужны ещё две подготовки

Когда уведомление приходит, не спрашивайте пользователя «Сохранить?»; закончите короткими завершающими действиями и выйдите. Временную блокировку для работы, которую действительно нельзя прервать, разбирает раздел 4, автоматическое восстановление после перезагрузки — раздел 7.

Другая подготовка — оставить данные, которые ещё можно прочитать после отключения питания без уведомления. Запись во временный файл, сброс, подмена, резервная копия и проверка при запуске собраны в разделе 8. Когда путь уведомления реализован, переходите к проекту сохранения и восстановления в разделе 8 и к проверке в разделе 9.

flowchart TB
    accTitle: Проект сохранения, общий для уведомлений о выходе и отключения питания
    accDescr: Штатное сохранение держит несохранённую дельту маленькой; при уведомлении следуют короткие завершающие действия, а без него сохранённые данные проверяют и восстанавливают до возобновления работы
    daily["Сохранять на каждой вехе"] --> event{"Есть уведомление при выходе?"}
    event -->|"Да"| close["Сохранить только оставшуюся дельту и выйти"]
    event -->|"Нет"| lost["Завершающие действия на месте невозможны"]
    close --> boot["Проверить и восстановить при следующем запуске"]
    lost --> boot
    boot --> resume["Возобновить работу"]

Рис. 1: Вместо того чтобы напрягаться только при уведомлении, сделайте штатное сохранение до следующего запуска одним непрерывным процессом.

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

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

2.1. Смотрите на сеанс пользователя и на ядро отдельно

Если разделить «что заканчивается» на две части, обработку проще организовать. Сеанс пользователя — область, в которой работают приложения этого пользователя. Ядро и драйверы, напротив, принадлежат стороне ОС и продолжают работать после выхода пользователя.

В GUI WM_QUERYENDSESSION бит ENDSESSION_LOGOFF в lParam указывает на выход из системы. Если lParam равен 0, это завершение работы или перезагрузка, и их нельзя различить. Считайте lParam битовой маской.¹

Для несохранённых данных приложения выход из системы и завершение работы требуют одной и той же подготовки. Не разделяйте их на «при выходе из системы сохранять не нужно»; направляйте оба в общую процедуру сохранения. Это, однако, не делает условия уведомления консольных приложений и служб одинаковыми; проверяйте пути в разделах 5 и 6 для каждого.

flowchart TB
    accTitle: Думайте о выходе из системы и выходе системы отдельно
    accDescr: Выход из системы заканчивает приложения пользователя, а службы продолжают работать; завершение работы или перезагрузка системы останавливает и службы; отключение питания не уведомляет никого
    signout["Выход из системы"] --> user["Приложения пользователя выходят"]
    signout -.-> alive["Службы продолжают работать"]
    system["Завершение работы или перезагрузка"] --> user
    system --> svc["Службы тоже останавливаются"]
    power["Отключение питания"] --> none["Уведомления нет никому"]

Рис. 2: Выход из системы позволяет прогнать обработку выхода GUI, но это не считается проверкой остановки службы.

2.2. Почему «завершение работы не чинит, а перезагрузка чинит»

На клиентских ОС начиная с Windows 8 быстрый запуск по умолчанию включён на многих ПК, которые поддерживают гибернацию. В этой конфигурации завершение работы выводит пользователя, но состояние ядра и драйверов устройств сохраняется в файл гибернации и восстанавливается при следующей загрузке. Отключение питания не обязательно значит, что всё состояние ОС было сброшено.⁵

Это поведение условно. Там, где гибернация отключена (powercfg /hibernate off), где быстрый запуск выключен политикой или в параметрах электропитания, и на Windows Server получается традиционное полное завершение. Проверяйте параметры электропитания и через powercfg /a смотрите, доступен ли быстрый запуск.

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

flowchart TB
    accTitle: Быстрый запуск против полной загрузки
    accDescr: Завершение работы при включённом быстром запуске сохраняет и восстанавливает состояние ядра и драйверов, а полное завершение или перезагрузка инициализируют всё полной загрузкой
    s["Завершение работы"] --> q{"Использовать быстрый запуск?"}
    q -->|"Да"| save["Увести ядро и драйверы в гибернацию"]
    save --> restore["Восстановить состояние при следующем запуске"]
    q -->|"Нет"| full["Полное завершение работы"]
    full --> boot["Инициализировать полной загрузкой в следующий раз"]
    r["Перезагрузка"] --> boot

Рис. 3: Отключение питания — это не то же самое, что сброс ядра и драйверов.

Из командной строки shutdown /s запрашивает явное полное завершение, а shutdown /s /hybrid — гибридное поведение. Shutdown.exe по умолчанию делает полное завершение, поэтому важно не считать его тем же, что пункт «Завершение работы» на экране.⁵

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

3. GUI-приложения — отделите запрос от подтверждённого выхода

3.1. WM_QUERYENDSESSION — вопрос, WM_ENDSESSION — результат

Приложение, у которого есть окно и очередь сообщений, уведомляется о конце сеанса в два этапа.¹

Сам возврат TRUE на запрос не значит, что выход уже решён. Другое приложение может отказать, и выход отменяется. Если на этом этапе отключить или отдать ресурсы, которые ещё нужны, приложение, которое не вышло, больше не сможет работать. Поэтому завершающие действия переносят на подтверждённое уведомление.¹

flowchart TB
    accTitle: Запрос GUI и результат выхода
    accDescr: Даже после возврата TRUE на WM_QUERYENDSESSION другое приложение может отменить выход, поэтому завершающие действия после подтверждения выполняются только когда wParam у WM_ENDSESSION равен TRUE
    query["WM_QUERYENDSESSION"] --> reply["Сразу вернуть TRUE как правило"]
    reply --> result["WM_ENDSESSION"]
    result --> yes{"wParam равен TRUE?"}
    yes -->|"Да"| cleanup["Завершающие действия после подтверждения"]
    yes -->|"Нет"| running["Выход отменён; продолжать работу"]

Рис. 4: Не путайте ответ, который разрешает выход, с уведомлением, что выход подтверждён.

Есть случаи, когда можно вернуть FALSE и отказать в выходе, но правило — уважать намерение пользователя выйти. Приложение, которое отказывает, показывают как препятствующее завершению работы. У консольных приложений и приложений без видимого окна тоже есть ограничения: в обычной конфигурации приложение, которое не отвечает в течение 5 секунд, может быть завершено автоматически. Считайте блокировку исключительной обработкой раздела 4 и не используйте её для обычного сохранения.⁶

3.2. Около 5 секунд — это не гарантия, что успеете сохранить

Если задержать ответ примерно на 5 секунд на этапе WM_QUERYENDSESSION или WM_ENDSESSION, система показывает экран со списком приложений, которые препятствуют завершению работы, и пользователь может выбрать принудительное завершение. После принудительного завершения возможности дописать сохранение уже нет.⁶

Мера — сохранять штатно и уменьшать дельту на выходе. Несохранённое рабочее состояние кладите во временное место и восстанавливайте при следующем запуске. Не проектируйте приложение так, чтобы при завершении работы показывать диалог подтверждения и ждать. Обычное подтверждение выхода и запрос на выход от ОС — разные вещи.¹

flowchart TB
    accTitle: Держите работу на выходе маленькой
    accDescr: Проект, который сохраняет штатно, оставляет на выходе маленькую дельту, а проект, который копит в памяти до выхода, не укладывается в короткий льготный срок и рискует потерей через принудительное завершение
    good["Сохранять штатно"] --> small["Дельта, оставшаяся на выходе, маленькая"]
    small --> fast["Выйти с короткими завершающими действиями"]
    bad["Копить в памяти до выхода"] --> large["Сохранить всё на выходе"]
    large --> risk["Слишком мало льготного срока; риск принудительного завершения"]

Рис. 5: Подготовка к выходу за несколько секунд идёт до уведомления о выходе.

3.3. В WinForms и WPF отделите сохранение от завершающих действий, которые нельзя отменить

В WinForms соответствие — FormClosing с CloseReason.WindowsShutDown; в WPF — Application.SessionEnding. WPF можно зарегистрировать и через атрибут SessionEnding в XAML, и обработать, переопределив OnSessionEnding.

Оба, однако, — события этапа запроса. Здесь допустимо самое большее «идемпотентное сохранение снимка»: безвредно, если выход отменят, и даёт тот же результат, сколько бы раз ни выполнилось. Работу, которая возможна только после подтверждения выхода, например отключение, делают, принимая WM_ENDSESSION с wParam=TRUE в WndProc WinForms или в хуке WPF.

flowchart TB
    accTitle: Разделение обработки выхода в WinForms и WPF
    accDescr: FormClosing и SessionEnding сохраняют снимок, который безопасен даже если выход отменят, а хук на WM_ENDSESSION с TRUE выполняет завершающие действия, которые нельзя отменить
    notify["Этап запроса"] --> forms["FormClosing"]
    notify --> wpf["SessionEnding"]
    forms --> snapshot["Идемпотентное сохранение снимка"]
    wpf --> snapshot
    final["WM_ENDSESSION с TRUE"] --> hook["Принять в WndProc или хуке"]
    hook --> cleanup["Работа после подтверждения, например отключение"]

Рис. 6: Не запихивайте работу после подтверждения в события платформы.

Следующие два примера — часть, которая на этапе запроса сохраняет только рабочее состояние. Примеры кода — выдержки реализации; содержимое функции сохранения, обработка сбоев, регистрация событий и прочее зависят от приложения.

// WinForms: FormClosing вызывается и при завершении работы, и при выходе из системы
private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
    if (e.CloseReason == CloseReason.WindowsShutDown)
    {
        // Только идемпотентное сохранение снимка. Диалог не показывать.
        // e.Cancel = true (отказ) тоже не ставить.
        SaveWorkingStateToTempFile();
        return;
    }

    // В обычных случаях, например пользователь закрывает кнопкой X, подтверждение здесь нормально
}

// WPF: App.xaml.cs
protected override void OnSessionEnding(SessionEndingCancelEventArgs e)
{
    base.OnSessionEnding(e);

    // ReasonSessionEnding.Logoff / Shutdown можно различить, но
    // базовая схема — одно и то же сохранение снимка для обоих
    SaveWorkingStateToTempFile();

    // e.Cancel = true не ставить без очень веской причины
}

В обоих случаях направляйте данные, которые используются при обычном выходе, при завершении работы и, если возможно, при сбое, в общую функцию и формат сохранения. Если не создавать отдельный формат для каждого пути сохранения, логика восстановления при следующем запуске тоже может быть одна. Проектирование так, чтобы при сбое оставалась информация, разобрано в проектировании Windows-приложений, которые оставляют логи и дампы при сбое.

4. Блокируйте временно и только для работы, которую нельзя прервать

4.1. Регистрация причины и отказ выйти — разные работы

Работа, которая физически уничтожается, если её прервать, например запись CD или прошивка, — исключение. Зарегистрируйте причину через ShutdownBlockReasonCreate когда работа начинается, и снимите через ShutdownBlockReasonDestroy когда она заканчивается. Зарегистрированная причина показывается на экране со списком приложений, которые препятствуют завершению работы.⁷

Учтите, однако, что одной регистрации строки причины недостаточно, чтобы остановить завершение работы. Совместите её с флагом «защищено» и только пока он установлен возвращайте FALSE на WM_QUERYENDSESSION. Когда работа заканчивается, снимите и причину, и флаг защиты.

flowchart TB
    accTitle: Разделение ролей во временной блокировке выхода
    accDescr: Только пока идёт непрерываемая работа, совмещайте регистрацию причины с отказом на запрос и снимайте оба по завершении; принудительное завершение пользователем всё равно нельзя предотвратить
    start["Начинается непрерываемая работа"] --> reason["Зарегистрировать причину и поставить флаг защиты"]
    reason --> work["Обрабатывать на рабочем потоке"]
    work --> done["Закончить; снять причину и флаг"]
    work -.-> request["Тем временем приходит запрос на выход"]
    request --> refuse["Вернуть FALSE и показать причину"]
    refuse --> choice{"Решение пользователя"}
    choice -->|"Отменить"| keep["Продолжать работу"]
    choice -->|"Принудительно"| terminate["Может быть завершено"]

Рис. 7: Одна регистрация причины — это не отказ, и даже реализация отказа не предотвращает принудительное завершение.

4.2. Держите UI-поток способным принять запрос на выход

Регистрируйте и снимайте причину из потока, который создал целевое окно. Вызовы из других потоков завершаются ошибкой.⁷ Саму долгую непрерываемую работу, напротив, переносите на рабочий поток. Если UI-поток заблокирован синхронной обработкой, приложение становится «Не отвечает» ещё до того, как будет обработано сообщение, нужное для отказа.

[DllImport("user32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
static extern bool ShutdownBlockReasonCreate(IntPtr hWnd, string pwszReason);

[DllImport("user32.dll", SetLastError = true)]
static extern bool ShutdownBlockReasonDestroy(IntPtr hWnd);

// Вызывать из потока, который создал главное окно (вызовы из других потоков завершаются ошибкой)
_criticalOperationInProgress = true;
ShutdownBlockReasonCreate(this.Handle, "Запись данных измерений в файл");
try
{
    // Непрерываемую работу выполнять на рабочем потоке. Синхронный запуск на
    // UI-потоке останавливает насос сообщений, и приложение принудительно продолжают как
    // «Не отвечает» до того, как сможет выполниться код отказа WM_QUERYENDSESSION ниже
    await Task.Run(() => WriteMeasurementData());
}
finally
{
    ShutdownBlockReasonDestroy(this.Handle);
    _criticalOperationInProgress = false;
}

// Кроме того, возвращать FALSE на WM_QUERYENDSESSION только пока защищено, чтобы отказать
protected override void WndProc(ref Message m)
{
    const int WM_QUERYENDSESSION = 0x0011;
    if (m.Msg == WM_QUERYENDSESSION && _criticalOperationInProgress)
    {
        m.Result = IntPtr.Zero;   // Отказ. Зарегистрированная строка причины показывается в полноэкранном UI
        return;
    }
    base.WndProc(ref m);
}

Этот пример — каркас, который совмещает регистрацию причины, обработку на рабочем потоке и отказ на запрос. Обработка ошибок, включая сбои API, нужна отдельно. Держите строку причины короткой и конкретной и ограничивайте регистрацию временем, когда работу действительно нельзя прервать, а не держите её зарегистрированной всю жизнь приложения.⁷

Даже тогда пользователь может выбрать принудительное завершение. Есть и пути принудительного выхода вроде ENDSESSION_CRITICAL, поэтому никогда не делайте возможность блокировать предпосылкой сохранности данных. Подготовка к случаю, когда остановить не удалось, — проект сохранения и восстановления раздела 8.⁶

5. Консольные приложения и .NET — проверяйте условия, при которых приходят уведомления

5.1. Уведомления и льготные сроки, которые принимает SetConsoleCtrlHandler

В консольном приложении управляющие сигналы приходят обработчику, зарегистрированному через SetConsoleCtrlHandler. В отличие от обработки сообщений GUI, обработчик выполняется на отдельном потоке.²

Принудительное завершение процесса со вкладки «Подробности» Диспетчера задач и подобное — немедленное завершение без уведомления и вне этой таблицы.²

Не проектируйте консольное приложение в интерактивном сеансе так, чтобы оно ждало CTRL_LOGOFF_EVENT или CTRL_SHUTDOWN_EVENT. Интерактивные приложения завершаются в момент выхода из системы, поэтому на практике эти события могут принять только процессы, работающие как службы. Кроме того, процесс, который загрузил gdi32.dll или user32.dll, считается приложением Windows, и обработчики LOGOFF/SHUTDOWN не вызываются. Официальный обход в этом случае — создать скрытое окно и принимать WM_QUERYENDSESSION / WM_ENDSESSION.²⁸

flowchart TB
    accTitle: Условия приёма уведомлений о выходе консоли
    accDescr: Интерактивная консоль может принять уведомление о закрытии, но не может рассчитывать на уведомления о выходе из системы или завершении работы, а даже службе нужен другой путь уведомления, как только она загружает GUI-DLL
    console["Консольный процесс"] --> close["Закрытие идёт в обработчик управления"]
    console --> q{"Ждать LOGOFF или SHUTDOWN?"}
    q -->|"Интерактивный сеанс"| no["На это уведомление опираться нельзя"]
    q -->|"Служба"| dll{"Загружены GUI-DLL?"}
    dll -->|"Нет"| signal["Обработать соответствующий управляющий сигнал"]
    dll -->|"Да"| window["Принимать через скрытое окно"]

Рис. 8: Не считайте обработку закрытия консоли обработкой завершения работы.

Следующая выдержка готовится к Ctrl+C и закрытию консоли. Она удерживает делегат, чтобы сборщик мусора его не собрал, и после коротких завершающих действий переходит к обработчику по умолчанию. Одна эта регистрация не гарантирует уведомления о завершении работы интерактивному приложению.

// Консольное приложение: завершающие действия на Ctrl+C и закрытие консоли
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool SetConsoleCtrlHandler(HandlerRoutine handler, bool add);

delegate bool HandlerRoutine(int ctrlType);   // 2 = CTRL_CLOSE_EVENT

static readonly HandlerRoutine s_handler = OnCtrlEvent;  // Держать ссылку, чтобы сборщик не собрал

static bool OnCtrlEvent(int ctrlType)
{
    // Только завершающие действия, которые укладываются в 5 секунд
    FlushAndCloseDataFile();
    return false;   // Перейти к обработчику по умолчанию; процесс выходит
}

static void Main()
{
    SetConsoleCtrlHandler(s_handler, add: true);
    // ...
}

5.2. Начиная с .NET 10 не кладите завершающие действия только в ProcessExit

Начиная с .NET 10 среда больше не даёт обработчик по умолчанию для CTRL_CLOSE_EVENT / CTRL_SHUTDOWN_EVENT. Без собственного обработчика или обработчика из библиотеки верхнего уровня обработка ОС по умолчанию завершает процесс, и на этом пути не срабатывают ни AppDomain.ProcessExit, ни AssemblyLoadContext.Unloading.⁴

Это изменение поведения по умолчанию для внешних сигналов завершения. Это не значит, что ProcessExit больше не срабатывает при обычном выходе вроде возврата из Main.

flowchart TB
    accTitle: Снятие зависимости от обработчика завершения .NET по умолчанию
    accDescr: Старая среда связывала соответствующие сигналы с ProcessExit, но начиная с .NET 10 обработчик по умолчанию не предоставляется, поэтому используйте путь уведомления модели приложения
    signal["Сигнал CLOSE или SHUTDOWN"] --> old["Обработка старой среды по умолчанию"]
    old --> event["Поднимает ProcessExit и подобные"]
    signal --> modern["Нет обработки по умолчанию начиная с .NET 10"]
    modern --> own{"Приложение обрабатывает?"}
    own -->|"Нет"| os["Завершено обработкой ОС по умолчанию"]
    own -->|"Да"| handle["Завершающие действия, которые соответствуют модели"]

Рис. 9: Различайте обычный выход и завершение внешним сигналом и дайте обработчик, который нужна модели приложения.

Сосредоточьте завершающие действия там, где это соответствует модели приложения. Для GUI это события и подтверждённое уведомление раздела 3; для Generic Host — IHostApplicationLifetime и BackgroundService.StopAsync; для обычного консольного приложения — SetConsoleCtrlHandler или PosixSignalRegistration. Когда используете последнее, выбирайте сигналы, которые соответствуют целевым путям завершения, например SIGINT, SIGTERM и SIGHUP.⁴

В Generic Host явно задайте HostOptions.ShutdownTimeout. Однако одна настройка на стороне Host не растягивает внешний льготный срок GUI, консоли или SCM. Даже хотя у Ctrl+C нет явного тайм-аута, всё равно нужно готовиться к отключению питания и другим путям завершения. Во всех моделях политика одна: держите состояние сохранённым и держите работу после уведомления маленькой.

flowchart TB
    accTitle: Остановка Host и внешний льготный срок выхода
    accDescr: Остановка Generic Host сосредоточена в StopAsync, но задание тайм-аута HostOptions не растягивает льготный срок выхода ОС или SCM, поэтому проверяйте оба
    outer["Запрос на выход от ОС или SCM"] --> host["Путь остановки Host"]
    host --> stop["Завершающие действия в StopAsync"]
    stop --> inner["Задать время остановки на стороне Host"]
    outer -.-> limit["Внешний льготный срок существует отдельно"]
    inner --> check["Измерить, укладывается ли быстро"]
    limit --> check

Рис. 10: Проверяйте лимиты времени на стороне Host и на стороне ОС отдельно и не ограничивайтесь растягиванием настройки.

6. Службы Windows — сразу возвращайтесь из обработчика управления

6.1. Разница между SHUTDOWN и PRESHUTDOWN

Службы не останавливаются при выходе из системы, но останавливаются при завершении работы и перезагрузке. Уведомление приходит от SCM (Service Control Manager), и служба должна объявить флаг, соответствующий коду управления, который хочет принимать.³

flowchart TB
    accTitle: Этапы уведомления службам о выходе
    accDescr: SCM сначала уведомляет службы, которые принимают PRESHUTDOWN, ждёт их остановки или тайм-аута, затем переходит к обычному уведомлению SHUTDOWN
    start["Начинается завершение работы системы"] --> pre["Уведомить службы, принимающие PRESHUTDOWN"]
    pre --> wait["Ждать остановки или настроенного срока"]
    wait --> shut["Уведомить службы, принимающие SHUTDOWN"]
    shut --> proceed["После льготного срока перейти к выходу системы"]

Рис. 11: Быть уведомлённым раньше и быть ожидаемым — разные условия; у PRESHUTDOWN тоже есть настроенный срок.

Тайм-аут PRESHUTDOWN задаётся через ChangeServiceConfig2(SERVICE_CONFIG_PRESHUTDOWN_INFO). По умолчанию 10 секунд начиная с Windows 10 Creators Update (сборка 15063) и 3 минуты до того. Если предполагать «PRESHUTDOWN всегда даёт 3 минуты», вы не получите ожидаемого времени.⁹

Поскольку PRESHUTDOWN задерживает завершение работы всей системы, используйте его только когда действительно нужно. Переписывать обычный WaitToKillServiceTimeout со стороны службы, чтобы растянуть его, тоже не рекомендуется.³

6.2. Отделите приём уведомления от фактической остановки

Обработчик управления должен вернуться в течение 30 секунд, но вместо того чтобы считать это 30 секундами, которыми можно пользоваться, структурируйте так, чтобы подать сигнал остановки и сразу вернуться. Долгую работу отдайте другому потоку и сообщайте SERVICE_STOP_PENDING.³

// Служба Win32: принимать PRESHUTDOWN и оставить работу остановки рабочему потоку
g_status.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_PRESHUTDOWN;

DWORD WINAPI ServiceHandlerEx(DWORD control, DWORD, LPVOID, LPVOID)
{
    switch (control)
    {
    case SERVICE_CONTROL_PRESHUTDOWN:
    case SERVICE_CONTROL_STOP:
        ReportStatus(SERVICE_STOP_PENDING, /*waitHintMs*/ 3000);
        SetEvent(g_stopEvent);   // Сигнализировать рабочему остановиться и сразу вернуться
        return NO_ERROR;
    }
    return ERROR_CALL_NOT_IMPLEMENTED;
}

// Сторона рабочего: если завершающие действия длятся дольше wait hint, продолжайте
// периодически сообщать SERVICE_STOP_PENDING, увеличивая dwCheckPoint. SCM судит
// по wait hint и продвигающемуся checkpoint, что служба «ещё жива и
// продвигается». Если сообщения прекратятся, её считают зависшей и завершение работы может
// идти дальше. Всегда сообщайте SERVICE_STOPPED по окончании

На стороне рабочего, если завершающие действия длятся дольше wait hint, продолжайте сообщать SERVICE_STOP_PENDING, продвигая dwCheckPoint. Если сообщения о прогрессе прекратятся, службу могут счесть зависшей. Сообщение SERVICE_STOPPED по окончании — часть обработки остановки.³⁹

flowchart TB
    accTitle: Разделение работы между обработчиком управления службы и рабочим
    accDescr: Обработчик управления сообщает stop pending, сигнализирует рабочему и сразу возвращается; рабочий делает завершающие действия и сообщения о прогрессе и в конце сообщает stopped
    handler["Обработчик управления"] --> pending["Сообщить STOP_PENDING"]
    pending --> signal["Сигнализировать рабочему остановиться"]
    signal --> back["Обработчик сразу возвращается"]
    signal --> worker["Рабочий делает завершающие действия"]
    worker --> report["Сообщать о прогрессе, если длится долго"]
    report --> stopped["Сообщить STOPPED по окончании"]

Рис. 12: Не блокируйте поток, который принимает уведомление, долгой обработкой остановки.

6.3. Умейте закончить быстро даже если зависимость остановилась первой

При завершении работы SCM по умолчанию шлёт уведомления без учёта зависимостей служб. Обработка остановки должна справляться со случаем, когда служба-зависимость уже недоступна, и не должна слишком долго ждать ответов сетевых партнёров. Вместо того чтобы тратить время на освобождение памяти и подобное, отдавайте приоритет быстрой фиксации нужных данных.³

Эта политика важна и в связи с ИБП. Чем дольше служба растягивает ожидание, тем труднее завершить остановку всей ОС до того, как сядет батарея. Вместо увеличения льготного срока уменьшайте работу при остановке, сохраняя на каждой вехе.³

Когда .NET Worker Service работает под UseWindowsService, STOP / SHUTDOWN превращаются в остановку Host, которая ведёт к BackgroundService.StopAsync. Стандартная реализация на момент написания оригинала не принимает PRESHUTDOWN, поэтому если он нужен, придётся расширить реализацию обработчика. Политика явно задавать HostOptions.ShutdownTimeout и укладывать сам StopAsync в несколько секунд та же. Общую реализацию см. в Как создать и эксплуатировать службу Windows.

7. Восстановление после перезагрузки — выровняйте регистрацию, данные восстановления и вход

7.1. RegisterApplicationRestart заранее регистрирует путь восстановления

На ПК оборудования и в необслуживаемой работе проект идёт дальше сохранения и выхода: он покрывает возобновление работы после перезагрузки. RegisterApplicationRestart — API, который регистрирует приложение на перезапуск в каждой из этих ситуаций: сбой (необработанное исключение), «Не отвечает», перезапуск приложения из‑за обновления и перезапуск ОС из‑за обновления.¹⁰

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

Для приложения, которому нужно повышение, проектируйте путь восстановления, держа UI на обычных правах и вынося привилегированную работу в службу, либо через задачу Планировщика заданий с «Выполнять с наивысшими правами» и подобным.¹⁰

7.2. Обратный вызов восстановления и ARSO играют разные роли

Если ещё использовать RegisterApplicationRecoveryCallback, WER (Windows Error Reporting) вызывает обратный вызов восстановления при сбое, и можно сохранить данные, с которыми работали. Пока сохранение продолжается, вызывайте ApplicationRecoveryInProgress в пределах зарегистрированного интервала ping и уведомляйте ApplicationRecoveryFinished по окончании. Если сообщения о прогрессе прекратятся, обработку восстановления могут оборвать.

flowchart TB
    accTitle: Сохранение и уведомление о прогрессе в обратном вызове восстановления
    accDescr: Обратный вызов восстановления, который вызывает WER, продолжает вызывать ApplicationRecoveryInProgress в пределах интервала ping, пока сохраняет, и уведомляет ApplicationRecoveryFinished по окончании
    reg["Заранее зарегистрировать обратный вызов восстановления"] --> crash["Сбой; WER вызывает его"]
    crash --> save["Сохранить данные, с которыми работали"]
    save --> progress["Сообщать о прогрессе в пределах интервала ping"]
    progress --> completed{"Сохранение закончено?"}
    completed -->|"Ещё нет"| save
    completed -->|"Готово"| done["Уведомить, что восстановление закончено"]
    progress -.-> timeout["Могут оборвать, если сообщения прекратятся"]

Рис. 13: Не только сохраняйте; уведомляйте WER о прогрессе и завершении.

Замена файлов, которые используются во время обновления, и перезапуск — работа Restart Manager. Это разобрано в Как заменить EXE или DLL, которые используются.

Механизм, который возвращает сеанс пользователя после перезапуска ОС, напротив, — ARSO (автоматический вход Winlogon). Когда Windows Update начинает автоматический перезапуск, он безопасно сохраняет учётные данные последнего интерактивного пользователя и настраивает Autologon, и после перезапуска входит этим пользователем и блокирует экран.¹¹

flowchart TB
    accTitle: Регистрация перезапуска, вход и восстановление данных
    accDescr: На фоне предварительной регистрации перезапуска сбой требует согласия пользователя, а приложениям пользователя после перезапуска ОС нужны восстановление сеанса через ARSO или подобное и восстановление сохранённого состояния
    reg["Зарегистрировать перезапуск до возникновения проблемы"] --> crash["Сбой или «Не отвечает»"]
    crash --> consent["Получить согласие пользователя"]
    consent --> app["Перезапустить приложение"]
    reg --> update["Перезапуск ОС с нужными флагами"]
    update --> session["Восстановить сеанс через ARSO или подобное"]
    session --> app
    app --> data["Прочитать сохранённую точку восстановления"]
    session -.-> policy["Проверить политику и условия запуска"]

Рис. 14: Дайте не только регистрацию перезапуска приложения, но и путь, которым возвращаются сеанс и рабочее состояние.

shutdown /g — команда, которая запрашивает перезапуск плюс возобновление зарегистрированных приложений. ARSO может быть отключён организационной политикой вроде DisableAutomaticRestartSignOn, поэтому проверяйте его вместе с требованиями необслуживаемого восстановления. Фоновую обработку, которая нужна всегда, лучше запускать как службу Windows, чем делать зависимой от автоматического входа пользователя.¹¹

8. Отключение питания без уведомления — проектируйте сохранение и загрузку парой

8.1. Временный файл, подмена, резервная копия и проверка при запуске как один комплект

Сработавший автомат, вышедший из строя блок питания или выдернутый шнур не несут ни WM_ENDSESSION, ни PRESHUTDOWN. Если перезаписывать исходный файл на месте, прерывание посередине может оставить файл со смешанным старым и новым содержимым.

База — полностью записать во временный файл на том же томе, сбросить и затем подменить. ReplaceFile собирает шаги, соответствующие сохранению в новый файл, откладыванию исходного, переименованию и удалению, и переносит атрибуты вроде времени создания, ACL и альтернативных потоков данных. Заменяемый файл, файл замены и резервная копия должны быть на одном томе. File.Replace в .NET вызывает этот API.¹²

flowchart TB
    accTitle: Сохранение файла и восстановление при следующем запуске
    accDescr: Записать во временный файл на том же томе, сбросить, подменить, сохранив резерв, затем при запуске проверить основной файл и при необходимости откатиться на резерв
    tmp["Временный файл на том же томе"] --> write["Записать до конца и сбросить"]
    write --> replace["Подменить; старое содержимое уходит в .bak"]
    replace -.-> boot["Следующий запуск"]
    boot --> valid{"Основной файл цел?"}
    valid -->|"Да"| main["Читать основной файл"]
    valid -->|"Нет"| backup["Откатиться на резерв"]

Рис. 15: Реализуйте не только безопасный способ писать, но и способ читать, когда файл сломан.

// Стандартный шаблон сохранения настроек и данных: записать во временный файл, затем подменить, сохранив старое содержимое
public static void SaveAtomically(string path, string content)
{
    string dir = Path.GetDirectoryName(path)!;
    string tmp = Path.Combine(dir, Path.GetRandomFileName());  // Создать на том же томе

    try
    {
        using (var fs = new FileStream(tmp, FileMode.CreateNew, FileAccess.Write))
        using (var writer = new StreamWriter(fs))
        {
            writer.Write(content);
            writer.Flush();
            fs.Flush(flushToDisk: true);   // Эквивалент FlushFileBuffers. Выводит буферы ОС
                                           // на диск (пределы кэша на стороне устройства — в разделе 8.2)
        }

        if (File.Exists(path))
            File.Replace(tmp, path, path + ".bak");  // Вызывает ReplaceFile. Держит старое содержимое как .bak
        else
            File.Move(tmp, path);
    }
    catch
    {
        // Если сбой посередине, не оставлять временный файл. Если периодические сохранения
        // продолжают сбоить, полные копии постепенно заполнят том
        try { File.Delete(tmp); } catch { /* Неудачное удаление уступает исходному исключению */ }
        throw;
    }
}

Хотя этот пример назван SaveAtomically, он не гарантирует атомарность через отключение питания. В обычной работе он оставляет читаемым либо полный старый файл, либо полный новый, но ReplaceFile — многошаговая операция пространства имён, и её атомарность против внезапного отключения питания спецификацией не гарантируется. Именно поэтому вы держите .bak и реализуете процедуру загрузки, которая при запуске проверяет основной файл и откатывается на резерв, если он сломан.¹²

catch в примере существует, чтобы временные файлы не копились при обычных сбоях и не заполняли том. Он не рассчитывает, что этот код выполнится в момент отключения питания. Для журналов только на дозапись и CSV не применяйте подход подмены целого файла как есть; используйте формат, который учитывает, как он ломается, например «писать одну строку на запись и при загрузке отбрасывать повреждённую последнюю строку».

8.2. Различайте успех WriteFile и достижение диска

Даже когда WriteFile успешен, данные могут ещё сидеть в кэше ОС. Windows обычно пишет в системные буферы и применяет данные к диску отложенной записью. На важных контрольных точках сбрасывайте через FlushFileBuffers или укажите FILE_FLAG_WRITE_THROUGH при CreateFile, чтобы запросить немедленную запись. Метаданные файловой системы тоже кэшируются, поэтому их фиксация включает сброс или write-through.¹³

Write-through, однако, не то же самое, что «не использовать кэш ОС». Частые вызовы FlushFileBuffers неэффективны, поэтому где нужно рассмотрите сочетание с FILE_FLAG_NO_BUFFERING. На практике реалистичный проект — сбрасывать в точках, которые важны для целостности, например на границах транзакций и непосредственно перед закрытием файла.¹³

flowchart TB
    accTitle: Граница между успехом записи и сохранением
    accDescr: Обычная запись доходит до накопителя из кэша ОС с задержкой; сброс или write-through толкают к фиксации, но ограничения кэша на стороне устройства остаются
    write["WriteFile успешен"] --> cache["Может быть в кэше ОС"]
    cache --> delayed["Отложенная запись"]
    cache --> flush["Сброс на контрольной точке"]
    delayed --> device["Применено к накопителю"]
    flush --> device
    device -.-> limit["Пределы кэша на стороне устройства"]

Рис. 16: Не считайте успех API, фиксацию кэша ОС и устойчивость к отключению питания одним и тем же.

У энергозависимого кэша на стороне устройства тоже есть пределы, и нельзя сказать «мы сбросили, значит это полностью переживает отключение питания на любом железе». Связь диспетчера кэша, отложенной записи и аппаратных кэшей подробно объяснена в Диспетчере кэша: когда WriteFile оказывается на диске?.

8.3. Используйте ИБП, чтобы превратить отключение питания в запланированное завершение работы

Роль ИБП — не устранить отключения, а превратить отключение питания без уведомления в запланированное завершение работы с уведомлением. Нужное условие — такое соотношение:

Время работы батареи ИБП > время обнаружения переключения + завершающие действия приложений и служб + завершение остановки ОС

Переключение между питанием от сети и батареей и низкий остаток заряда сообщаются через PBT_APMPOWERSTATUSCHANGE. GUI принимает это через WM_POWERBROADCAST; служба объявляет SERVICE_ACCEPT_POWEREVENT и затем принимает SERVICE_CONTROL_POWEREVENT в HandlerEx. WM_POWERBROADCAST в обработчик управления службы не доставляется.¹⁴

После приёма проверьте ACLineStatus и BatteryLifePercent через GetSystemPowerStatus и переходите к приостановке измерений, сохранению и запросу завершения работы.¹⁴

flowchart TB
    accTitle: От обнаружения ИБП до завершения остановки
    accDescr: Обнаружить переход ИБП на батарею через соответствующий путь уведомления, проверить состояние питания, перейти к сохранению и завершению работы и спроектировать всю последовательность так, чтобы она укладывалась во время работы батареи
    outage["Отключение; ИБП переходит на батарею"] --> notice["Уведомление о питании по подходящему пути"]
    notice --> check["Проверить состояние питания и остаток заряда"]
    check --> save["Приостановить измерения и сохранить"]
    save --> req["Запросить завершение работы у ОС"]
    req --> done["Закончить завершающие действия и выход ОС"]
    done -.-> time["Уложить всю последовательность во время работы"]

Рис. 17: Укладывайте во время работы ИБП не только приложение, но и время до выхода ОС.

В конфигурациях, где Windows видит ИБП как батарею, например типичный ИБП с USB, стандартные API могут его мониторить. Если у управляющего ПО поставщика есть функция «завершить работу при N% остатка», также проверьте, что её порог согласован со временем завершающих действий. Возобновление после сна или гибернации — отдельная тема; см. Сон, гибернация, Modern Standby и долгоживущие приложения.

9. Проверка — подтвердите уведомления, время и результаты восстановления

9.1. Воспроизводите пути выхода на тестовой машине, а не в продакшене

Не пробуйте сначала на продакшен-ПК оборудования; используйте тестовую машину или виртуальную машину вроде Hyper-V. На виртуальной машине заранее сделайте контрольную точку и повторяйте тесты с тестовыми данными, которые можно потерять.

Выход из системы отличается тем, что установлен бит ENDSESSION_LOGOFF, но это простой способ подтвердить путь уведомления GUI. Не путайте команды полного, гибридного и перезапуска; пробуйте их отдельно.¹⁵

flowchart TB
    accTitle: Поэтапное расширение проверки завершения работы
    accDescr: В тестовой среде пробовать уведомления GUI и каждую операцию выхода, подтвердить восстановление после внезапной остановки на ВМ, затем проверить устойчивость к отключению питания, включая накопитель, на железе, эквивалентном продакшену
    prep["Подготовить тестовую машину и данные"] --> notify["Пробовать пути уведомления и операции выхода"]
    notify --> time["Измерить время завершающих действий"]
    time --> vm["Подтвердить восстановление после внезапной остановки ВМ"]
    vm --> real["Проверить на реальном железе, включая накопитель"]
    real --> check["Подтвердить данные и восстановление при следующем запуске"]

Рис. 18: Проверяйте не только то, что приложение нормально выходит, но и что оно может восстановить после внезапной остановки.

Выключение ВМ воспроизводит только внезапную остановку гостя. Оно не воспроизводит потерю энергозависимого кэша физического диска или порчу, зависящую от контроллера, поэтому при поставке как ПК оборудования финальное подтверждение делайте на железе, эквивалентном продакшену.

Пишите метку времени в начале и конце функции завершающих действий и измеряйте, укладывается ли она примерно в 5 секунд для GUI и подобного или в льготный срок, настроенный для службы. Подтверждайте не только то, что выход удался, но и что было загружено при следующем запуске и откуда можно было возобновить работу.

9.2. Изолируйте, что случилось ночью, из журнала событий

В журнале «Система» Windows Event ID 1074 записывает процесс, который инициировал завершение работы, пользователя и причину. При неожиданном завершении при следующем запуске записываются 41 (Kernel-Power) или 6008.¹⁵

# Проверить недавнюю историю событий, связанных с завершением работы
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1074, 6008, 41 } -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

Если 1074 показывает перезапуск Windows Update, а данные всё равно повреждены, сначала разбирайте обработку уведомления о выходе и путь сохранения. С другой стороны, не заключайте об отключении питания только из 41 или 6008. Они указывают на неожиданное завершение, и синий экран или принудительный сброс тоже кандидаты.¹⁵

flowchart TB
    accTitle: Выбор того, что расследовать, по журналу событий завершения работы
    accDescr: Подтвердить инициирующий процесс и причину из 1074 и считать 41 и 6008 подсказками к неожиданному завершению, чтобы сверить с окружающей информацией вроде кода bug check и дампов
    log["Журнал событий системы"] --> normal["1074: инициирующий процесс и причина"]
    normal --> cleanup["Разобрать обработку уведомления и путь сохранения"]
    log --> unexpected["41 и 6008: неожиданное завершение"]
    unexpected --> evidence["Проверить BugcheckCode и дампы"]
    evidence --> classify["Изолировать сбой, отключение питания и прочее"]

Рис. 19: 41 и 6008 — не доказательство самого отключения питания; они вход в дальнейшее расследование.

Ненулевой BugcheckCode в событии 41 — подсказка к сбою. Если он 0 и дампа памяти нет, подозревают отключение питания, но решайте, сверяя с окружающей информацией. Если оказывается отключение питания, сосредоточьтесь на проекте сохранения и ИБП раздела 8; если это был запланированный выход — на уведомлениях и завершающих действиях разделов 3–6.

10. Итог — проектируйте до следующего запуска, а не только обработку выхода

Обработка завершения работы — не про обработчик события, который один раз выполняется на выходе. Важно сделать штатное сохранение → короткие завершающие действия → проверку и восстановление при следующем запуске одним непрерывным целым.

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

flowchart TB
    accTitle: Финальная проверка от обработки выхода до восстановления
    accDescr: Держать сохранённое состояние во время обычной обработки, делать маленькие завершающие действия при уведомлении о выходе и проверять данные, которые остаются даже без уведомления, чтобы восстановиться при следующем запуске
    daily["Держать сохранённое состояние штатно"] --> endq{"Есть уведомление о выходе?"}
    endq -->|"Да"| short["Выйти с короткими завершающими действиями"]
    endq -->|"Нет"| prior["Последнее сохранённое состояние — всё, что есть"]
    short --> nextboot["Проверить и восстановить при следующем запуске"]
    prior --> nextboot
    nextboot --> restart["Вернуться к работе при нужных условиях"]

Рис. 20: Не отделяйте реализацию события выхода от штатного сохранения и восстановления при следующем запуске.

Наконец, пробуйте пути уведомления и требуемое время на тестовой машине и подтверждайте восстановление после внезапной остановки тоже. В расследовании после факта используйте 1074 / 41 / 6008 как подсказки, чтобы изолировать запланированный выход от неожиданного завершения.

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

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

• Как заменить EXE или DLL, которые используются — Restart Manager и проблема «файл используется» при автоматическом обновлении
• Как создать и эксплуатировать службу Windows — от выбора между Планировщиком заданий и службой до превращения BackgroundService в службу
• Спящий режим, гибернация и Modern Standby: как не дать долгоживущему приложению остановиться ночью
• Глубины ввода-вывода Windows (часть 4) — диспетчер кэша: когда WriteFile оказывается на диске
• Как проектировать логи и дампы при сбое Windows-приложения
• Чек-лист безопасной работы с дочерними процессами в Windows-приложении

Смежные области консультирования

KomuraSoft LLC занимается проектированием и реализацией мер против завершения работы и отключения питания для ПК оборудования и долгоживущих приложений, расследованием причин порчи данных и сбоев «утром уже не работало», которые начинаются с перезапуска Windows Update или выхода из системы, и ревью проекта обработки остановки служб Windows и автоматического восстановления. Можно начать со стадии «кажется, каждый раз при завершении работы что-то ломается, но не знаю, с чего начать».

• Разработка Windows-приложений
• Расследование сбоев и анализ причин
• Техническая консультация и ревью проекта
• Связаться с нами

Справочные ссылки

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

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

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

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

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

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

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

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

Сбой, который не ушёл после «Завершение работы», исчез после «Перезагрузка». Почему?

На клиентских ОС начиная с Windows 8, если включён быстрый запуск (по умолчанию на большинстве ПК, которые поддерживают гибернацию), «Завершение работы» идёт по схеме гибридного завершения (hybrid shutdown). Пользователь выходит из системы, но состояние ядра и драйверов сохраняется в файл гибернации и при следующей загрузке восстанавливается как есть. То есть ядро ОС не сбрасывается. «Перезагрузка», напротив, всегда делает полную загрузку, поэтому сбои драйверов и служб сбрасываются. В инструкции по диагностике пишите «Перезагрузить», а не «выключить и снова включить». Если из командной строки нужно полное завершение работы, можно использовать shutdown /s.

Можно ли задержать завершение работы, пока приложение не закончит сохранение?

Попросить подождать ненадолго можно, надёжно остановить — нельзя. Если зарегистрировать строку причины через ShutdownBlockReasonCreate только на время операции, которую нельзя прервать, эта причина появится на экране «Это приложение препятствует завершению работы», и пользователь решит, продолжить или отменить. Пользователь всё равно может выбрать принудительное продолжение, а принудительное завершение или перезагрузка из‑за обновления могут не ждать вовсе. Поэтому правильный путь — не «блокировать», а частое автосохранение, чтобы под риском было меньше данных, плюс завершающие действия, рассчитанные на несколько секунд с момента уведомления.

Остановка службы Windows занимает много времени. Можно ли увеличить отведённое на завершение время?

В конфигурации по умолчанию, которая принимает SERVICE_CONTROL_SHUTDOWN, отводится примерно 20 секунд, и это зависит от значения реестра WaitToKillServiceTimeout. Переписывать это значение со стороны приложения, чтобы растянуть срок, не рекомендуется. Если нужно больше времени, можно объявить SERVICE_ACCEPT_PRESHUTDOWN и принимать SERVICE_CONTROL_PRESHUTDOWN: уведомление приходит раньше остальных, а тайм-аут задаётся через ChangeServiceConfig2 (по умолчанию 10 секунд начиная с Windows 10 Creators Update и 3 минуты до того). PRESHUTDOWN, однако, на это время задерживает завершение работы всей системы, поэтому оставляйте его для случаев, когда он действительно нужен, а саму остановку проектируйте так, чтобы она укладывалась в несколько секунд.

Можно ли делать завершающие действия при выходе в AppDomain.ProcessExit .NET?

На это лучше не опираться. Раньше среда выполнения регистрировала обработчик сигналов по умолчанию, и ProcessExit срабатывал на CTRL_CLOSE_EVENT и CTRL_SHUTDOWN_EVENT, но начиная с .NET 10 среда больше не даёт обработчики сигналов завершения по умолчанию, и в этих ситуациях ProcessExit не возникает. Реализуйте завершающие действия на пути уведомления, который соответствует модели приложения: GUI-приложения — FormClosing или SessionEnding (это уведомления этапа запроса, поэтому ограничивайтесь идемпотентным сохранением; действия, которые допустимы только после подтверждения сеанса, делайте в хуке WM_ENDSESSION); Generic Host / Worker Service — IHostApplicationLifetime и StopAsync; консольные приложения — SetConsoleCtrlHandler или PosixSignalRegistration.

Как не дать файлам повредиться при внезапном отключении питания?

Отключение питания не несёт никакого уведомления, поэтому остаётся писать так, чтобы файл не ломался, когда бы питание ни пропало. Базовая схема — не перезаписывать исходный файл на месте: полностью записать во временный файл на том же томе, сбросить на диск и подменить через ReplaceFile (в .NET — File.Replace). В обычной работе это оставляет возможность прочитать либо полный старый файл, либо полный новый, но атомарность ReplaceFile через отключение питания спецификацией не гарантируется, поэтому держите резервную копию (третий аргумент) и при запуске проверяйте основной файл, а если он повреждён — откатывайтесь на резерв. Кроме того, успех WriteFile не значит, что данные дошли до диска, поэтому на важных контрольных точках подтверждайте запись через FlushFileBuffers или FILE_FLAG_WRITE_THROUGH. На ПК оборудования к этому обычно добавляют ИБП: обнаруживают переход на батарею и переводят систему в безопасное завершение работы.

Об авторе

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

Го Комура

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

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