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.
Thanks, Rana On 8/10/06, Mikhail Fursov <[EMAIL PROTECTED]> 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.
