http://bugs.winehq.org/show_bug.cgi?id=22064
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #47 from Anastasius Focht focht@gmx.net 2010-08-24 13:53:31 --- Hello,
--- quote --- c0000005 is a crash. Perhaps this is a red herring, but I wonder whether this crash is somewhere in a thread which should have been receiving data, which causes it never to receive it? I suspect someone willing to disassemble the app and debug the crash that way will get further with this than I. --- quote ---
well, I had a look at it ;-)
First, you can greatly reduce complexity by starting only the launcher with useful arguments:
--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Ubisoft/Ubisoft Game Launcher
$ wine ./UbisoftGameLauncher.exe -prodid 17 -gameversion 704 -lng en-US -nohttpproxy -orbitcookie 666 --- snip ---
Determine the exact values for your game using +relay or +process by starting the main game executable once.
While playing with the launcher I found additional useful command line arguments:
--- snip --- -httpproxy [proxy] -nohttpproxy -nowatchdog -orbitcookie [int] -orbitdroptimeout [seconds] -gameexe [path_base64_encoded_string] -satellites ip1:port1,ip2:port2 (note will crash the launcher if not valid format) -satellite_list_url [url] -orbitdev (use "mdc-dev-orbt-mgmt01.ubisoft.com") -orbituat (use "mdc-uat-orbt-lnx01.ubisoft.com" [defaults: static3.cdn.ubi.com/orbit and ubisoft-orbit.s3.amazonaws.com]) --- snip ---
Additional log files created in launcher folder:
--- snip --- launcher_log.txt orbitdll_game_log.txt orbitdll_launcher_log.txt --- snip ---
First there are notable 0x406D1388 exceptions (EXCEPTION_NAME_THREAD) which the ubisoft/orbit framework (ubiorbitapi_r2.dll) raises to give their worker threads meaningful names (the devs probably use Visual Studio).
Names given using EXCEPTION_NAME_THREAD:
"ServerBox - Resolver" - DNS resolver thread (gethostbyname) "Network Monitor" - (unknown how connections are "monitored") "NamedPipeConnection" - worker, reads from a named pipe ("\\.\pipe\orbit_ipc_pipe"), seems more like an in-process "IPC" mechanism "ServerBox - WorkerThread" - listens for data on sockets using I/O completion port (overlapped socket I/O)
The crash is in "ServerBox" socket receiver worker thread in some kind of memcpy() to copy received (and decrypted) payload(s) to other app internal buffers.
The "src" parameter of the copy routine is bogus at the time of the crash. It pointed to the last bytes of mapped ntdll.dll. The "memcpy" caller passed 1000 byte count hence it touched the next page after ntdll.dll which is of course not mapped, hence the read fault.
Upon reception of message, the receiver worker thread decrypts the message payload (if encrypted), calling secur32.DecryptMessage:
Without +relay channel:
--- snip --- ... 001e:trace:secur32:DecryptMessage 0x4d6c14 0xbde94c 0 (nil) 001e:trace:secur32:schan_DecryptMessage context_handle 0x1b9490, message 0xbde94c, message_seq_no 0, quality (nil) 001e:trace:secur32:dump_buffer_desc Buffer desc 0xbde94c: 001e:trace:secur32:dump_buffer_desc buffer 0: cbBuffer 26, BufferType 0x1 pvBuffer 0xbde8b0 001e:trace:secur32:dump_buffer_desc buffer 1: cbBuffer 0, BufferType 0 pvBuffer (nil) 001e:trace:secur32:dump_buffer_desc buffer 2: cbBuffer 0, BufferType 0 pvBuffer (nil) 001e:trace:secur32:dump_buffer_desc buffer 3: cbBuffer 0, BufferType 0 pvBuffer (nil) ... 001e:trace:secur32:schan_DecryptMessage Received 5 bytes --- snip ---
Now with +relay enabled (leading to crash):
--- snip --- ... 001d:trace:secur32:DecryptMessage 0x4d6c7c 0x9de94c 0 (nil) 001d:trace:secur32:schan_DecryptMessage context_handle 0x1cc820, message 0x9de94c, message_seq_no 0, quality (nil) 001d:trace:secur32:dump_buffer_desc Buffer desc 0x9de94c: 001d:trace:secur32:dump_buffer_desc buffer 0: cbBuffer 26, BufferType 0x1 pvBuffer 0x9de8b0 001d:trace:secur32:dump_buffer_desc buffer 1: cbBuffer 10348896, BufferType 0 pvBuffer 0x7bc914ba 001d:trace:secur32:dump_buffer_desc buffer 2: cbBuffer 29, BufferType 0 pvBuffer 0x7b8865b6 001d:trace:secur32:dump_buffer_desc buffer 3: cbBuffer 1, BufferType 0 pvBuffer 0x4d6c40 ... 001d:trace:secur32:schan_DecryptMessage Received 5 bytes ... 001d:Ret secur32.DecryptMessage() retval=00000000 ret=10052862 --- snip ---
Buffer index 1 and 2 contain completely bogus values due to changed stack layout (relay thunks). The app obviously didn't initialize all descriptor fields explicitly. A bit later, when the decrypted buffer payloads are copied:
--- snip --- 001d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1001d67a ip=1001d67a tid=001d 001d:trace:seh:raise_exception info[0]=00000000 001d:trace:seh:raise_exception info[1]=7bcb6000 001d:trace:seh:raise_exception eax=7bcb6292 ebx=009b9f70 ecx=000000a5 edx=00000000 esi=7bcb5ffe edi=004fe4e8 001d:trace:seh:raise_exception ebp=009de87c esp=009de874 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 001d:trace:seh:call_vectored_handlers calling handler at 0x689a12d0 code=c0000005 flags=0 001d:trace:seh:call_vectored_handlers handler at 0x689a12d0 returned 0 001d:trace:seh:call_stack_handlers calling handler at 0x10077f05 code=c0000005 flags=0 --- snip ---
esi=7bcb5ffe -> next dword touches unmapped page
I zeroed out the byte count for each unused buffer in "dlls/secur32/schannel.c:schan_DecryptMessage" and it helped. With that fix you can fully use +relay (with the "UbisoftGameLauncher.exe" launcher shortcuts I gave above).
Regards