当显示“您已崩溃，我们很抱歉...”时，完全停止应用程序弹出窗口
如果我的应用程序崩溃，我会拦截崩溃（使用函数 SetUnhandledExceptionFilter）。在我的崩溃处理程序中，我创建一个小型转储文件，并通知用户他的应用程序已崩溃。此通知是通过带有 MB_TASKMODAL 标志的 MessageBox 完成的，因此应用程序的其余部分将被阻止。
不幸的是，这并不会阻止重绘和计时器消息的处理。特别是计时器消息非常烦人，因为它们可能会执行各种中间操作（取决于我的应用程序中加载了哪些插件），甚至保存到备份文件等。
有没有一种简单的方法可以防止Windows发送重绘和计时器消息（同时显示“你已经崩溃”弹出窗口）？
另一种方法是使用一些全局变量，该变量将在我的崩溃处理程序中设置，并在我的应用程序中执行某些逻辑的每个位置进行检查，但这对我来说似乎是一个相当“肮脏”且不灵活的解决方案。 难道就没有更简单的方法吗？ （并且只需确保消息框的消息循环仅处理消息框消息而不处理其他窗口的消息）。
谢谢 帕特里克
If my application crashes, I intercept the crash (using the function SetUnhandledExceptionFilter). In my crash handler, I create a mini dump file, and notify the user that his application has crashed. This notification is done via a MessageBox with the flag MB_TASKMODAL so the rest of the application is blocked.
Unfortunately, that doesn't block the handling of repaint- and timer-messages. Especially the timer messagesare very annoying since they may execute all kinds of intermediate actions (depending on which plug-ins are loaded in my application), even saves to backup files, etc.
Is there an easy way to prevent Windows from sending repaint- and timer-messages(while showing the "you have crashed" popup)?
An alternative would be to use some global variable, that would be set in my crash handler, and checked in every place in my application where I would execute some logic, but this seems a rather 'dirty' and non-flexible solution to me.
Isn't there an easier way? (and only making sure that the message loop of the message box only handles message box messages and no messages of other windows).
Thanx
Patrick
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无法阻止 Windows 发送重绘和计时器消息。毕竟，您确实希望消息框本身也被重新绘制。
模态消息框会阻止其显示的 UI 线程的执行。这仍然会使您生成的后台线程或您在线程池上计划的工作项继续运行。
您已经获取了小型转储并且知道您的应用程序已崩溃。为什么要保留该进程并从其中显示消息框？您显然不希望应用程序能够恢复，因此此时合理的做法是启动一个小帮助程序进程，该进程将向用户显示消息并终止崩溃的应用程序。
it's not possible to prevent Windows from sending repaint and timer messages. After all, you do want you message box itself to be repainted as well.
a modal message box blocks the execution of the UI thread it was shown on. This still leaves background threads you spawned or work items you scheduled on the thread pool running.
you've taken the mini-dump and you know your app has crashed. Why do you want to keep the process around and show the message box from inside it? You obviously don't expect the app to be able to recover, so the reasonable thing at that point is to kick off a small helper process that would show the message to the user and terminate the crashing application.
只有一种方法可以安全地显示崩溃对话框 - 在专门为其创建的单独线程上。在崩溃的线程上创建对话框将导致各种副作用（正如您所注意到的），因为它将泵送和分派发往该线程上的窗口的已发布和已发送消息。
问题是 - 从崩溃处理程序中创建对话框是否安全？我可以想到几种可能出现问题的场景 - 特别是如果涉及全局加载器锁（即，由于加载 dll 导致对象初始化内部某处发生崩溃）。
因此，在应用程序启动时创建线程并使其处于待机状态可能是个好主意。
There is only one way to show a crash dialog safely - on a seperate thread created specifically for it. Creating a dialog on a crashed thread will cause all sorts of side effects (as you have noticed) as it will pump and dispatch both posted and sent messages destined for windows on that thread.
The question is - is it safe to create a dialog from within a crash handler? I can think of several scenarios where it could be problematic - especially if the global loader lock has been involved (i.e. a crash happens somewhere inside object initialization caused by a dll being loaded).
So its probably a good idea to create the thread on app startup and have it on standby.