harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [general] platform support
Date Thu, 10 Aug 2006 17:50:31 GMT
Hi Mikhail,
    As far as I know, SetUnhandledExceptionFilter was introduced as a
backdoor method in in Win2K SP4 to get around the problem that the SEH
handlers are limited to the frame and not process wide. It does handle
problems like NPE and AV, but as you point out, it works by hijacking the
first and last chance debugger handlers. So, unlike VEH which are fully
functional when debugging, these SetUnhandled...filters are not visible when
debugging. I also believe that they execute in the context of the current
thread, which means that they are not so good to handle stack corruption,
SOE etc. which we are currently using VEH. Since one does not expect them to
be used on the newer Windows boxes, the .Net framework overwrites them
...which means that any process that loads a Microsoft dll that has any
Microsoft managed code in it ( and many do ), is at a risk that the
SetUnhandled.. may or may not work.
   I think that SetUnhandled..was a great(probably only ) solution on the
Win2K boxes, but VEH was put in place to solve some of its limitations. The
bottom line is that one needs to experiment with this on several Windows
boxes before we know how good or bad it is. I myself don't have a lot of
experience with it.


On 8/10/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >**Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE
> >for Win2k too.
> >The only problem is debbuging of applications with exception filter
> >installed. AFAIK debugger will catch all of these events.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message