Beta2 can't catch exceptions?

[Tamas Demjen]

I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
Violation exceptions in unmanaged code.

To reproduce this, I created a minimal Win32 console application:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
int* p = 0;
try
{
*p = 0;
}
catch(...)
{
}
return 0;
}

When I compile and run this with VC++ 2003 or a Borland compiler, the
exception is caught silently as expected. With VC++ 2005 Beta 2, I get
the system dialog "X.exe has encountered a problem and needs to close.
[...] Debug / Send Error Report / Don't Send". Just like if the catch
block wasn't even there. It can't catch divide by zero either.

Am I missing something? C++ exception handling is turned on, and
catch(...) catches other C++ exceptions that I throw, such as throw
std::exception("!").

Tom

 

[Doug Harrison [MVP]]

I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
Violation exceptions in unmanaged code.

To reproduce this, I created a minimal Win32 console application:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
int* p = 0;
try
{
*p = 0;
}
catch(...)
{
}
return 0;
}

When I compile and run this with VC++ 2003 or a Borland compiler, the
exception is caught silently as expected. With VC++ 2005 Beta 2, I get
the system dialog "X.exe has encountered a problem and needs to close.
[...] Debug / Send Error Report / Don't Send". Just like if the catch
block wasn't even there. It can't catch divide by zero either.

Am I missing something? C++ exception handling is turned on, and
catch(...) catches other C++ exceptions that I throw, such as throw
std::exception("!").

Access violations aren't C++ exceptions. The short answer is that VC8
finally fixes this bug, and to restore the behavior you're expecting, you
need to specify /EHa instead of /GX or /EHsc. That's actually been required
for several versions now in order to consistently catch untranslated SEs in
catch(...) in release builds. For much more on this, and to understand why
it's generally a bad idea to want to catch SEs in catch(...), see:

http://members.cox.net/doug_web/eh.htm

 

[adebaene]

I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
Violation exceptions in unmanaged code.

To reproduce this, I created a minimal Win32 console application:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
int* p = 0;
try
{
*p = 0;
}
catch(...)
{
}
return 0;
}

When I compile and run this with VC++ 2003 or a Borland compiler, the
exception is caught silently as expected. With VC++ 2005 Beta 2, I get
the system dialog "X.exe has encountered a problem and needs to close.
[...] Debug / Send Error Report / Don't Send". Just like if the catch
block wasn't even there. It can't catch divide by zero either.

Am I missing something? C++ exception handling is turned on, and
catch(...) catches other C++ exceptions that I throw, such as throw
std::exception("!")

To complete what Doug has said, it's a *very* bad idea to try to ignore
silently an Access Violation : An AV is basically a bug in your code
that may put your program in an undetefined state, and trying to
continue to run in those conditions could be dangerous.

That's why it's generally better to let your soft die when an AV is
raised, and do a post-mortem debugging - unless your app is
specifically designed so that different components are really isolated
one from the other and you're certain the AV hasn't corrupted anything.

Arnaud
MVP - VC

 

[Tamas Demjen]

Access violations aren't C++ exceptions. The short answer is that VC8
finally fixes this bug, and to restore the behavior you're expecting, you
need to specify /EHa instead of /GX or /EHsc. That's actually been required
for several versions now in order to consistently catch untranslated SEs in
catch(...) in release builds. For much more on this, and to understand why
it's generally a bad idea to want to catch SEs in catch(...), see:

http://members.cox.net/doug_web/eh.htm

Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh. For example, a crash in the OCR enigne will
cause all text entities to be lost for a particular page in the *worst*
case. Those errors are caught in the catch and are logged, so there is
warning about it. If it's an application level problem, then maybe items
will be missing from a list box, or similar, but the user will still be
able to save the document before exiting. I don't blindly catch AVs,
without letting the user know about them. Either a dialog box is popped
up, or the error is logged, or both.

Anyway, I understand the concept, it was a very useful feedback. I
appreciate it.

Tom

 

[Arnaud Debaene]

I see that it can be dangerous, but risking a crash and total data
loss for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh. For example, a crash in the OCR enigne will
cause all text entities to be lost for a particular page in the
*worst* case.

No : A rogue pointer writing may do anything to your app : in the *worst*
case, you may corrupt the heap manager, TEB, handle descriptor or any other
vital data structure.

Arnaud
MVP - VC

 

[William DePalo [MVP VC++]]

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh. For example, a crash in the OCR enigne will cause
all text entities to be lost for a particular page in the *worst* case.
Those errors are caught in the catch and are logged, so there is warning
about it. If it's an application level problem, then maybe items will be
missing from a list box, or similar, but the user will still be able to
save the document before exiting. I don't blindly catch AVs, without
letting the user know about them. Either a dialog box is popped up, or the
error is logged, or both.

FWIW: Where structured exceptions and C++ are concerned, Doug's essay sums
it up much better than I could. That said, however, in development, or
perhaps in production where you are faced with a pernicious but elusive SE
raised by some component for which you don't have source, you might have a
valid reason to "translate" the SE to a C++ typed exception so that you can
handle it as you describe above.

This thread shows one way to do that:

http://groups.google.com/group/micr...e+author:depalo&rnum=1&hl=en#d8aa89b74adeeeab

Regards,
Will

 

[Tamas Demjen]

No : A rogue pointer writing may do anything to your app : in the *worst*
case, you may corrupt the heap manager, TEB, handle descriptor or any other
vital data structure.

I realize the danger, no question about that, that's why I never want a
completely silent handling of AVs. In fact, I want an annoying or scary
message that makes the customer report it to us.

However, I thought a rogue pointer would either cause corruption in the
heap/stack *without* an AV, which remains completely unnoticed until
later in time, or it causes an AV, in which case there is no corruption
whatsoever (the AV itself prevents any corruption). So while an AV is a
sign of programming error that may cause corruption, at the time of the
AV it doesn't.

In my practice, these uncaught exceptions are often either AV due to
NULL pointer dereference, or division by 0 due to unknown resolution
value in an image, or similar programming erros, which often are not
enough for an immediate crash that causes all data to be lost.

I see the danger, and it's a good idea to rethink how we handle access
violations.

Probably the ideal way of handling these errors would be the following:
1. save all data to a recovery file
2. show an error message to the customer that a critical error occured
and the author should be notified
3. exit the application immedaitely
4. the next time the application launches, it recognizes the recovery
data and offers the user for loading/recovering

In an embedded system or mission critical system, maybe log the error,
reboot, and start an auto-recovery.

Tom

 

[Tamas Demjen]

However, I thought a rogue pointer would either cause corruption in the
heap/stack *without* an AV, which remains completely unnoticed until
later in time, or it causes an AV, in which case there is no corruption
whatsoever (the AV itself prevents any corruption). So while an AV is a
sign of programming error that may cause corruption, at the time of the
AV it doesn't.

Actually an AV can be a result of a previously unnoticed stack/heap
corruption, and the memory may already be corrupt at that time. It makes
sense to be cautious...

Tom

 

[Doug Harrison [MVP]]

Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.

Which is literally about as long as I've been trying to get this bug fixed.

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh. For example, a crash in the OCR enigne will
cause all text entities to be lost for a particular page in the *worst*
case. Those errors are caught in the catch and are logged, so there is
warning about it. If it's an application level problem, then maybe items
will be missing from a list box, or similar, but the user will still be
able to save the document before exiting. I don't blindly catch AVs,
without letting the user know about them. Either a dialog box is popped
up, or the error is logged, or both.

In that case, I hope you don't overwrite an existing (good) file with the
potentially corrupted data, and I hope you warn the user the file you do
save may contain corrupted data. If you allow the program to continue, you
should also disclose that you have no idea what state it's in, so the user
necessarily proceeds at his own risk and should be prepared to run into
other problems later on that may or may not have anything to do with the
prior bug swallowing event, which, in this day and age, may have opened up
unspeakable security holes.

Anyway, I understand the concept, it was a very useful feedback. I
appreciate it.

You're welcome. Many people have resisted the ideas I wrote about far more
vehemently than you.

 

[Tamas Demjen]

You're welcome. Many people have resisted the ideas I wrote about far more
vehemently than you.

I'm convinced. It made me think for a while, and yes, initially I had
mixed feelings about it. AVs seemed innocent enough in the past, and
customers always took it as serious as a crash, reporting it right away.
I just have no way of knowing how many times I silenced an AV. ;-)

Tom

 

[Peter Koch Larsen]

Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh.

Do you call dereferencing a null-pointer insignificant?
For example, a crash in the OCR enigne will

cause all text entities to be lost for a particular page in the *worst*
case. Those errors are caught in the catch and are logged, so there is
warning about it.

Well.. if you are using software, that dereferences null pointers, all bets
are off, arent they?

If it's an application level problem, then maybe items

will be missing from a list box, or similar, but the user will still be
able to save the document before exiting. I don't blindly catch AVs,
without letting the user know about them. Either a dialog box is popped
up, or the error is logged, or both.

Anyway, I understand the concept, it was a very useful feedback. I
appreciate it.

My recommendation is that you - if you really, really have to use such
unreliable software components, at least run them in another process.

Tom

/Peter

 

[Andre Kaufmann]

I'm convinced. It made me think for a while, and yes, initially I had
mixed feelings about it. AVs seemed innocent enough in the past, and
customers always took it as serious as a crash, reporting it right away.
I just have no way of knowing how many times I silenced an AV. ;-)

The coolest thing about how Windows handles access violations are that
it writes dump files. Windows will send them to Microsoft / the developer.
The dump file may be loaded directly in the VC IDE and enables the
developer to debug the application and the cause of the access violation.

Another cool thing is that Windows Vista task manager now has a context
menu "Write dump file". So that the state of a running application
showing errors, but no crashs, may be analyzed in the IDE.

Andre