Re: I see what you mean.

From:

John Lim <john.lim@pciltd.com.sg>

Newsgroups:

microsoft.public.vc.language

Date:

Wed, 24 Nov 2010 13:07:39 GMT

Message-ID:

<201011248735usenet@eggheadcafe.com>

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

On Sunday, October 11, 2009 10:13 PM Alexander Grigoriev wrote:

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

On Sunday, October 11, 2009 10:26 PM legalize+jeeve wrote:

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

"Alexander Grigoriev" <alegr@earthlink.net> spake the secret code

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/>

On Monday, October 12, 2009 1:56 AM Ben Voigt [C++ MVP] wrote:

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

On Tuesday, October 13, 2009 1:07 AM Alexander Grigoriev wrote:

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.

On Tuesday, October 13, 2009 9:37 AM Alexander Grigoriev wrote:

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

On Wednesday, October 14, 2009 10:03 AM Alexander Grigoriev wrote:

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.

On Thursday, October 15, 2009 8:09 PM Ben Voigt [C++ MVP] wrote:

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

On Thursday, October 15, 2009 8:14 PM Ben Voigt [C++ MVP] wrote:

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

On Monday, October 26, 2009 8:23 PM Sanje?v wrote:

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

On Monday, October 26, 2009 8:23 PM Sanje?v wrote:

Though why I would wanna catch an access violation, is not related to
the problem. Here is why, anyway:

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

On Monday, October 26, 2009 8:23 PM Sanje?v wrote:

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

On Monday, October 26, 2009 8:23 PM Sanje?v wrote:

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