VirtualProtect and app crash: exception handling?

[Robert Baruch]

I downloaded (shudder) Microsoft's windbg program 
(http://www.microsoft.com/ddk/debugging/installx86beta.asp) and ran it 
for the app under Win2000/VMWare.

It also shows an exception at the same access! However, windbg displays 
the exception and then allows the user to continue the program, letting 
whatever exception handler the program installed handle the exception. 
And the program does install an exception handler.

After I stepped it past that exception, it started accessing memory 
starting from 0x401000 in steps of multiples of 0x1000, each access 
throwing an exception, until it hit the last exception at 0x757000, and 
then then program ran normally. Probably no coincidence, since the next 
writable segment starts at 0x759000.

So apparently the program is designed to throw the exceptions.

Just before the call to VirtualProtect:

0806d398:Call kernel32.SetUnhandledExceptionFilter(0075f447) ret=0075f0cb
0806d398:Ret  kernel32.SetUnhandledExceptionFilter() retval=00000000 
ret=0075f0cb

This function is this:

0075F447 sub_75F447      proc near
0075F447                 call    sub_75F047
0075F44C                 xor     eax, eax
0075F44E                 retn    4
0075F44E sub_75F447      endp

eax is set to 0 on exit, which is EXCEPTION_CONTINUE_SEARCH, which means 
to proceed with the UnhandledExceptionFilter Windows function, which 
should either display an Application Error message, or return to the 
application if SetErrorMode says so.

So what's with this trace?

0806d398:trace:seh:EXC_CallHandler calling handler at 0x761b10 
code=c0000005 flags=0

It looks like we're calling 0x761B10, not 0x75F447. Why?

It also looks like EXC_CallHandler is called from EXC_RtlRaiseException, 
which is called from do_segv, which is called from a signal handler for 
SIGSEGV.

Why does do_segv call EXC_RtlRaiseException, and not 
UnhandledExceptionFilter? Where did EXC_CallHandler get that 0x761B10 
address from?

--Rob