App crashes and exception handling [Was: Re: VirtualProtect and app crash]

[Robert Baruch]

This is where that 0x761B10 address must have been coming from:

007605E2 sub_7605E2      proc near               ; CODE XREF: start+88^Xp
007605E2                 mov     eax, large fs:0
007605E8                 push    ebp
007605E9                 mov     ebp, esp
007605EB                 push    0FFFFFFFFh
007605ED                 push    75A010h
007605F2                 push    761B10h
007605F7                 push    eax
007605F8                 mov     large fs:0, esp
007605FF                 sub     esp, 14h

It's code that gets called very near the beginning of the program. I 
think this corresponds to the EXCEPTION_FRAME structure in 
include/winnt.h, so that 0x761B10 is the exception handler, and eax 
(fs:0) is the previous exception frame. Then there's some extra data, 
0x75A010 and -1 at the end of the frame data.

I used WinDbg to step through the code running under W2K, setting a 
breakpoint at 0x761B10. Running the code, it caught an access violation 
at a place neither wine nor gdb caught in a piece of code that seems 
obviously designed to look for an access violation:

0075F0D7                 mov     eax, 75F07Eh
0075F0DC                 mov     dword_75C5B0, eax
0075F0E1                 mov     dl, [eax]
0075F0E3                 mov     [eax], dl   <- write exception

75F07E is actually the beginning of the procedure containing this code.

The WinDbg debugger caught it, and I told it to continue, not handling 
the exception. I promptly hit my breakpoint. I let it continue from 
there, and I hit the next access violation in the place where both gdb 
and wine caught it. But when I continued in WinDbg, the exception 
handler at 0x761B10 was not called! Weird!

So I restarted, got to the second violation, and single-stepped. I ended 
up in a function called ntdll!KiUserExceptionDispatcher. I did a little 
web research and found an excellent article describing the internals of 
handling exceptions in a Microsoft Systems Journal article from 1997: 
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/exception/exception.htm&nav=/msj/0197/newnav.htm

The article even described exactly what 0x761B10 seems to do when I 
looked at it and compared it to the article's __except_handler3 
pseudocode. Apparently it's from Visual C++.

Anyway, I'm now going to look into why wine doesn't catch the exception 
that WinDbg did.

--Rob