http://bugs.winehq.org/show_bug.cgi?id=27435
--- Comment #4 from Anastasius Focht focht@gmx.net 2011-06-09 18:34:33 CDT --- Hello Austin,
next time please try "append" mode, some parts are hard to read due to interleaving messages.
From a quick look this seems to be the location where the problem starts:
--- snip --- ... 0029:Call ntdll.RtlAddVectoredExceptionHandler(00000001,009423a0) ret=009425bb 0029:Ret ntdll.RtlAddVectoredExceptionHandler() retval=00154260 ret=009425bb ... 0029:Ret KERNEL32.GetCurrentThreadId() retval=00000029 ret=00941b22 0029:trace:seh:raise_exception code=80000003 flags=0 addr=0x94290d ip=0094290e tid=0029 0029:trace:seh:raise_exception eax=0033ef40 ebx=0033f5f4 ecx=0033eb7c edx=574cb391 esi=00154290 edi=00000000 0029:trace:seh:raise_exception ebp=0033f180 esp=0033ef30 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00000282 0029:trace:seh:call_vectored_handlers calling handler at 0x9423a0 code=80000003 flags=0 ... 0029:Call KERNEL32.GetSystemDirectoryW(00000000,00000000) ret=0094fff1 0029:Ret KERNEL32.GetSystemDirectoryW() retval=00000014 ret=0094fff1 0029:Call KERNEL32.GetProcessHeap() ret=00950006 0029:Ret KERNEL32.GetProcessHeap() retval=00110000 ret=00950006 0029:Call ntdll.RtlAllocateHeap(00110000,00000008,00000234) ret=0095000d 0029:Ret ntdll.RtlAllocateHeap() retval=0015f4d0 ret=0095000d 0029:Call KERNEL32.GetSystemDirectoryW(0015f4d0,00000234) ret=00950017 0029:Ret KERNEL32.GetSystemDirectoryW() retval=00000013 ret=00950017 0029:Call KERNEL32.GetModuleHandleA(00adf650 "kernel32.dll") ret=0094b5ae 0029:Ret KERNEL32.GetModuleHandleA() retval=7b810000 ret=0094b5ae 0029:Call KERNEL32.GetProcAddress(7b810000,00adf630 "Wow64DisableWow64FsRedirection") ret=0094b5c4 0029:Ret KERNEL32.GetProcAddress() retval=7b826650 ret=0094b5c4 0029:Call KERNEL32.GetProcAddress(7b810000,00adf610 "Wow64RevertWow64FsRedirection") ret=0094b5d0 0029:Ret KERNEL32.GetProcAddress() retval=7b826668 ret=0094b5d0 0029:Call KERNEL32.Wow64DisableWow64FsRedirection(0033f1d0) ret=0094b5e3 0029:Ret KERNEL32.Wow64DisableWow64FsRedirection() retval=00000000 ret=0094b5e3 0029:Call KERNEL32.CreateFileW(0015f4d0 L"C:\windows\system32\",80000000,00000007,00000000,00000003,00000000,ffffffff) ret=0094cb34 0029:Ret KERNEL32.CreateFileW() retval=ffffffff ret=0094cb34 0029:Call KERNEL32.CreateFileW(0015f4d0 L"C:\windows\system32\",80000000,00000007,00000000,00000003,02000000,ffffffff) ret=0094cb53 0029:Ret KERNEL32.CreateFileW() retval=000001a0 ret=0094cb53 0029:Call KERNEL32.GetFileInformationByHandle(000001a0,0033f190) ret=0094cb81 0029:Ret KERNEL32.GetFileInformationByHandle() retval=00000001 ret=0094cb81 0029:trace:seh:raise_exception code=80000004 flags=0 addr=0x94ddf0 ip=0094ddf0 tid=0029 0029:trace:seh:raise_exception eax=00c5625d ebx=0033f698 ecx=00000000 edx=00000000 esi=0015f4d0 edi=000001a0 0029:trace:seh:raise_exception ebp=0033f1d8 esp=0033ef6c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010202 0029:trace:seh:call_vectored_handlers calling handler at 0x9423a0 code=80000004 flags=0 0029:Call KERNEL32.GetCurrentThreadId() ret=00941a2a 0029:Ret KERNEL32.GetCurrentThreadId() retval=00000029 ret=00941a2a 0029:trace:seh:call_vectored_handlers handler at 0x9423a0 returned 0 0029:trace:seh:call_vectored_handlers calling handler at 0x7e0e55a0 code=80000004 flags=0 0029:trace:seh:call_vectored_handlers handler at 0x7e0e55a0 returned 0 0029:trace:seh:call_stack_handlers calling handler at 0x99b933 code=80000004 flags=0 0029:Call KERNEL32.GetLastError() ret=78543849 0029:Ret KERNEL32.GetLastError() retval=00000000 ret=78543849 0029:trace:seh:call_stack_handlers handler at 0x99b933 returned 1 0029:trace:seh:call_stack_handlers calling handler at 0x109101ad code=80000004 flags=0 0029:Call KERNEL32.GetLastError() ret=78543849 0029:Ret KERNEL32.GetLastError() retval=00000000 ret=78543849 0029:trace:seh:call_stack_handlers handler at 0x109101ad returned 1 0029:trace:seh:call_stack_handlers calling handler at 0x7bc87380 code=80000004 flags=0 0029:Call KERNEL32.UnhandledExceptionFilter(0033eae8) ret=7bc873cd 0029:Call KERNEL32.IsBadCodePtr(60001770) ret=03ad261d 0029:Ret KERNEL32.IsBadCodePtr() retval=00000000 ret=03ad261d 0029:Call dbghelp.SymGetOptions() ret=600029f5 0029:Ret dbghelp.SymGetOptions() retval=00000002 ret=600029f5 --- snip ---
That break instruction exception seen here (caused by int 3) is most likely used to modify own thread context from installed vectored SEH without the need of (Nt)Get/SetThreadContext().
"Most likely" because of that 0x80000004 exception that follows some calls later (hardware bp/singlestep). It would be interesting to have a look at debug register values at this point (dr0-dr3,dr6,dr7) but that requires a +server trace. One of them should reference the address 0x94ddf0 (break on execution).
That GetFileInformationByHandle() call might be some part of DRM scheme, remember this is steam. I think this was also the reason why this API was introduced in Wine (Left 4 Dead 2 DRM?). Though one needs to debug/disassemble the caller to actually find out what parts of the returned data are used and how. Maybe the index number because it's guaranteed to be unique across filesystems (FAT32, NTFS). "C:\windows\system32\" is a pretty "stable" path so the index number might only change if someone uses FAT and decides to defragment the disk.
At the point of IsBadCodePtr()/SymGetOptions() calls the things were already out of control... maybe some condition was not satisfied. Either the hw breakpoint(s) should never been hit/reached by "normal" execution paths or if they were to hit, the data gathered until that point was somehow considered bad (hence SEH chain no handler felt responsible).
Though that's pure speculation... it's like crystal ball reading when looking at such relay logs without actually live debugging that garbage. Guesswork because of similar patterns I remember/encountered in countless debug sessions of anti debug/protection crap.
Regards