views:

110

answers:

3

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
+2  A: 

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!

Jerry Coffin
The incorrect update is not the problem, the fact that the application keeps on running after an Access Violation in a WM_PAINT message is (at least on Vista)
Patrick
No, the program does not stop ! We tried exactly the same code as in your comment (except using 123 instead of 1 :-)): on XP it crashes, on Vista it doesn't crash.
Patrick
Jerry, glad we agree on this, +1. In the mean time I found an identical question (http://stackoverflow.com/questions/1487950/access-violation-in-wm-paint-not-caught). Unfortunately, no good answer yet. I'm currently investigating using VectoredExceptionHandling to solve this problem.
Patrick
A: 

Apparently, question has been asked before. See http://stackoverflow.com/questions/1487950/access-violation-in-wm-paint-not-caught

Patrick
+2  A: 

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

mljack
Indeed, that seems to be it. We will investigate this further and see how we can correctly solve this. Thanks for the tip.
Patrick