App crashes and exception handling [Was: Re: VirtualProtect and app crash]
Robert Baruch
autophile at starband.net
Wed Dec 12 18:47:45 CST 2001
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
More information about the wine-users
mailing list