Win32/C++ 的关闭异常处理
我有一个可以很好地处理异常的流程。它调用：
_set_se_translator(exception_trans_func);
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit
每当发生异常时，都会调用其中一个处理程序，为我创建故障转储。生活是美好的。
一个客户站点除外。当他们关闭进程时，由于某种原因，出现了一个未通过这些调用路由的异常，并且他们收到错误：
“0x101ba9df”处的指令引用了“0x00000004”处的内存。内存无法被“读取”。单击“确定”终止...”
x000000004 的内存引用看起来可能是一个空指针。查看该地址似乎是一个全局 STL 对象的析构函数（可能在 CRT 的 initterm 调用中，其中全局变量已清理）。
现在我有点卡住了，因为我无法获取诊断转储和调用堆栈并确切地了解发生了什么。所以......
为什么不通过异常进行路由。上面的处理程序，而不是显示给用户？
有没有办法隐藏该对话框（因为此时没有造成任何损害）？
有没有办法追踪根本错误
？
I have a process that handles exceptions great. It calls:
_set_se_translator(exception_trans_func);
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit
Anytime an exception happens, one of the handlers is called which creates a crash dump for me. Life is good.
Except at one customer site. When they shutdown the process, there is an exception that isn't routed through these calls for some reason and they get the error:
The instruction at "0x101ba9df" referenced memory at "0x00000004". The memory could not be "read". Click OK to terminate...."
The memory reference of x000000004 looks like it's probably a null pointer. And looking at that address appears to be a global STL object's destructor (probably in the CRT's initterm call where globals are cleaned up).
Right now I'm kind of stuck though since I can't get a diagnostic dump and call stack and see exactly what is going on. So....
Why isn't the exception being routed through the above handlers, and instead being shown to the user?
Is there any way to hide that dialog (since no harm is being done at that point)?
And is there a way to track down the root error?
Thanks for any ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
他们运行什么操作系统？
之类的内容设置错误模式，
我假设您正在使用
::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);以确保 Windows 不会跳入其自己的错误处理？
What operating system are they running?
I assume you're setting the error mode using something like
::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);to make sure that windows isn't jumping in with its own error handling?
这听起来像是 CRT 在某些代码周围放置了 SEH try/catch 块（无法正确编写，Markdown 启动），并捕获异常以显示消息，因此您永远不会最终调用 未处理异常代码路径。您可能需要对 CRT 进行一些黑客攻击才能弄清楚发生了什么。
This sounds like the CRT has put an SEH try/catch block (can't write it properly, Markdown kicks in) around some piece of code, and is catching the exception to display the message, so you never end up calling the unhandled exception code path. You might have to do some CRT hacking to figure out what's happening.
可能是在程序关闭时销毁全局变量期间正在执行 STL 代码，并且可能（取决于您使用的 STL 版本）它所需的一些全局变量已经被销毁。
我在 VS2008 的 STL 中见过这个。有一些 STL 锁对象是在启动期间通过文件级静态创建的。
您在错误处理函数中使用 STL 吗？可能是其中一个在程序关闭后期关闭并导致了问题。
It could be that STL code is being executed during the destruction of global variables at program shutdown time and perhaps (depending on the version of STL that you're using) some global variables that it requires have already been destroyed.
I've seen this with VS2008's STL. There are some STL lock objects that are created via a file level static during start up.
Are you using STL in your error handler functions? It could be that one of these is going off late in program shutdown and causing the problem.