开发者

Exceptions and Access Violations in Paint events in Windows

开发者 https://www.devze.com 2022-12-31 07:33 出处:网络
After executing some new code, my C++ application started to behave strange (incorrect or incomplete screen updates, sometimes no screen updates at all).

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(...)" cons开发者_StackOverflow社区truction (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


It's a known defect. Check the hotfix. http://support.microsoft.com/kb/976038


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!

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号