Filtering 'Access Violation' error inside a try-catch block

Discussion:

(too old to reply)

Sanje²v

2009-10-12 00:22:11 UTC

Hi to all,
I have enabled 'SEH with Exceptions' options in my VC++ 2008 Express
compiler and would like to filter 'Access violation' exception in a
code (unmanaged) guarded by a try-catch block. How can I know that the
exception raised in a catch block is due to access voilation? I can
use 'GetExceptionCode() only inside __try-__except block but if I use
it instead of try-catch I will have to change everything to __try-
__except. Is there any disadvantages to this? Can't I just filter the
required exception in a try-catch block instead?

-Sanjeev

Alexander Grigoriev

2009-10-12 02:13:00 UTC

Permalink

Why do you want to catch access violation? You can't use it to validate
memory addresses.

Post by SanjeÂ²v
Hi to all,
I have enabled 'SEH with Exceptions' options in my VC++ 2008 Express
compiler and would like to filter 'Access violation' exception in a
code (unmanaged) guarded by a try-catch block. How can I know that the
exception raised in a catch block is due to access voilation? I can
use 'GetExceptionCode() only inside __try-__except block but if I use
it instead of try-catch I will have to change everything to __try-
__except. Is there any disadvantages to this? Can't I just filter the
required exception in a try-catch block instead?
-Sanjeev

legalize+ (Richard)

2009-10-12 02:26:33 UTC

Permalink

[Please do not mail me a copy of your followup]

Post by Alexander Grigoriev
Why do you want to catch access violation? You can't use it to validate
memory addresses.

About the only useful thing I can think of is to generate a minidump
for bug reporting.

Once you've chased down through a bogus pointer, all bets are usually
off.

--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Ben Voigt [C++ MVP]

2009-10-12 05:56:47 UTC

Permalink

Yes, using _set_se_translator

But I'd just use __try/__except for that. You don't have to change all your
try/catch. You just can't put both in the same function, it's legal to put
__try/__except in a function that calls another function which uses
try/catch.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4498 (20091011) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Sanje²v

2009-10-13 02:42:06 UTC

Permalink

Though why I would wanna catch an access violation, isn't related to
the problem. Here's why, anyway:

My program allows third-party dlls to be loaded into its address space
as plugins. But I surely wouldn't want my application to crash due to
a faulty third-party dll doing something stupid like dereferencing a
NULL pointer. So, I thought why not guard the point where my
application calls functions in the third-party dll and if an access
violation is thrown, just unload the faulty dll and notify the user
that a problem has occurred due to a plugin and the program has
downgraded? I only want to catch an access violation error and allow
my application to crash (default behaviour) if other serious errors
occur.

A 'try/catch(...)' willl catch an access violation error but is not
able to identify if its really an access violation or any other error.
Is __try/__except only the way out of this?

-Sanjeev

Alexander Grigoriev

2009-10-13 05:07:47 UTC

Permalink

Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

Post by SanjeÂ²v
Though why I would wanna catch an access violation, isn't related to
My program allows third-party dlls to be loaded into its address space
as plugins. But I surely wouldn't want my application to crash due to
a faulty third-party dll doing something stupid like dereferencing a
NULL pointer. So, I thought why not guard the point where my
application calls functions in the third-party dll and if an access
violation is thrown, just unload the faulty dll and notify the user
that a problem has occurred due to a plugin and the program has
downgraded? I only want to catch an access violation error and allow
my application to crash (default behaviour) if other serious errors
occur.
A 'try/catch(...)' willl catch an access violation error but is not
able to identify if its really an access violation or any other error.
Is __try/__except only the way out of this?
-Sanjeev

Sanje²v

2009-10-13 11:17:14 UTC

Permalink

Post by Alexander Grigoriev
Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

I could do that but why bother all the tedious IPCs? With two
processes, I will have to copy bitmap objects (and similarly other
objects required by my application) back and fro, make sure of mutual
exclusion of shared data, ahh all that already gives me an headache.

Isn't my technique a better choice? Does it have any side-effects?

Still waiting for answer to my question.

Thanks all for replying,
Sanjeev

Alexander Grigoriev

2009-10-13 13:37:23 UTC

Permalink

If you got an access violation in the DLL, it could mean the DLL code
corrupted random memory, etc. The state of your process is now corrupted,
and it may crash in the future. Use of a proxy DLL host guarantees that your
process' state is never corrupted by third pary code.

Post by Alexander Grigoriev
Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

Sanje²v

2009-10-14 07:10:35 UTC

Permalink

I see what you mean. But as I said earlier copying data to and fro two
processes is tedious. I heavily use bitmap object and DCs between my
application and plugins. As HBITMAP and HDC are not usable across
processes, extracting bitmaps from HDCs, extracting and copying bitmap
header and bits into address space of plugin process and again doing
the same from the plugin process as a return bitmap from the function
in plugin is...I don't know...dirty? How have been applications using
plugins been doing all these years?

Here's another approach to the problem. If there was a way to protect
my application code with READ and EXECUTE only permissions before
entering plugin code, then my application could not be in inconsistent
state if plugin code tried to write where it wasn't supposed to. If
plugin code referenced NULL pointers then access violation could be
caught without ambiguity.

-Sanjeev

Alexander Grigoriev

2009-10-14 14:03:06 UTC

Permalink

The corruption happens in the data pages, not in code. You cannot protect
all your data with read-only.

You could write a set of routines to marshal the objectsback and forth. Your
own API proxy layer. To reduce copying, you can use shared memory.

You either do it right albeit tedious, or half-baked and essentially
not-working.

Post by SanjeÂ²v
I see what you mean. But as I said earlier copying data to and fro two
processes is tedious. I heavily use bitmap object and DCs between my
application and plugins. As HBITMAP and HDC are not usable across
processes, extracting bitmaps from HDCs, extracting and copying bitmap
header and bits into address space of plugin process and again doing
the same from the plugin process as a return bitmap from the function
in plugin is...I don't know...dirty? How have been applications using
plugins been doing all these years?
Here's another approach to the problem. If there was a way to protect
my application code with READ and EXECUTE only permissions before
entering plugin code, then my application could not be in inconsistent
state if plugin code tried to write where it wasn't supposed to. If
plugin code referenced NULL pointers then access violation could be
caught without ambiguity.
-Sanjeev

Ben Voigt [C++ MVP]

2009-10-16 00:09:56 UTC

Permalink

With an in-process plugin system, it's definitely worth while to catch the
exception and report the list of loaded plugins (any of them could have
corrupted data structures). Don't count on recovery though (but do try to
save the user's data into a temp file, process it when your app restarts to
see if there's anything useful there).

Post by Alexander Grigoriev
The corruption happens in the data pages, not in code. You cannot protect
all your data with read-only.
You could write a set of routines to marshal the objectsback and forth.
Your own API proxy layer. To reduce copying, you can use shared memory.
You either do it right albeit tedious, or half-baked and essentially
not-working.

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

John Lim

2010-11-24 13:07:39 UTC

Permalink

Hi,

If I have two dlls. The first dll will call the exported functions of the second dll. In my first dll i have the following __try __except section

__try
{
if(CallFuncIn2ndDll(pBuffer))
{
dwDataReadCount = 8;
}
else
{
dwDataReadCount = (DWORD) -1;
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
SetLastError(ERROR_INVALID_PARAMETER);
return (DWORD) -1;
}

An exception (Access violation) happens in the function of the 2nd dll (which does not have a __try __except block) but my __try __except block does not catch this exception. Is this because the __try __except block can only catch excpetions within it own dll process space?

Thanks.

Regards,
John

Why do you want to catch access violation? You cannot use it to validate
memory addresses.

Post by legalize+ (Richard)
[Please do not mail me a copy of your followup]
About the only useful thing I can think of is to generate a minidump
for bug reporting.
Once you have chased down through a bogus pointer, all bets are usually
off.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Post by Ben Voigt [C++ MVP]
Yes, using _set_se_translator
But I'd just use __try/__except for that. You do not have to change all your
try/catch. You just cannot put both in the same function, it is legal to put
__try/__except in a function that calls another function which uses
try/catch.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4498 (20091011) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

Post by Alexander Grigoriev
Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

Post by Alexander Grigoriev
If you got an access violation in the DLL, it could mean the DLL code
corrupted random memory, etc. The state of your process is now corrupted,
and it may crash in the future. Use of a proxy DLL host guarantees that your
process' state is never corrupted by third pary code.
I could do that but why bother all the tedious IPCs? With two
processes, I will have to copy bitmap objects (and similarly other
objects required by my application) back and fro, make sure of mutual
exclusion of shared data, ahh all that already gives me an headache.
Isn't my technique a better choice? Does it have any side-effects?
Still waiting for answer to my question.
Thanks all for replying,
Sanjeev

Post by Alexander Grigoriev
The corruption happens in the data pages, not in code. You cannot protect
all your data with read-only.
You could write a set of routines to marshal the objectsback and forth. Your
own API proxy layer. To reduce copying, you can use shared memory.
You either do it right albeit tedious, or half-baked and essentially
not-working.

With an in-process plugin system, it is definitely worth while to catch the
exception and report the list of loaded plugins (any of them could have
corrupted data structures). Don't count on recovery though (but do try to
save the user's data into a temp file, process it when your app restarts to
see if there is anything useful there).
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

Already told you: __try/__except is best, you can use it as long as it is in
a different function from try/catch (and one can call the other, then both
are protected).
But __set_se_handler will also let you identify access violation exceptions
from C++ try/catch. However, since stack unrolling has already taken place,
your debugging and recovery options are more limited, so I would choose
__try/__except to install an exception filter (aka first-chance exception
handler) before starting your main program.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

Though why I would wanna catch an access violation, is not related to
My program allows third-party dlls to be loaded into its address space
as plugins. But I surely would not want my application to crash due to
a faulty third-party dll doing something stupid like dereferencing a
NULL pointer. So, I thought why not guard the point where my
application calls functions in the third-party dll and if an access
violation is thrown, just unload the faulty dll and notify the user
that a problem has occurred due to a plugin and the program has
downgraded? I only want to catch an access violation error and allow
my application to crash (default behaviour) if other serious errors
occur.
A 'try/catch(...)' willl catch an access violation error but is not
able to identify if its really an access violation or any other error.
Is __try/__except only the way out of this?
-Sanjeev

Post by SanjeÂ²v
is
I could do that but why bother all the tedious IPCs? With two
processes, I will have to copy bitmap objects (and similarly other
objects required by my application) back and fro, make sure of mutual
exclusion of shared data, ahh all that already gives me an headache.
Isn't my technique a better choice? Does it have any side-effects?
Still waiting for answer to my question.
Thanks all for replying,
Sanjeev

Post by SanjeÂ²v
I see what you mean. But as I said earlier copying data to and fro two
processes is tedious. I heavily use bitmap object and DCs between my
application and plugins. As HBITMAP and HDC are not usable across
processes, extracting bitmaps from HDCs, extracting and copying bitmap
header and bits into address space of plugin process and again doing
the same from the plugin process as a return bitmap from the function
in plugin is...I do not know...dirty? How have been applications using
plugins been doing all these years?
Here is another approach to the problem. If there was a way to protect
my application code with READ and EXECUTE only permissions before
entering plugin code, then my application could not be in inconsistent
state if plugin code tried to write where it was not supposed to. If
plugin code referenced NULL pointers then access violation could be
caught without ambiguity.
-Sanjeev
Submitted via EggHeadCafe
ASP.NET Sum of Numbers Captcha Control with CustomValidator
http://www.eggheadcafe.com/tutorials/aspnet/bde8bf73-c31c-4c73-af05-861769e625e8/aspnet-sum-of-numbers-captcha-control-with-customvalidator.aspx

John Lim

2010-11-24 15:19:16 UTC

Permalink

Why do you want to catch access violation? You cannot use it to validate
memory addresses.

Post by Alexander Grigoriev
Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

Post by Alexander Grigoriev
The corruption happens in the data pages, not in code. You cannot protect
all your data with read-only.
You could write a set of routines to marshal the objectsback and forth. Your
own API proxy layer. To reduce copying, you can use shared memory.
You either do it right albeit tedious, or half-baked and essentially
not-working.

Post by SanjeÂ²v
I see what you mean. But as I said earlier copying data to and fro two
processes is tedious. I heavily use bitmap object and DCs between my
application and plugins. As HBITMAP and HDC are not usable across
processes, extracting bitmaps from HDCs, extracting and copying bitmap
header and bits into address space of plugin process and again doing
the same from the plugin process as a return bitmap from the function
in plugin is...I do not know...dirty? How have been applications using
plugins been doing all these years?
Here is another approach to the problem. If there was a way to protect
my application code with READ and EXECUTE only permissions before
entering plugin code, then my application could not be in inconsistent
state if plugin code tried to write where it was not supposed to. If
plugin code referenced NULL pointers then access violation could be
caught without ambiguity.
-Sanjeev

Post by John Lim
Hi,
If I have two dlls. The first dll will call the exported functions of the second dll. In my first dll i have the following __try __except section
__try
{
if(CallFuncIn2ndDll(pBuffer))
{
dwDataReadCount = 8;
}
else
{
dwDataReadCount = (DWORD) -1;
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
SetLastError(ERROR_INVALID_PARAMETER);
return (DWORD) -1;
}
An exception (Access violation) happens in the function of the 2nd dll (which does not have a __try __except block) but my __try __except block does not catch this exception. Is this because the __try __except block can only catch excpetions within it own dll process space?
Thanks.
Regards,
John
Submitted via EggHeadCafe
OAuth Basics for .NET Developers
http://www.eggheadcafe.com/tutorials/aspnet/16beeea4-4332-4d23-8433-ade0ae6dbcbd/oauth-basics-for-net-developers.aspx

John Lim

2010-11-24 15:19:48 UTC

Permalink

Why do you want to catch access violation? You cannot use it to validate
memory addresses.

Post by Alexander Grigoriev
Make a separate DLL hosting process, and design a communication scheme
between it and your main app. If the dll host crashes, your main process is
still alive.

Post by Alexander Grigoriev
The corruption happens in the data pages, not in code. You cannot protect
all your data with read-only.
You could write a set of routines to marshal the objectsback and forth. Your
own API proxy layer. To reduce copying, you can use shared memory.
You either do it right albeit tedious, or half-baked and essentially
not-working.

Post by SanjeÂ²v
I see what you mean. But as I said earlier copying data to and fro two
processes is tedious. I heavily use bitmap object and DCs between my
application and plugins. As HBITMAP and HDC are not usable across
processes, extracting bitmaps from HDCs, extracting and copying bitmap
header and bits into address space of plugin process and again doing
the same from the plugin process as a return bitmap from the function
in plugin is...I do not know...dirty? How have been applications using
plugins been doing all these years?
Here is another approach to the problem. If there was a way to protect
my application code with READ and EXECUTE only permissions before
entering plugin code, then my application could not be in inconsistent
state if plugin code tried to write where it was not supposed to. If
plugin code referenced NULL pointers then access violation could be
caught without ambiguity.
-Sanjeev

Post by John Lim
Hi,
If I have two dlls. The first dll will call the exported functions of the second dll. In my first dll i have the following __try __except section
__try
{
if(CallFuncIn2ndDll(pBuffer))
{
dwDataReadCount = 8;
}
else
{
dwDataReadCount = (DWORD) -1;
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
SetLastError(ERROR_INVALID_PARAMETER);
return (DWORD) -1;
}
An exception (Access violation) happens in the function of the 2nd dll (which does not have a __try __except block) but my __try __except block does not catch this exception. Is this because the __try __except block can only catch excpetions within it own dll process space?
Thanks.
Regards,
John
Submitted via EggHeadCafe
C# In Depth Second Edition - An Interview with Jon Skeet
http://www.eggheadcafe.com/tutorials/aspnet/9961390d-2cc6-4a63-ab5e-dd8c1098e9f8/c-in-depth-second-edition--an-interview-with-jon-skeet.aspx

Ben Voigt [C++ MVP]

2009-10-16 00:14:26 UTC

Permalink

Post by SanjeÂ²v
A 'try/catch(...)' willl catch an access violation error but is not
able to identify if its really an access violation or any other error.
Is __try/__except only the way out of this?

Already told you: __try/__except is best, you can use it as long as it's in
a different function from try/catch (and one can call the other, then both
are protected).
But __set_se_handler will also let you identify access violation exceptions
from C++ try/catch. However, since stack unrolling has already taken place,
your debugging and recovery options are more limited, so I would choose
__try/__except to install an exception filter (aka first-chance exception
handler) before starting your main program.

Post by SanjeÂ²v
-Sanjeev
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com