[Bug 22064] The Settlers 7 Demo fails to start

Tue Aug 24 13:53:32 CDT 2010

http://bugs.winehq.org/show_bug.cgi?id=22064

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net

--- Comment #47 from Anastasius Focht <focht at 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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.