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
