Exceptions and Access Violations in Paint Events on Windows

After executing some new code, my C ++ application began to behave strangely (incorrect or incomplete screen updates, sometimes no screen updates). After some time, it became clear that the new code is causing an access violation. Oddly enough, the application just continues to work (but with incorrect screen updates).

At first we thought that the problem was caused by the try-catch (...) construct (put there by an overactive ex-colleague), but after a few hours (carefully checking the call stacks, adding a lot of breakpoints, ...) we found out that if there is an access violation in the drawing event, Windows catches it and just continues to run the application.

  • Is this normal behavior?
  • Is it normal for Windows to catch exceptions / errors during a paint event?
  • Is there any way to disable this? (if not, this would mean that we should always run in the debugger, and all exceptions are included when testing our code).

EDIT:

  • XP correctly crashes (desired behavior after access violation)
  • In Vista and Windows 7, the application continues to work
+4
source share
2 answers

This is a known bug. Check the fix. http://support.microsoft.com/kb/976038

+2
source

My immediate reaction is that it sounds like a resource leak, and it crashes when you no longer have the type of resource you need.

[I deleted the rest of the previous answer because, based on Patrick's comments and a small investigation, this is clearly not applicable to the problem. ]

Following Patrick's comment, I quickly tested and duplicated the behavior in Windows 7. I started with a really minimal program (the base program created by VS 2008 for the Win32 project), and all I added was a non-existent address. Of course, you will not find any signs that something bad has happened.

Just for a laugh, I quickly checked how to respond to this exception. For what it stands, it does not resume after an exception, it just grabs it and skips the rest of the code in the WM_PAINT handler.

I am a little versed in MSDN, but so far I have not found any documentation that explains how and why this happened, whether it can be disabled, and if so, how, or much more. I have to agree: this is really a serious problem - if I caused an access violation (no, it cannot happen!) I want the program to work as quickly and quickly as possible. Disguising an error (especially one as serious as access violation) is an impressively bad idea!

+2
source

Source: https://habr.com/ru/post/1310844/


All Articles