程序崩溃后如何挂起所有线程?

发布于 2024-09-15 07:35:23 字数 466 浏览 10 评论 0原文

我有一个未处理的异常处理程序。它显示了一个漂亮的 GUI,并允许用户发送错误报告。用户甚至可以留下他们的姓名和电话号码等信息,我们的支持部门会给他们回电。效果好,看起来不错,让顾客不那么生气。无论如何,理论上来说。

问题是我的应用程序使用后台线程,并且线程似乎并不关心是否在 GUI 线程上抛出异常(这是有道理的),并且只是继续其工作。如果用户让我的自定义异常处理程序窗口保持打开足够长的时间,最终会导致弹出 WER 对话框,使其看起来像是错误处理程序本身崩溃了。

我无权访问异常处理程序范围内的线程对象,因此无法挂起它们。让线程对象全局可访问也不是一个解决方案。我现在的解决方法是在异常处理程序中使用类似 Globals.Crashed = true; 的内容,并让我的线程方法在每次循环迭代时检查该属性。虽然不完美,但可以最大程度地减少损失。

有谁知道一种不太hacky的方法?我的做法有错吗?我是否必须像 WER 那样启动一个外部程序来暂停主程序并显示错误 UI?

I have an unhandled exception handler. It shows a nice GUI and allows users to send an error report. Users can even leave their name and phone number and things, and our support department calls them back. Works well, looks good, makes customers less angry. In theory, anyway.

The problem is that my application uses background threads, and the threads don't seem to care if an exception was thrown on, say, the GUI thread (which makes sense), and just continue their work. That eventually results in a WER dialog poping up if the user lets my custom exception handler window stay open long enough, making it look like the error handler itself crashed.

I don't have access to the thread objects in the scope of the exception handler, so I can't suspend them. Making the thread objects globally accessible is not a solution either. My workaround for now is to use something like Globals.Crashed = true; in my exception handler, and to have my thread methods check that property at every loop iteration. Not perfect, but it minimizes the damage.

Does anyone know a less-hacky method? Is my approach wrong? Do I have to do it like WER does and launch an external program that suspends the main program and shows the error UI?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

后知后觉 2024-09-22 07:35:23

如果您有未处理的未知异常,您可以假设发生了任何事情,并且您的程序可能无法完成最简单的事情。例如,考虑它已经消耗了所有可用内存的情况 - 那么您也将无法发送错误报告,因为它可能需要分配内存。

一个好的方法是编写一个单独的小应用程序来仅执行错误报告。该应用程序可以从文件中获取要报告的详细信息。这样,您的未知异常处理程序将:

  • 将信息转储到临时目录中的文件中。
  • 使用文件名作为参数启动错误报告应用程序。
  • 在失败的进程做出愚蠢的事情之前终止它。

错误报告应用程序应删除临时文件。

If you have an unhandled, unknown exception, you can assume that ANYTHING has happend and that your program might fail to do even the most simple thing. Consider e.g. the case that it has consumed all available memory - then you won't be able to send the error report either, because it probably requires memory to be allocated.

A good approach is to write a separate small application that just does the error reporting. That application can pick up the details to report from a file. That way your unknown exception handler would:

  • Dump the info to a file in the temp directory.
  • Start the error reporting app with the file name as an argument.
  • Terminate the failing process, before it does something stupid.

The temp file should be removed by the error reporting app.

薄荷梦 2024-09-22 07:35:23

您可以跟踪全局 Collection 对象中的所有线程,以便当您的处理程序执行时,它可以简单地迭代集合对象并中止那里的线程。

You could track all your threads in a global Collection object, so that when your handler executes, it could simply iterate through the collection object and abort the threads there.

浮萍、无处依 2024-09-22 07:35:23

看看这个问题中的代码,Suspend Process in C#,您需要调整它,以便不挂起你的 GUI 线程和任何不是你启动的后台线程,但它应该可以解决问题。

然而,更好的选择是尝试将错误报告 GUI 作为单独的进程启动,向其传递任何所需的信息,然后从未处理的异常处理程序中终止原始进程,而不是允许任何内容在可能损坏的状态下运行。

Take a look at the code in this question, Suspend Process in C#, you'll need to tweak it so as to not suspend your GUI thread and any that aren't background ones you've started, but it should do the trick.

The better option, however, is to try and launch your error report GUI as a separate process, passing any required information to it, and then kill the original process from your unhandled exception handler, rather than allowing anything to run in a potentially corrupt state.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文