理解UnhandledExceptionFilter

 最初发表在QQ空间，全文参见 理解UnhandledExceptionFilter

UnhandledExceptionFilter，在一个windows平台上的C/C++程序中，主线程的SEH框架会有2层，最外层是BaseProcessStart，里面是mainCRTStartup，这意味着一般情况下，当有异常发生时，UnhandledExceptionFilter会被调用2次。

UEF首先会检测当前进程的DebugPort，如果存在，则返回EXCEPTION_CONTINUE_SEARCH，继续分发异常。这也是为什么，只有在调试情况下，用户态异常才有第2轮分发的机会。

下面，UEF会调用_BasepCurrentTopLevelFilter（如果存在），这个值是用SetUnhandledExceptionFilter设定的。参见 Windows平台下的异常处理

然后，UEF中会检测是否显示GPF，如果不显示，则UEF返回EXCEPTION_EXECUTE_HANDLER，通常也就是终止进程。

UEF接下来会显示Error Box，要么用户选择关闭进程，也还是如上面一样，UEF返回EXCEPTION_EXECUTE_HANDLER，终止进程，要么用户就启用了JIT，UEF返回EXCEPTION_CONTINUE_SEARCH，这样才会有调用外层UEF的机会。

在第一次的UEF调用中，如果启用了JIT，则由于NtDebugActiveProcess函数的作用，当前的进程已经成为了一个被调试的进程，所以第2次的UEF调用中检测到当前进程是一个被调试的进程，直接返回了EXCEPTION_CONTINUE_SEARCH，这样也导致了第2轮的异常分发，调试器会首先收到这一异常。

从上面的流程可以看出，用户自定义的未处理异常过滤器即顶层异常过滤器被调用的条件是2个，1. 发生未处理的异常 2. 当前进程不在被调试

2011/05/04:

补充一个意外的发现，__report_gsfailure中UEF的特殊行为