Windows 中 Paint 事件中的异常和访问冲突
执行一些新代码后，我的 C++ 应用程序开始表现奇怪（屏幕更新不正确或不完整，有时根本没有屏幕更新）。 一段时间后，我们发现新代码导致了访问冲突。奇怪的是，应用程序只是继续运行（但屏幕更新不正确）。
起初我们认为问题是由“try-catch(...)”结构引起的（由一位过度活跃的前同事放在那里），但几个小时后（仔细检查调用堆栈，添加许多断点，... ）我们发现，如果绘制事件中存在访问冲突，Windows 会捕获它，然后继续运行应用程序。
- 这是正常行为吗？
- Windows 在绘制事件期间捕获异常/错误是否正常？
- 有办法禁用这个吗？ （如果没有，这意味着我们必须始终在调试器中运行，并在测试代码时启用所有异常）。
编辑：
- 在 XP 上正确崩溃（访问冲突后所需的行为）
- 在 Vista 和 Windows 7 上应用程序继续运行
After executing some new code, my C++ application started to behave strange (incorrect or incomplete screen updates, sometimes no screen updates at all).
After a while we found out that the new code is causing an Access Violation. Strange enough, the application simply keeps on running (but with the incorrect screen updates).
At first we thought the problem was caused by a "try-catch(...)" construction (put there by an overactive ex-colleague), but several hours later (carefully inspecting the call stacks, adding many breakpoints, ...) we found out that if there's an Access Violation in a paint event, Windows catches it, and simply continues running the application.
- Is this normal behavior?
- Is it normal that Windows catches exceptions/errors during a paint event?
- Is there a way to disable this? (if not, it would mean that we have to always run in the debugger with all exceptions enabled while testing our code).
EDIT:
- On XP the correctly crashes (the wanted behavior after an Access Violation)
- On Vista and Windows 7 the application keeps on running
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个已知的缺陷。检查修补程序。 http://support.microsoft.com/kb/976038
It's a known defect. Check the hotfix. http://support.microsoft.com/kb/976038
我的第一反应是，这听起来像是资源泄漏，当您不再拥有正确类型的可用资源时就会发生故障。
[我删除了之前答案的其余部分，因为根据帕特里克的评论和一些调查，它显然不适用于当前的问题。 ]
根据 Patrick 的评论，我做了一个快速测试并复制了 Windows 7 下的行为。我从一个真正的最小程序（VS 2008 为 Win32 项目生成的基本程序）开始， >我添加的所有内容都是对不存在的地址的写入。果然，你根本看不到任何不好的事情发生的迹象。
只是为了笑一下，我做了一个快速测试，看看它对异常的反应如何。无论如何，它不会在异常发生后恢复，它只是捕获异常并跳过 WM_PAINT 处理程序中的其余代码。
我在 MSDN 上做了一些查找，但到目前为止还没有找到任何文档来解释这是如何或为何发生的、是否可以禁用它、如果可以禁用如何禁用或其他任何内容。但我必须同意：这确实是一个严重的问题 - 如果我造成了访问冲突（不，不可能发生！），我希望程序尽可能彻底、快速地崩溃。掩盖错误（尤其是像访问冲突这样严重的错误）是一个非常糟糕的主意！
My immediate reaction is that this sounds like a resource leak, with the failure occurring when you no longer have a resource of the correct kind available.
[ I've deleted the rest of the previous answer, because based upon Patrick's comments and a bit of investigation, it was clearly inapplicable to the problem at hand. ]
Following up to Patrick's comment, I did a quick test and duplicated the behavior under Windows 7. I started with a truly minimal program (the basic program generated by VS 2008 for a Win32 project) and all I added was a write to a nonexistent address. Sure enough, you get no sign of anything bad having happened at all.
Just for grins I did a quick test to see exactly how it's reacting to the exception. For what it's worth, it's not resuming after the exception, it's just trapping it and skipping the remainder of the code in the WM_PAINT handler.
I've done a bit of looking in MSDN, but so far haven't found any documentation that explains how or why this came about, whether it can be disabled, and if so how, or much of anything else. I have to agree though: this really as a serious problem -- if I've caused an access violation (no, couldn't happen!) I want the program to crash as thoroughly and quickly as possible. Masking a bug (especially one as serious as an access violation) is a spectacularly bad idea!