http://bugs.winehq.org/show_bug.cgi?id=15649
Summary: Ultima Online with Razor (.NET) often crashes Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: leffeman@gmail.com
Created an attachment (id=16705) --> (http://bugs.winehq.org/attachment.cgi?id=16705) catted together a couple different stack traces
UO often crashes when launched by Razor (a .NET application), it appears to be due to some stack corruption as all stack traces originate at ``wine_switch_to_stack,'' and sometimes I get the ``stack overflow %u bytes in thread %04x'' message (haven't been able to catch it this time though).
List of applications needed for testing: http://gamedaily.newaol.com/pub/0078700501/UOML_setup.exe http://www.runuo.com/razor/Razor_Latest.exe .NET 2.0 (``winetricks dotnet20'' works well, some people might have to run some font installers as well.)
http://bugs.winehq.org/show_bug.cgi?id=15649
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |1.1.6
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #1 from Philip Nilsson leffeman@gmail.com 2008-10-23 05:10:53 --- Created an attachment (id=16815) --> (http://bugs.winehq.org/attachment.cgi?id=16815) stack overflow
Managed to catch some of the stack overflows, attaching one of them.
http://bugs.winehq.org/show_bug.cgi?id=15649
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-12-14 10:04:22 --- Hello,
I can only reproduce some of the issues when I slow the app down under a managed debugger (changes timing of execution paths).
One of problems is actually within the software itself.
Whoever wrote this .NET app doesn't know how to cleanly separate UI and threading. UI controls are not generally thread safe in .NET (suprise!). That means one should not access controls from a threads other than the one where it lives. That app tries exactly that, by accessing controls across threads (looks like some splash UI/thread vs. main UI/thread) issue.
If the app works in Windows it doesn't necessarily mean there is no bug. It might be hidden due to different execution timing.
You could try to update to newer Wine + newer Razor client and check if the overall situation improves...
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #3 from Austin English austinenglish@gmail.com 2009-06-16 14:24:05 --- Is this still an issue in current (1.1.23 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #4 from Philip Nilsson leffeman@gmail.com 2009-06-16 17:40:27 --- It's still around.
I wrote a few test applications three months ago which gave me the same errors and concluded it's because of the known problem with code injection (bug 13915 might be the same or related if true). A page on the Wine Wiki[1] has some information under the TODO heading, the linked thread[2] is worth reading.
[1] http://wiki.winehq.org/RemoteProcessOperations [2] http://www.winehq.org/pipermail/wine-devel/2005-August/thread.html#39120
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #5 from Anastasius Focht focht@gmx.net 2009-06-17 02:16:25 --- Hello,
--- quote --- It's still around. --- quote ---
Please provide exact step-by-step instructions to reproduce it. Is that an in-game problem?
The startup issue this bug was initially about seems now gone with newer version of Razor.NET client (1.0.11).
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #6 from Philip Nilsson leffeman@gmail.com 2009-06-17 05:54:28 --- (In reply to comment #5)
Please provide exact step-by-step instructions to reproduce it.
1. ftp://largedownloads.ea.com/pub/uo/setup-1.46.0.3.exe 2. winetricks dotnet20 3. http://www.runuo.com/razor/Razor_Latest.exe 4. Launch Razor.exe 5. Click Okay. 6. client.exe either crashes or doesn't, repeat steps 4-6 a few times.
With a new prefix and today's Wine it crashes more often than not. It is rumored that some users do not experience this crashing.
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #7 from Anastasius Focht focht@gmx.net 2009-06-17 07:37:53 --- Hello,
--- quote --- With a new prefix and today's Wine it crashes more often than not. It is rumored that some users do not experience this crashing. --- quote ---
Different execution/thread timing can cause all sorts of hidden bugs to surface. Wine can't replicate exact threading/timing behaviour of Windows by design.
I looked again and I still hold up my analysis. The app accesses splash screen (label control) across threads without proper synchronization to the threads which owns the control (Window).
The only workaround I can give you is to pass "--nowelcome" command line parameter which basically omits the splash screen at all, preventing the buggy code. Please report back if that works for you. Otherwise I fear this is something Wine can't fix.
Again: If something works in Windows this doesn't mean it's properly implemented nor bug free. Windows tolerates lots of brain damage, hiding many app bugs.
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #8 from Philip Nilsson leffeman@gmail.com 2009-06-17 09:46:05 --- (In reply to comment #7)
The only workaround I can give you is to pass "--nowelcome" command line parameter which basically omits the splash screen at all, preventing the buggy code. Please report back if that works for you.
That does omit the splash screen, but the result is the same.
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #9 from Anastasius Focht focht@gmx.net 2009-06-17 09:52:03 --- Hello,
--- quote --- That does omit the splash screen, but the result is the same. --- quote ---
Actually I can't get this thing to single crash here (apart from the splash screen bug), tested dozen times. Works out of the box.
Please provide WINEDEBUG=+tid,+seh,+relay wine ./foo.exe &> log.txt, compress and attach the log in case of a crash.
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #10 from Anastasius Focht focht@gmx.net 2009-06-17 10:55:04 --- Hello,
additionally can you do the following:
Download a tracing tool for .NET CLR runtime (.NET assemblies): http://www.woodmann.com/collaborative/tools/images/Bin_DotNET_Tracer_2008-12...
You need 'winetricks vcrun6' before install (MFC42.dll dependency).
1. Start the tool "KDE.exe". 2. Browse to path of that Razor app in "assembly to trace". 3. Select "CLR Events" in "Events to log" (will tick all childs). 4. Press "start" ... when it bails, save the log (ctrl+s) and attach to this bug.
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #11 from Philip Nilsson leffeman@gmail.com 2009-06-17 13:37:28 --- Created an attachment (id=21855) --> (http://bugs.winehq.org/attachment.cgi?id=21855) WINEDEBUG=+tid,+seh,+relay WINEPREFIX=$HOME/incoming/razorprefix ~/dev/wine/wine Razor.exe &>relay.log
(In reply to comment #10)
additionally can you do the following:
Thanks, I did not manage to reproduce the crash while running under the .NET tracer, but with WINEDEBUG=+tid,+seh,+relay it was no problem. I ran with the splash screen disabled.
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #12 from Anastasius Focht focht@gmx.net 2009-06-17 15:41:17 --- Hello,
--- quote --- Thanks, I did not manage to reproduce the crash while running under the .NET tracer, but with WINEDEBUG=+tid,+seh,+relay it was no problem. I ran with the splash screen disabled. --- quote ---
So using tracer tool on razor makes the client start? Interesting. What happens if you do the following:
1. Start game client ("client.exe" whatever the binary is named) from install directory, e.g. "C:\Program Files\EA Games\Ultima Online 2D Client\" 2. Open another console, start "winedbg" 3. Execute "info process" command, make note of "client.exe" process id 4. Exit "winedbg" -> "quit" 5. Start "Razor" tool from install directory with "--nowelcome --pid 0xHH" (replace "HH" with process id from step 3)
Does Razor successfully attach to the existing client process?
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #13 from Anastasius Focht focht@gmx.net 2009-06-17 17:30:11 --- Hello,
after looking at Razor's injector code it seems indeed to rely on fixed base address for kernel32.dll in both Razor and game client process space - needed to write the thunk instructions that call LoadLibrary() and GetProcAddress().
The following code snippets are called from "loader.dll", export "Load":
Params:
"C:\Program Files\EA Games\Ultima Online 2D Client\client.exe" -> the remote process where the dll will be injected/loaded "Crypt.dll" -> the library to be injected "OnAttach" -> export that will be called from remote thunk code when library got loaded
--- snip --- 0009:Call KERNEL32.CreateProcessA(0033f170 "C:\Program Files\EA Games\Ultima Online 2D Client\client.exe",00000000,00000000,00000000,00000000,00000004,00000000,0033ecec "C:\Program Files\EA Games\Ultima Online 2D Client",0033edf0,0033ec8c) ret=031d118f 0022:trace:relay:load_list L"RelayExclude" = L"ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.48;kernel32.49;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98" 0022:trace:relay:load_list L"RelayFromExclude" = L"winex11.drv;user32;gdi32;advapi32;kernel32" 0022:Call KERNEL32.__wine_kernel_init() ret=7ef94483 0009:Ret KERNEL32.CreateProcessA() retval=00000001 ret=031d118f --- snip ---
Remote process is created suspended.
--- snip --- ... 0009:Call KERNEL32.VirtualAllocEx(00000184,00000000,00000066,00003000,00000040) ret=031d120e 0009:Ret KERNEL32.VirtualAllocEx() retval=00340000 ret=031d120e 0009:Call ntdll.RtlAllocateHeap(03890000,00000000,00000066) ret=031d1be6 0009:Ret ntdll.RtlAllocateHeap() retval=03891e18 ret=031d1be6 0009:Call KERNEL32.VirtualProtectEx(00000184,00554b3c,00000008,00000040,0033ec88) ret=031d1297 0009:Ret KERNEL32.VirtualProtectEx() retval=00000001 ret=031d1297 0009:Call KERNEL32.ReadProcessMemory(00000184,00554b3c,0033ecec,00000008,0033ec88) ret=031d12cd 0009:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=031d12cd 0009:Call KERNEL32.WriteProcessMemory(00000184,00554b3c,0033eca4,00000008,0033ec88) ret=031d1315 0009:Ret KERNEL32.WriteProcessMemory() retval=00000001 ret=031d1315 0009:Call KERNEL32.LoadLibraryA(031d816c "Kernel32") ret=031d13a8 0009:Ret KERNEL32.LoadLibraryA() retval=7edb0000 ret=031d13a8 0009:Call KERNEL32.GetProcAddress(7edb0000,031d815c "LoadLibraryA") ret=031d13bd 0009:Ret KERNEL32.GetProcAddress() retval=7edc1f40 ret=031d13bd 0009:Call KERNEL32.GetProcAddress(7edb0000,031d814c "GetProcAddress") ret=031d13de 0009:Ret KERNEL32.GetProcAddress() retval=7edc1118 ret=031d13de 0009:Call KERNEL32.FreeLibrary(7edb0000) ret=031d13f2 0009:Ret KERNEL32.FreeLibrary() retval=00000001 ret=031d13f2 0009:Call KERNEL32.WriteProcessMemory(00000184,00340000,03891e18,00000066,0033ec88) ret=031d149c 0009:Ret KERNEL32.WriteProcessMemory() retval=00000001 ret=031d149c 0009:Call ntdll.RtlFreeHeap(03890000,00000000,03891e18) ret=031d1b77 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=031d1b77 0009:Call KERNEL32.ResumeThread(00000188) ret=031d14cb 0009:Ret KERNEL32.ResumeThread() retval=00000001 ret=031d14cb --- snip ---
The dll injection mechanism. Along with the thunk, code is written to remote process entry point (0x00554b3c -> PE entry point) to jump to the thunk code which loads the library and calls the export. Remote process execution is resumed which should ideally load the dll (and restore the entry).
The anomaly with your trace log is here:
"Razor.exe":
--- snip --- ... 0009:Call PE DLL (proc=0x7ef41110,module=0x7ef30000 L"mscoree.dll",reason=WINE_PREATTACH,res=(nil)) 0009:Ret PE DLL (proc=0x7ef41110,module=0x7ef30000 L"mscoree.dll",reason=WINE_PREATTACH,res=(nil)) retval=0 0009:Call PE DLL (proc=0x7efc8e30,module=0x7ef60000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) 0009:Ret PE DLL (proc=0x7efc8e30,module=0x7ef60000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x7ee3a490,module=0x7edb0000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) 0009:Ret PE DLL (proc=0x7ee3a490,module=0x7edb0000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x79002c77,module=0x79000000 L"mscoree.dll",reason=PROCESS_ATTACH,res=0x1) ... --- snip ---
"C:\Program Files\EA Games\Ultima Online 2D Client\client.exe":
--- snip --- ... 0022:Call PE DLL (proc=0x7efc8e30,module=0x7ef60000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) 0022:Ret PE DLL (proc=0x7efc8e30,module=0x7ef60000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0022:Call PE DLL (proc=0x7ee46490,module=0x7edc0000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) 0022:Ret PE DLL (proc=0x7ee46490,module=0x7edc0000 L"KERNEL32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0022:Call PE DLL (proc=0x7e98a490,module=0x7e950000 ... --- snip ---
Kernel32.dll gets different image bases in different virtual address spaces and additionally it's not getting its preferred base at all (along with ntdll). Do you run a Linux distribution which has virtual address space randomization enabled by chance?
"cat /proc/sys/kernel/randomize_va_space"
Also try to attach to Razor process with "winedbg" and do "info share". Attach output to bug to have the usual virtual address space layout on your system reviewed.
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #14 from Anastasius Focht focht@gmx.net 2009-06-17 17:37:49 --- Hello,
--- quote --- Also try to attach to Razor process with "winedbg" and do "info share". Attach output to bug to have the usual virtual address space layout on your system reviewed. --- quote ---
Additionally please do the following:
1. Use "ps" to find out unix pid of Razor.exe 2. "cat /proc/<pid>/maps" and attach to bug
Thanks,
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #15 from Philip Nilsson leffeman@gmail.com 2009-06-18 10:30:23 ---
"cat /proc/sys/kernel/randomize_va_space"
I've tried disabling it before, with the result that the application would always crash. I tried it again, and now it works every time! (Even other hooking applications that I've never been able to get working.) A bisect shows that it works after commit 8e16e7871063df35ca3a6de6fb165767c00bd087 is applied.
This is strange, because I am pretty sure I tried disabling ASLR later than that patch with crashing as the result. It is possible that I had that patch reverted at the time though (it was causing another bug).
I can't see how this patch might be relevant, though.
http://bugs.winehq.org/show_bug.cgi?id=15649
--- Comment #16 from Anastasius Focht focht@gmx.net 2009-06-18 14:53:56 --- Hello,
--- quote --- I've tried disabling it before, with the result that the application would always crash. I tried it again, and now it works every time! (Even other hooking applications that I've never been able to get working.) A bisect shows that it works after commit 8e16e7871063df35ca3a6de6fb165767c00bd087 is applied. --- quote ---
That commit is most likely not the cause of this behaviour. Maybe you had a poised source/build tree. Other causes can be prelink which sometimes leads to weird behaviour (improperly configured/run intervals) or Linux kernels where ASLR was broken.
Since it's working for you now, I suggest to mark this bug "invalid".
Maybe you can add a note to UO appdb entry, describing the problem with "Razor" tool and solution. That way other users benefit from it and don't fall into same trap.
Regards
http://bugs.winehq.org/show_bug.cgi?id=15649
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #17 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-18 22:21:38 --- Per Anastasius' investigation.
http://bugs.winehq.org/show_bug.cgi?id=15649
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-18 22:22:05 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=15649
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxmad@gmail.com
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 2009-07-26 01:55:10 --- *** Bug 19461 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org