0 .net c# wpf multithreading process
我正在开发一个 WPF C# 应用程序，无论如何都需要在每次退出时运行一些清理代码。Dotnet 提供了一些致命的崩溃处理程序，但如果我通过调试器或任务管理器终止应用程序，它们不会被调用。
我尝试为此寻找某种最佳实践，但一无所获。我能想到的最好办法是尝试创建一个单独的进程来监视主进程崩溃。如果我想将所有内容打包为单个可移植 .exe 并运行它，我认为该解决方案不起作用。据我了解，当主线程崩溃时，从主线程产生的任何线程都将被销毁。如果我想生成一个新进程，而不是启动一个单独的线程，我认为我不能将其打包到我的 .exe 中。
所以我真的不确定我在这里有什么办法。有人能指出我正确的方向吗？
简而言之，在 100% 的情况下，您绝对无法在终止时强制终止进程。想一想。这并不是桌面应用程序所独有的。浏览器应用程序有这个问题。服务器应用程序有它。电源可能会断电。房间可能会爆炸。实际上没有办法保证应用程序达到上限之前会发生某些事情。
但即使您不能保证在退出之前执行清理操作，情况也并非毫无希望。本质上，您需要将应用程序的状态保存在某个持久的位置 - 这可以是本地的或在线的，具体取决于您的应用程序。每次你开始一些关键的事情时，你都会记录它正在开始。当它成功完成时，您会记录它成功（或者删除存在未完成任务的记录）。
现在假设发生了事故。两种可能性——
(1) 如果您是在线应用程序，并且在线保存此状态，那么您的服务器可能会定期 ping 您的应用程序，直到任务完成。如果它没有从您的应用程序收到成功的 ping，它可以假设该应用程序已死亡，并清理所有必要的内容。
(2) 如果您完全离线，那么您可能只能在应用程序重新启动时进行清理。此时，您检查最后状态的记录，查看它是否打开/不完整，如果是，则进行清理。
编辑回应评论 -
根据您使用 Windows API 更改系统并希望确保其正确恢复所做的工作，听起来在线解决方案不起作用。
我认为你启动一个单独的进程作为你的监视器的想法可能是你最好的选择。您需要它是一个单一的可移植 EXE，但仍然应该能够通过 运行相同的进程Process.Start，但通过命令行参数将其置于监视器“模式”中。您可以获取进程路径Assembly.GetExecutingAssembly，然后启动第二个实例以将其置于该模式。
但这仍然无法帮助您避免系统崩溃。如果您想要最高级别的稳健性，您可能需要将应用程序安装在启动文件夹中，以便它可以在重新启动时检查并处理此故障模式。在这种情况下，您需要不断地将进度记录到磁盘的某个位置，以便您的应用程序知道在启动时发生故障时如何正确回滚。