问题标签 [seh]

本文很好地概述了为什么结构化异常处理不好。有没有办法获得阻止服务器崩溃的稳健性，同时克服文章中提到的问题？

我有一个服务器软件，可以同时运行大约 400 个连接的用户。但如果发生崩溃，所有 400 个用户都会受到影响。我们添加了结构化异常处理并享受了一段时间的结果，但最终不得不将其删除，因为一些崩溃导致整个服务器挂起（这比让它崩溃并自行重启更糟糕）。

所以我们有这个：

• 使用 SEH：400 中只有 1 个用户在大多数崩溃中遇到问题
• 没有 SEH：如果任何用户发生崩溃，所有 400 都会受到影响。
• 但有时与 SEH：服务器挂起，所有 400 都受到影响，未来的用户会尝试连接。

我希望在离开函数之前设置一个 usererror 字符串，具体取决于函数中的返回码和变量。

我目前有：

是否可以使用 return RetType.FailedParse，然后在 finally 块中访问它？

这个问题更清楚地说明了这里描述的问题。我做了更多调查，发现堆栈展开没有发生在以下代码中：

我使用 VC6 SP5 编译器编译了这段代码，输出为“Wrapper constructor :: AddRef !!!” （即未调用在堆栈上构造的包装器对象的析构函数。这是预期的行为吗？还是 VC 编译器的错误？我可以使用一些编译器标志以便在这种情况下发生堆栈展开吗？

我发布了一个关于验证指针可访问性的问题。结论是要么使用 IsBadReadPtr 检查指针，要么使用 SEH 捕获异常（最好两者都不使用，并调试应用程序，但这不是这里的问题）。

据说 IsBadReadPtr 不好，因为除其他原因外，它会尝试读取指针，并会捕获任何异常。它可能会捕获堆栈保护页面异常，从而阻止它到达内存管理器，这应该扩大了堆栈。

如果我使用 SEH 并且只捕获 EXCEPTION_ACCESS_VIOLATION 异常，这会产生同样的问题吗？

另一件事：使用 SEH 的含义是什么？ 本文建议“编译器无法在受 SEH 保护的代码中执行流分析”。如果我在 __try 块中调用一个函数怎么样。编译器根本不会优化被调用的函数吗？

有没有办法在不削弱 SEH 的情况下摆脱 Win32 的“一大堆”模型？我希望能够在堆上分配堆栈帧，作为实现协程的一种方式。然而，我的代码目前依赖于 SEH，这篇文章，几页下来，说（关于异常处理程序的遍历，扫描，强调我的）：

在这个链遍历期间，操作系统对损坏的堆栈非常偏执。它检查所有链条目是否在堆栈的范围内。（这些界限也记录在 TEB 中）。操作系统还检查所有条目在堆栈上是否按升序排列。如果您违反这些规则，操作系统将认为堆栈已损坏并且将无法处理异常。这是 Win32 应用程序不能将其堆栈分成多个不相交的段作为处理堆栈溢出的创新技术的原因之一。

所以基本上，如果当前堆栈帧在“一个大堆栈”之外时发生异常，则该进程将立即终止。不理想的行为。

有没有人能够解决这个问题并在本机 Win32 应用程序中使用带有不相交堆栈的 SEH？此外，是否还有其他 Win32 特定的“陷阱”具有不相交的堆栈？

有人可以提供一些在 VB6 中实现 SEH 的例子吗？到目前为止我所看到的一切都是用 C++ 编写的

以下代码在 Windows 7 32bit 下运行时会出现严重故障：

但是，如果我在 Windows 7 64 位上尝试这个，我只是在输出窗口中得到这个：

Test.exe 中 0x13929384 处的第一次机会异常：0xC0000005：访问冲突写入位置 0x00000000。
Test.exe 中 0x77c6ee42 处的第一次机会异常：0xC0150010：被停用的激活上下文对于当前执行线程无效。

这是什么原因？我知道这是一个硬件异常（http://msdn.microsoft.com/en-us/library/aa363082.aspx），但是为什么在 32 位和 64 位下运行时会有差异？我该怎么做才能正确处理这些错误？因为它们确实应该被捕获和修复，而不是当前发生的情况，即 Windows 只是继续向应用程序发送消息并让它运行（因此用户和开发人员完全不知道实际发生了任何问题）。

更新： 我们的常规崩溃报告软件使用SetUnhandledExceptionFilter但不会在 x64 上调用 WndProc 内的硬件异常。有没有人有这方面的任何信息，或解决方法？

Update2： 我在 Microsoft Connect 上报告了这个问题：
https ://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-消息

每个 C++ 开发人员都应该了解结构化异常的哪些要点？

我正在尝试了解有关 Windows SEH 的更多信息。我的第一个测试程序给我带来了一些真正的麻烦。我查看了 msdn 文档，但我仍然不确定我有什么问题。尝试编译此程序时出现以下错误：

都在第 15 行。

谢谢。

这主要是出于好奇，但我一直在阅读有关 Visual Studio 在 C++try-catch构造中捕获 SEH 异常的历史。我一直在断言启用了 /GX 标志的旧版本 Visual Studio 会“有时”在 C++catch块中捕获结构化的 Win32 异常。

什么情况下Visual Studio 6.0 使用/GX 标志构建时会在下面的代码中进入catch 块？

在我自己使用 Visual Studio 6 + SP6 进行的简单测试中，程序执行会因未处理的异常而停止，并且永远不会打印“In catch”。然而，一些文章（比如这篇文章）让我相信进入catch区块是可能的。