Вы все плюете на этот пост, но здесь идет ...
Вы пытаетесь решить проблему на неправильном уровне (т.е. запускать код в вашем приложении, когда ядро убивает приложение). Реальная проблема заключается в том, чтобы гарантировать, что база данных правильно отражает наличие (или отсутствие) ее клиентских приложений.
Чтобы решить эту проблему, не допускайте, чтобы приложения находились в «неконгруэнтном состоянии» между взаимодействиями с пользователем. Другими словами, не запускайте транзакции, которые вы не можете быстро зафиксировать, не записывайте данные в файлы, которые оставляют файл в наполовину записанном или нечитаемом состоянии, и не держите ресурсы, внешние по отношению к вашему приложению, как несовместимые. состояние вне взаимодействия с пользователем. Иными словами, если ваше приложение не занято, отвечая на обработчик событий, оно должно быть готово к немедленному закрытию.
Если вы будете следовать вышеупомянутой практике, вы найдете очень мало сценариев, в которых вам нужно «быстро очиститься» перед завершением. Вне взаимодействия, когда пользователь нажимает «ОК» или «Сохранить» и т. Д., Хорошо написанное приложение должно выдерживать немедленное завершение без какого-либо длительного повреждения или повреждения своих хранилищ данных.
Если вам абсолютно необходимо установить флаг в базе данных при выходе (что звучит типично для шаблона, используемого для определения, вошел ли пользователь в систему или нет), то рассмотрите одну из следующих альтернатив:
Периодически (возможно, каждые 30 секунд) вставляйте / обновляйте поле, подобное метке времени, в базе данных, чтобы указать, как недавно приложение было в сети. Другие приложения могут проверять эти временные метки, чтобы определить, как недавно другое приложение было в сети ... если значение находится в течение последних 30 секунд, другое приложение все еще работает в режиме онлайн.
Как справедливо предположил Вудхендж, создайте отдельный процесс (в идеале сервис) для мониторинга состояния основного приложения. Службы Windows можно настроить на автоматический перезапуск в случае сбоя службы. Этот процесс мониторинга затем выдаст временные метки в базу данных.
Обратите внимание, что оба приведенных выше предложения решают реальную проблему (обнаружение доступа приложений к базе данных), даже не оставляя базу данных в «несовместимом состоянии» (вышеупомянутый флаг равен «Y», когда приложение действительно мертво и флаг должен быть "N").