http://bugs.winehq.org/show_bug.cgi?id=16051
Summary: LOTRO launcher fails on startup Product: Wine Version: 1.1.8 Platform: PC-x86-64 URL: http://download.lotro.level3.turbine.com/largecontent/lo tro/book14/downloader/live/standardres/LOTRO-US-Book14- Downloader-StandardRes.exe OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: hans@meelstraat.net
Created an attachment (id=17279) --> (http://bugs.winehq.org/attachment.cgi?id=17279) console messages
Steps to reproduce:
0. rm -rf ~/.wine 1. download lotro installer from URL above 2. run the installer, it should run a subinstaller for dotnet 1.1 3. run TurbineLauncher.exe from the directory where lotro was installed
This will pop up a dialog saying:
"Fatal execution engine error".
And if you click that away you'll get another one:
"Failed to load resources from resource file" "Please check your Setup"
http://bugs.winehq.org/show_bug.cgi?id=16051
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2008-11-18 10:18:27 --- Created an attachment (id=17347) --> (http://bugs.winehq.org/attachment.cgi?id=17347) CLR backtrace
I don't recall the exact steps but at some during my investigations a dialog popped up from which I could copy this managed code backtrace.
http://bugs.winehq.org/show_bug.cgi?id=16051
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-11-19 18:04:09 --- Hello,
--- quote --- 1. download lotro installer from URL above 2. run the installer, it should run a subinstaller for dotnet 1.1 --- quote ---
You forgot to mention that the installer downloads a whopping 5.5 GiB first - before doing anything useful :)
--- snip --- [focht@localhost lotr]$ ls -lsa total 5762640 4 drwxrwxr-x 2 focht focht 4096 2008-11-19 22:38 . 4 drwxrwxr-x 9 focht focht 4096 2008-11-18 21:27 .. 824548 -rw-rw-r-- 1 focht focht 843503843 2008-11-18 21:15 lotrosetup-1a.bin 927904 -rw-rw-r-- 1 focht focht 949237987 2008-11-18 22:02 lotrosetup-1b.bin 927904 -rw-rw-r-- 1 focht focht 949237987 2008-11-18 22:31 lotrosetup-1c.bin 927904 -rw-rw-r-- 1 focht focht 949237987 2008-11-18 23:00 lotrosetup-1d.bin 927904 -rw-rw-r-- 1 focht focht 949237987 2008-11-18 23:26 lotrosetup-1e.bin 927904 -rw-rw-r-- 1 focht focht 949237987 2008-11-18 23:56 lotrosetup-1f.bin 296964 -rw-rw-r-- 1 focht focht 303787822 2008-11-19 00:06 lotrosetup-1g.bin 868 -rwxrwxr-x 1 focht focht 881560 2008-11-19 00:06 lotrosetup.exe 732 -rw-rw-r-- 1 focht focht 742784 2008-11-18 20:24 LOTRO-US-Book14-Downloader-StandardRes.exe --- snip ---
Although the installer succeeds in the end, it contains a couple of more or less known/reported bugs which are not subject of this bug report.
--- quote --- 3. run TurbineLauncher.exe from the directory where lotro was installed
This will pop up a dialog saying:
"Fatal execution engine error".
And if you click that away you'll get another one:
"Failed to load resources from resource file" "Please check your Setup" --- quote ---
You seem to get farther. Really no native gdiplus install/override? ... that would be cheating ;-)
GdipNewPrivateFontCollection stub is the first showstopper, it needs a real implementation.
--- snip --- $ wine ./TurbineLauncher.exe fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported fixme:shell:URL_ParseUrl failed to parse L"mscorlib" fixme:shell:URL_ParseUrl failed to parse L"System.Windows.Forms" fixme:shell:URL_ParseUrl failed to parse L"System.Windows.Forms" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing" fixme:mscoree:LoadLibraryShim (0x49b85e8 L"Gdiplus.dll", (nil), (nil), 0x32df18): semi-stub fixme:gdiplus:GdipNewPrivateFontCollection stub 0x49b8458 --- snip ---
The runtime callable wrapper (rcw)/interop maps GdipNewPrivateFontCollection's NotImplemented result to CLR NotImplementedException exception and throws a (first chance) exception of that type.
--- snip --- First chance exception generated: (0x049ccf24) <System.NotImplementedException> Unhandled exception generated: (0x049ccf24) <System.NotImplementedException> --- snip ---
The managed handler catches it and throws a TypeInitializationException CLR exception (class constructor method failed) to be handled by app.
--- snip --- First chance exception generated: (0x049ccf88) <System.TypeInitializationException> Unhandled exception generated: (0x049ccf88) <System.TypeInitializationException> _typeName=(0x049ccfcc) "com.turbine.launcher.Launcher" _className=<null> _exceptionMethod=<null> _exceptionMethodString=<null> _message=(0x049ce44c) "The type initializer for "com.turbine.launcher.Launcher" threw an exception." _innerException=(0x049ccf24) <System.NotImplementedException> _helpURL=<null> _stackTrace=(0x049ce548) array with dims=[12] _stackTraceString=<null> _remoteStackTraceString=<null> _remoteStackIndex=0x00000000 _HResult=0x80131534 _source=<null> _xptrs=0x00000000 _xcode=0xe0434f4d --- snip ---
This is unexpected for app (no other handler will swallow this one), hence either CLR debugger (if registered) or winedbg will be spawned.
--- snip --- ... wine: Unhandled exception 0xe0434f4d at address 0x7b8449b0 (thread 0039), starting debugger... wine: Call from 0x7b8449b0 to unimplemented function gdiplus.dll.GdiplusNotificationHook, aborting First chance exception generated: (0x049ce5b4) <System.Runtime.InteropServices.SEHException> --- snip ---
That second part reveals another shortcoming, GdiplusNotificationHook.
Your managed callstack looks like a different issue. The launcher process spawns several child processes which each end up in bugs. In such case it's better to use at least +tid,+process debug channels to get sorted out where the exception/dialog actually originates from.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2008-11-20 04:50:00 --- (In reply to comment #2)
wine: Unhandled exception 0xe0434f4d at address 0x7b8449b0 (thread 0039), starting debugger... wine: Call from 0x7b8449b0 to unimplemented function gdiplus.dll.GdiplusNotificationHook, aborting First chance exception generated: (0x049ce5b4) <System.Runtime.InteropServices.SEHException> --- snip ---
That second part reveals another shortcoming, GdiplusNotificationHook.
Actually that one is probably not needed. When a stub exception is continued, execution will proceed into the next stub defined for that dll and cause another exception, it doesn't mean that the app called that function.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #4 from Hans Leidekker hans@meelstraat.net 2008-11-20 06:23:55 ---
Really no native gdiplus install/override? ... that would be cheating ;-)
You're right, this error only shows up after setting an override for gdiplus, sorry. So here's the correct recipe:
0. rm -rf ~/.wine 1. download lotro installer from URL above 2. winetricks dotnet11 3. run the installer 4. run TurbineLauncher.exe from the directory where lotro was installed
I've believe I've found the cause of one thread going haywire. The thread opens this registry key:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
And then wants to read value "First Counter" which is missing on Wine. This may be related to missing WBEM support, I'm not sure. Perhaps it should have been created during installation of the dotnet runtime?
If I create a "First Counter" value by hand the thread proceeds to call CreateFileMappingW("Global\netfxcustomperfcounters.1.0"), MapViewOfFile and then reads from this view. If my understanding of this subject is right this is not going to work in Wine.
I was hoping there would be a way to disable performance counters in dotnet but I haven't been able to find one. Removing the registry key did not help.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #5 from Anastasius Focht focht@gmx.net 2008-11-20 16:12:57 --- Hello,
--- quote --- Actually that one is probably not needed. When a stub exception is continued, execution will proceed into the next stub defined for that dll and cause another exception, it doesn't mean that the app called that function. --- quote ---
Maybe you misread ... it's not the infamous "unimplemented function" exception. The stub returns gdiplus specific "not implemented" code which gets thrown as CLR exception by .NET runtime callable wrapper.
--- snip dlls/gdiplus/font.c --- GpStatus WINGDIPAPI GdipNewPrivateFontCollection(GpFontCollection** fontCollection) { FIXME("stub %p\n", fontCollection);
if (!fontCollection) return InvalidParameter;
return NotImplemented; } --- snip dlls/gdiplus/font.c ---
--- snip --- 0033:Call KERNEL32.LoadLibraryExW(0032da7c L"c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\gdiplus.dll",00000000,00000008) ret=791b7b63 0033:Call PE DLL (proc=0x60c37a2c,module=0x60c10000 L"gdiplus.dll",reason=PROCESS_ATTACH,res=(nil)) ... 0033:Call gdiplus.GdiplusStartup(7b59017c,00166ac8,0032df04) ret=003ea442 0033:trace:gdiplus:GdiplusStartup 0x7b59017c 0x166ac8 0x32df04 0033:trace:gdiplus:GdiplusStartup GdiplusStartupInput 1 (nil) 1 0 0033:Ret gdiplus.GdiplusStartup() retval=00000000 ret=003ea442 ... 0033:Call KERNEL32.GetProcAddress(60c10000,7b592860 "GdipNewPrivateFontCollection") ret=791e0ce5 0033:Ret KERNEL32.GetProcAddress() retval=60c14aac ret=791e0ce5 ... 0033:Call gdiplus.GdipNewPrivateFontCollection(049b8458) ret=003ea902 0033:fixme:gdiplus:GdipNewPrivateFontCollection stub 0x49b8458 0033:Ret gdiplus.GdipNewPrivateFontCollection() retval=00000006 ret=003ea902 ... 0033:Call KERNEL32.RaiseException(e0434f4d,00000001,00000000,00000000) ret=7921020d ... --- snip ---
Later GdiplusNotificationHook proc is explicitly queried and called by .NET CLR, most likely to propagate/pass initialization/shutdown events.
--- snip --- 0033:Call KERNEL32.GetProcAddress(60c10000,7b59b351 "GdiplusNotificationHook") ret=791e0ce5 0033:Ret KERNEL32.GetProcAddress() retval=60c12b10 ret=791e0ce5 0033:Call ntdll.RtlTryEnterCriticalSection(001537a0) ret=791b3451 0033:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=791b3451 0033:Call KERNEL32.RaiseException(80000100,00000001,00000002,0032e574) ret=60c37b61 0033:trace:seh:raise_exception code=80000100 flags=1 addr=0x7b8449b0 0033:trace:seh:raise_exception info[0]=60c37be0 0033:trace:seh:raise_exception info[1]=60c38ad8 wine: Call from 0x7b8449b0 to unimplemented function gdiplus.dll.GdiplusNotificationHook, aborting --- snip ---
MSDN: http://msdn.microsoft.com/en-us/library/ms534046.aspx
Small stubs for the gdiplus NotificationHook/NotificationUnhook procs should be sufficient.
--- snip --- 002f:Call KERNEL32.GetProcAddress(6a890000,7b59b351 "GdiplusNotificationHook") ret=791e0ce5 002f:Ret KERNEL32.GetProcAddress() retval=6a89d774 ret=791e0ce5 002f:Call ntdll.RtlTryEnterCriticalSection(0014b340) ret=791b3451 002f:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=791b3451 002f:Call gdiplus.GdiplusNotificationHook(7b590180) ret=003ea902 002f:trace:gdiplus:NotificationHook 0x7b590180 002f:Ret gdiplus.GdiplusNotificationHook() retval=00000000 ret=003ea902 002f:Ret window proc 0x17851e (hwnd=0x3003e,msg="SystemEventsThreadCallbackMessage",wp=00000000,lp=00000000) retval=00000000 --- snip ---
Regarding the initial bug ... it seems all gdiplus functions dealing with font collections are just stubs that need to be worked on.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #6 from Anastasius Focht focht@gmx.net 2008-11-20 18:53:40 --- Hello,
--- quote --- I've believe I've found the cause of one thread going haywire. The thread opens this registry key:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
And then wants to read value "First Counter" which is missing on Wine. This may be related to missing WBEM support, I'm not sure. Perhaps it should have been created during installation of the dotnet runtime?
If I create a "First Counter" value by hand the thread proceeds to call CreateFileMappingW("Global\netfxcustomperfcounters.1.0"), MapViewOfFile and then reads from this view. If my understanding of this subject is right this is not going to work in Wine.
I was hoping there would be a way to disable performance counters in dotnet but I haven't been able to find one. Removing the registry key did not help. --- quote ---
Well, disabling the use of performance counters/data is not possible. There are several integral parts of .NET which make use of System.Diagnostics.PerformanceCounter component, backed by registry.
That specific ".NET CLR Networking" key problem you mentioned is caused by System.Net.Sockets component which tries to query the established connections perf counter. Harmless because the (first chance) exception gets caught. Async http web requests will succeed despite the failure.
WBEM/WMI is another big hole in wine. The first indication are errors like this:
--- snip --- err:ole:CoGetClassObject class {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} not registered err:ole:create_server class {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} could be created for context 0x15 --- snip ---
which basically means that the COM class factory for WbemDefaultPathParser failed (0x80004002 -> E_NOINTERFACE). .NET CLR will throw System.TypeInitializationException for System.Management.ManagementPath
The app makes use of System.Management component to query all sorts of informational system data. Fortunately failed native WMI requests don't cause any harm because all managed exceptions are caught by app handlers.
There seems to be a thread stack overflow (recursive SEH chain) in rss feed component which needs more investigation.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #7 from Hans Leidekker hans@meelstraat.net 2008-11-25 08:34:20 --- I stubbed out gdiplus to the point that native should not be needed anymore to reach this exception.
I looked at the RSS related exception for a bit but found nothing conclusive. Wireshark tells me that the feed is received in full and since Wireshark is able to parse it I assume it's not something in the RSS feed itself.
I also suspected our dotnet installation for while so I copied one from Windows, but it made no difference.
http://bugs.winehq.org/show_bug.cgi?id=16051
Jeremy White jwhite@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jwhite@codeweavers.com
--- Comment #8 from Jeremy White jwhite@codeweavers.com 2009-01-03 09:57:13 --- I've spent some time on this, and have a few bits of further information.
First, in addition to the 'Fatal Execution Error' and the 'Failed to load resources' error that are very common, you also get a divide by zero error at times. This appears to be related to NtQuerySystemInformation(SystemProcessorPerformanceInformation,...). Specifically, you see a thread get the sspi, Sleep(500), and get the sspi and then a divide by zero. I've run some tests on my Linux boxen, and in fact, I'll see the usr clock ticks not change sometimes. So it seems to be a Linux -> Windows difference, in that a Sleep(500) guarantees the user time will change on Windows, but apparently not on Linux. I haven't probed much further, but I'll attach the clockbias hack I used to prevent this from happening.
Second, there seems to be a SEGV that triggers a stack recursion that eventually blows the stack. That is, I'll see a RaiseException(c0000005,...), followed by exception handling code (you can see it looking for 'EHGolden'), and then exception handling code loops again and again, and then the stack blows. I believe this is what triggers the Fatal Execution Error, but the threads are sufficiently disconnected that I may be wrong.
You can fudge that if you prevent the RSS and launcher thread connect()s from firing. That actually gets the launcher to go much further and even start updating files. I've attached a hack for that as well. Of course, with that, you go on to fail after downloading for perhaps 30-40 seconds. Start it up, you get 30-40 more seconds of downloads, and then another crash. I haven't probed those further failures, they may provide some clues.
There also seems to clearly be just some flat out instability in running .NET 1.1. If you install the .net installer, you'll sometimes get a 'failed to load resources' error. And, looking at normal wine fixmes from installing .NET 1.1 and it's service pack, it sure smells like it does not fully install.
p.s. Note that you need Alexandre's server crash fix as of January 3rd, or you'll have the wine server dropping core on you.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #9 from Jeremy White jwhite@codeweavers.com 2009-01-03 09:57:54 --- Created an attachment (id=18428) --> (http://bugs.winehq.org/attachment.cgi?id=18428) Hack to prevent a divide by zero exception
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #10 from Jeremy White jwhite@codeweavers.com 2009-01-03 09:58:18 --- Created an attachment (id=18429) --> (http://bugs.winehq.org/attachment.cgi?id=18429) Hack to prevent the RSS and launcher feeds from connecting
http://bugs.winehq.org/show_bug.cgi?id=16051
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #11 from Jeremy White jwhite@codeweavers.com 2009-03-11 12:54:19 --- You get one new failure, with the new Gecko; LOTRO includes it's own js3250.dll. If you move that out of the way, then you get back to the more sporadic failures.
http://bugs.winehq.org/show_bug.cgi?id=16051
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #12 from Jeremy White jwhite@codeweavers.com 2009-06-07 20:01:44 --- Took another stab at this and spent a day or two on it. I tried to back track, and tested using only the hack to prevent the divide by zero exception.
There seems to be one fundamental issue - the Lotro exception handler seems to spin out of control, and dies of a stack over run. However, there seem to be two different, fairly reproducible, cases of failure.
The first one happens immediately after startup. You get: setup_exception_record nested exception on signal stack in thread 001d... and you're dead. You can connect with a debugger and hunt around, but nothing obvious jumps out.
The second one is the one that happens caused by the the RSS feed reading thread. This one is a c0000005 exception that goes into an infinite spin loop and eventually blows the stack. It happens after things begin to cook and we've started to put up the form.
There doesn't seem to be any certainty as to which of these two failures I'll get when I launch TurbineInvoker, but I always get one of them (more often the second than the first).
I spent a lot of time looking over the use of Overlapped io with winsock, along with IO Completion Ports, in the hope that something in the way the RSS feed was received was wrong. There is odd behavior, but it all seems intentional (and bug free :-/). That is, you'll have one thread do a WSARecv which sets up overlapped io. Another thread will do a GetQueuedCompletionStatus to pull the data, and then the first thread will repeat the WSARecv. Another thread might pull the next completion status, and so on, until you get to near the end of the RSS feed. Then we pull the last 6 bytes (a \r\n, 0^\r\n, and a ^\r\n) off with straight up recv()s of 2, 1, 2, and 2. Odd, but apparently intentional.
It certainly wouldn't hurt to write some good tests for this; there may be some gotchas hiding in there, particularly mixing overlapped w/io completion routines and 'normal' recv()s, but I couldn't find any.
Someone smarter than I am may also be more able to extract better information from winedbg as to what's causing the c0000005 exception.
http://bugs.winehq.org/show_bug.cgi?id=16051
Alan Jackson ajackson@bcs.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson@bcs.org.uk
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #13 from Jeremy White jwhite@codeweavers.com 2009-07-06 16:41:29 --- With git as of today, this behavior has changed. You now get an error message trying to connect to the lotro servers, but you do not get the 'normal' exception failure.
This is likely a new bug that is preventing lotro from getting to the 'normal' bug, but it might be worth investigating.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #14 from Hans Leidekker hans@meelstraat.net 2009-07-07 02:16:45 --- For me it still fails with the old exception message on current git. Network problem?
I have been chasing some of the ole fixme's and added an implementation of CoGetContextToken, but it didn't make a difference.
This thread looks promising though: http://www.winehq.org/pipermail/wine-devel/2009-June/076673.html
The patches in that thread don't fix the launcher but they do affect its behavior.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #15 from Jeremy White jwhite@codeweavers.com 2009-07-07 11:53:09 --- My mistake. I'd added 'options inet6' to my /etc/resolv.conf when testing something else, and that causes the error I was seeing.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #16 from Jeremy White jwhite@codeweavers.com 2009-07-07 14:31:48 --- Indeed. Experimenting with those patches do change launcher behavior.
The most consistent behavior I saw was if I zero'd the memory returned from VirtualAlloc when type ^ MEM_COMMIT. That triggers an early c0000005 exception every time.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #17 from Jeremy White jwhite@codeweavers.com 2009-07-13 15:25:56 --- Blech. My tests with those patches were invalid. You do get somewhat inconsistent behavior at startup. Mostly you'll get a c0000005 exception that will start a chain reaction leading to death. But other times you'll get a hang with some other thread dying off unexpectedly.
I have a hack patch that I started using to speed up my testing; it's not a fix (it's an anti-fix :-/); it just gets those c0000005 exceptions to crash out more quickly to make them easier to study. I'll attach it for future reference.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #18 from Jeremy White jwhite@codeweavers.com 2009-07-13 15:31:45 --- Created an attachment (id=22363) --> (http://bugs.winehq.org/attachment.cgi?id=22363) Patch to shortcircuit c0000005 exception handler, avoiding stack overflow, and letting us see the failure more quickly.
http://bugs.winehq.org/show_bug.cgi?id=16051
Athrun samurai_no_densetsu@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |samurai_no_densetsu@yahoo.e | |s
--- Comment #19 from Athrun samurai_no_densetsu@yahoo.es 2011-06-19 06:46:07 CDT --- LOTRO launcher is actually able to run with winetricks and dotnet, refer to bug 27513. Although I was not able to enter to a game server with the launcher I think that this issue is actually solved.
http://bugs.winehq.org/show_bug.cgi?id=16051
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | Severity|enhancement |normal
--- Comment #20 from Anastasius Focht focht@gmx.net 2011-06-19 08:11:29 CDT --- Hello,
--- quote --- LOTRO launcher is actually able to run with winetricks and dotnet, refer to bug 27513. Although I was not able to enter to a game server with the launcher I think that this issue is actually solved. --- quote ---
you probably tested with a recent version of LOTRO client. Unfortunately turbine has removed that old client this bug started with, it seems no more accessible:
http://download.lotro.level3.turbine.com/largecontent/lotro/book14/downloade...
I still have that old version around, it needs .NET Framework 1.1 in clean WINEPREFIX, no native gdiplus. Indeed most of issues discussed here seem to have been resolved - unfortunately this bug mixes several of them.
The game update still has issues: connecting, examine and updating (patching) seems to work. At the point of "examine game data" it gets CLR StackOverflowException
--- snip --- ... fixme:ole:NdrCorrelationFree (0xd83e368): stub fixme:ole:Context_CC_ContextCallback (0x1af7f0/0x1af7f4)->(0x7920c9b1, 0x33e9ec, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, (nil)) fixme:ole:NdrCorrelationInitialize (0x33eaa0, 0x33e6a0, 1024, 0x0): stub err:ole:ClientRpcChannelBuffer_SendReceive called from wrong apartment, should have been 0x3c0000cafe fixme:ole:NdrCorrelationFree (0x33eaa0): stub fixme:ole:Context_CC_ContextCallback (0x1af7f0/0x1af7f4)->(0x7920c9b1, 0x33ebdc, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, (nil)) err:ole:marshal_object object doesn't expose interface {df0b3d60-548f-101b-8e65-08002b2bd119}, failing with error 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002
Unhandled Exception: StackOverflowException. --- snip ---
Not sure if this bug should be still pursued as the original launcher is no more available. Also this issue is different and not mentioned here. I'd rather close this bug and start over with new ones.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #21 from Athrun samurai_no_densetsu@yahoo.es 2011-06-19 10:03:14 CDT --- Hello Anastasius,
Thank you very much for your kind answer.
I'm aware of what you are telling as I been mantained the LOTRO AppDB page along with Daniel Santos, Mikko Korkalo and other volunteers since 2008. Unluckily for us that's the way Turbine works, if you check obsolete versions of LOTRO on the AppDB you will find that almost every revision of LOTRO had his own way to install. What I mean?. That by example you cannot install LOTRO with the original CD (and you had to rsync from a Windows install) but you can install without problems a Book 12 standalone client and upper, and more funnier, if you rsynced an original CD install you will be not able to update (as the updater doesn't update the game exe and patcher).
Turbine isn't constant. I archieved three times to give instructions to archieve a good and current install without too many hacks, thrice times (or more) it changed, there's huge differences between clients, that lead to things like, if you did a current clean install LOTRO will run without "winetricks d3dx9" but if you updated from a not so old client you will need, there are differeces between LOTRO US (Turbine) and LOTRO EU (Codemasters) clients, depending how and when did you installed your client can have as less as 3.500 archives or even more than 11.000, and so I could go on the rest of the day...
So, what I learned and what's my point of view as mantainer of LOTRO? Fixing old Turbine's stuff does not assures you anything, as almost on every release they change something (and give headaches to all people using wine), so if any dev wants to fix this issue, I won't be opposing, but the experience tells me, keep current, keep giving good support, be on the present and try your best.
All the best.
Athrun
http://bugs.winehq.org/show_bug.cgi?id=16051
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dank@kegel.com Resolution| |ABANDONED
--- Comment #22 from Dan Kegel dank@kegel.com 2011-06-19 13:44:40 CDT --- OK, 'abandoned' seems like the right resolution for this version, then.
http://bugs.winehq.org/show_bug.cgi?id=16051
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #23 from Austin English austinenglish@gmail.com 2011-07-07 16:16:24 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #24 from Dan Kegel dank@kegel.com 2011-11-16 15:18:19 CST --- I'm seeing problems like this when installing the similar app DDO from http://www.fileplanet.com/202160/200000/fileinfo/Dungeons-&-Dragons-Onli...
http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #25 from Austin English austinenglish@gmail.com 2011-11-16 15:47:05 CST --- (In reply to comment #24)
I'm seeing problems like this when installing the similar app DDO from http://www.fileplanet.com/202160/200000/fileinfo/Dungeons-&-Dragons-Onli...
Try installing dotnet11sp1, I've noticed crashes on windows too, unless the service pack is installed.
-
wine-bugs＠winehq.org