在 Win7 64 位上因未处理的第一次机会异常而崩溃（在 XP 32 位、Linux 64 位上没有问题）

Posted 2023-02-16

【中文标题】在 Win7 64 位上因未处理的第一次机会异常而崩溃（在 XP 32 位、Linux 64 位上没有问题）

【英文标题】：Crash over unhandled first chance exception on Win7 64bit (no issue on XP 32bit, Linux 64bit)

【发布时间】：2013-02-15 14:18:58

【问题描述】：

我在 Visual Studio Express 2010 下使用 C++ 编写 OpenGL 程序时遇到了一个奇怪的问题。 我使用：Windows 7 64 位，OpenGL 4.x 我的伙伴使用：Windows XP 32bit、Visual Studio Express 2010、OpenGl 2.x

到目前为止，我们只是为我们的模型绘制了顶点，并且它在两个系统上都可以正常工作（我知道，我知道：已弃用，但我们仍然是初学者）。现在他包含了一个库来导入 3d 网格并制作动画。对他来说一切都很好，但我明白了

Ant Simulation.exe 中 0x0055f838 处的第一次机会异常：0xC0000005：访问冲突读取位置 0x00bb0000。 Ant Simulation.exe 中 0x0055f838 处未处理的异常：0xC0000005：访问冲突读取位置 0x00bb0000。

使用调试器，我将问题追溯到该行

glDrawArrays(GL_QUADS,0,n_data);

我试图捕捉代码，但没有任何触发。很奇怪，昨天我可以用调试器在这条线上重复 2-3 次，直到它崩溃，今天它直接崩溃了。我昨天检查了 n_data 每次都是一样的。如果我在 Windows 中执行 *.exe，它会崩溃（下面的错误代码）。当我的伙伴向我发送他的 *.exe 时，它​​通常不起作用，但我可以启动它 1 次。我在其他窗口上重现了该错误。我们在 Linux 64bit 上试过，没有问题。我尝试在兼容模式下运行它，但问题仍然存在（仍然崩溃）。

我四处搜索，发现了这个：https://blogs.msdn.com/b/debugger/archive/2010/05/12/visual-studio-debugger-fails-to-catch-unhandled-exception-for-a-windows-form-or-wpf-application.aspx?Redirected=true

不确定我是否理解正确。有一个我无法捕获但会杀死应用程序的异常 - 但为什么其他系统没有出现此异常的问题？

我尝试按照链接中描述的方式解决它，但似乎在 VS Express 中我没有抛出第一次机会异常的菜单。我会尝试获得 VS 2012，但我还是想知道：这是完全 Windows 的事情，还是我的代码有问题导致崩溃（如链接中的一个 cmets 中所建议的那样）？我也非常感谢您解释实际发生的事情......

我在运行 *.exe 时遇到的错误：

问题事件名称：APPCRASH 应用程序名称：Ant Simulation.exe 应用程序版本：0.0.0.0 申请时间戳：511d99a3 故障模块名称：StackHash_0a9e 故障模块版本：0.0.0.0 故障模块时间戳：00000000 异常代码：c0000005 异常偏移量：0037f278 操作系统版本：6.1.7601.2.1.0.256.48 区域设置 ID：1031 附加信息 1：0a9e 附加信息 2：0a9e372d3b4ad19135b953a78882e789 附加信息 3：0a9e 附加信息 4：0a9e372d3b4ad19135b953a78882e789

【参考方案1】：

Windows 中的“第一次机会异常”不是 C++ 异常，它意味着运行时系统检测到程序的非法行为，例如取消引用无效指针。事实上，“访问冲突读取位置 0x00bb0000”非常表明这就是正在发生的事情。

取消对无效指针的引用不一定会在不同的系统上或什至在同一台机器上的不同运行上导致相同的行为：有关更多信息，请参阅C code crashes in Windows, but not in Linux 之类的问题。在这种情况下，错误似乎发生在 GL 实现内部，但这可能是由于早期的应用程序代码提供了错误信息。

检查所有启用的顶点数组是否至少具有n_data 元素。 （要特别注意确保它们不只有n_data - 1 元素，并且n_data 包含您期望的值。）您还应该检查您之前传递给GL 函数的任何指针是否有效。还有更多的 GL 状态需要检查，但这是我的第一个猜测。

【讨论】：

感谢您的快速响应。我在找它。如果我找到它，我会提供反馈。到目前为止，当我只加载静态图像时，它可以工作，这表明您的猜测是正确的。

-1 假设这是 OpenGL 的错，而不是 OP。这看起来像是发生了明显的堆溢出，并且它更有可能出现在 OPs 代码中，而不是经过代码审查且相对稳定的 OpenGL 库中

我并不是说这是 OpenGL 的错，甚至不是特定的 GL 实现。违反 OpenGL 前提条件（这是应用程序的错误）导致 OpenGL 调用内部崩溃是很常见的。将无效指针传递给 GL 函数是实现此目的最明显的方法，但也有更微妙的方法。我将编辑答案以使其更清楚。

@SecurityMatt BTW，作为一名 GPU 驱动程序作者，我发现您将 GL 实现描述为“经过代码审查且相对稳定”有点幼稚。

@DanHulme：在所有代码中，如果您违反其先决条件之一，它就会中断，这是司空见惯的。我并不是说 OpenGL 没有错误。我只是说，您需要始终假设这是您的错误，直到您毫无疑问地证明这是其他人的错误，因此将 OP 提供的信息如此之少归咎于 OpenGL 似乎为时过早。