http://bugs.winehq.org/show_bug.cgi?id=20296
Summary: League of Legends: crash after eula Product: Wine Version: 1.1.31 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: puciek@gmail.com
Created an attachment (id=23993) --> (http://bugs.winehq.org/attachment.cgi?id=23993) Crash log
After launching LoL and accepting license + ToS, it will throw wine errors and hang. Attaching log
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2009-10-09 12:50:53 --- Hi.
Try with 'winetricks cc580' and report results please.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #2 from Tymoteusz Paul puciek@gmail.com 2009-10-09 12:58:10 --- Created an attachment (id=23994) --> (http://bugs.winehq.org/attachment.cgi?id=23994) Log with cc580 installed
Still crash, attaching log
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com 2009-10-09 13:04:14 --- (In reply to comment #2)
Created an attachment (id=23994)
--> (http://bugs.winehq.org/attachment.cgi?id=23994) [details]
Log with cc580 installed
Still crash, attaching log
Ok. What about dropping all overrides including these (and comctl32 too of course): --- PE 70bd0000-70c35000 Deferred shlwapi PE 71000000-71149000 Deferred shdocvw --- ?
If there's existing bug that is blocked without these overrides please mention it.
http://bugs.winehq.org/show_bug.cgi?id=20296
Tymoteusz Paul puciek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #23994|0 |1 is obsolete| |
--- Comment #4 from Tymoteusz Paul puciek@gmail.com 2009-10-09 13:14:32 --- Created an attachment (id=23995) --> (http://bugs.winehq.org/attachment.cgi?id=23995) Clean prefix with just comctrl override
Ok, i've created clean wineprefix for LoL since this is getting some attention ;) Posting log from clean prefix with just cc580 as override
http://bugs.winehq.org/show_bug.cgi?id=20296
Tymoteusz Paul puciek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://cds008.am4.hwcdn.net | |/h2f4b5v4/cds/installer/lol | |/LOL_Setup.exe
--- Comment #5 from Tymoteusz Paul puciek@gmail.com 2009-10-09 13:22:07 --- Since testing this bug does not require LoL account, I'm attaching link to place where you can download LoL setup.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #6 from Hans Leidekker hans@meelstraat.net 2009-10-10 13:58:28 --- Created an attachment (id=24015) --> (http://bugs.winehq.org/attachment.cgi?id=24015) hnetcfg: Add a stub implementation of INetFwOpenPorts and INetFwOpenPort.
Can you try this patch?
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #7 from Tymoteusz Paul puciek@gmail.com 2009-10-10 14:24:52 --- Created an attachment (id=24017) --> (http://bugs.winehq.org/attachment.cgi?id=24017) Crash log with path applied
Sadly still crashes, attaching log
http://bugs.winehq.org/show_bug.cgi?id=20296
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24017|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #8 from Tymoteusz Paul puciek@gmail.com 2009-10-24 03:03:53 --- Still present in 1.1.32
http://bugs.winehq.org/show_bug.cgi?id=20296
Matej Spindler matej.spindler@auspuh.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matej.spindler@auspuh.com
--- Comment #9 from Matej Spindler matej.spindler@auspuh.com 2009-11-02 10:26:05 --- I can confirm this bug!
This game is using Adobe AIR for launcher and lobby. Installer installs it and it looks like successful install. I hope this info helps!
http://bugs.winehq.org/show_bug.cgi?id=20296
urden@live.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from urden@live.fr 2009-11-07 14:07:32 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20296
Lubosz Sarnecki lubosz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lubosz@gmail.com
--- Comment #11 from Lubosz Sarnecki lubosz@gmail.com 2009-11-16 13:14:03 --- Output / Debug changes when i install dcom98 from winetricks.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #12 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-16 13:20:04 --- (In reply to comment #11)
Output / Debug changes when i install dcom98 from winetricks.
DCOM98 can't work properly in Wine, don't install it.
http://bugs.winehq.org/show_bug.cgi?id=20296
JB juggler885@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juggler885@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Michael Grigoriev mag@luminal.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mag@luminal.org
--- Comment #13 from Michael Grigoriev mag@luminal.org 2009-11-24 23:26:25 --- Just to confirm - when you say the game crashes after accepting EULA/TOS, do you mean the game itself, or the installer?
I am unable to get through the install process. The base game installs fine (I am able to accept EULA, etc), but then it goes to install Adobe Air runtimes, and dies somewhere inside webkit.dll. I am able to reproduce the same problem if I try to install the Adobe Air myself.
http://bugs.winehq.org/show_bug.cgi?id=20296
Manuel C. Bihl Manuel.Bihl@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Manuel.Bihl@gmx.de
--- Comment #14 from Manuel C. Bihl Manuel.Bihl@gmx.de 2009-11-24 23:29:33 --- (In reply to comment #13)
Just to confirm - when you say the game crashes after accepting EULA/TOS, do you mean the game itself, or the installer?
I am unable to get through the install process. The base game installs fine (I am able to accept EULA, etc), but then it goes to install Adobe Air runtimes, and dies somewhere inside webkit.dll. I am able to reproduce the same problem if I try to install the Adobe Air myself.
The Beta Version did not need air, so the installer quit nicely. But when you start Lol itself, you have to accept the eula, and after this it crashs. With the release Version I confirm your behavior.
http://bugs.winehq.org/show_bug.cgi?id=20296
Christoph Hohmann reboot@gmx.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |reboot@gmx.ch
--- Comment #15 from Christoph Hohmann reboot@gmx.ch 2010-01-10 09:23:54 --- The problem seems to be that the launcher tries to use a com object with the CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2} which can not be created. The launcher seems to assume that the was created without checking if it really worked.
The first problem is that the installer does not create the CLSID and AppID entries in the registry for the com object. I'll attach a registry file that will create the entries I got from a windows installation, you might need to adjust the path of the DLL.
The second problem is that lol.launcher tries to load a COM object that has only a InprocServer32 entry with the CLSCTX_LOCAL_SERVER flag. On windows the DLL is loaded into a out-of-process surrogate server. From what I could understand from the wine's code it does not support this. Wine can only start com servers if they have a LocalService entry under the AppId entry.
To check if the crash is really related to this I started lol.launcher in the wine debugger and put a break point CoGetClassObject. Every time the debugger stopped in the function i checked which CLSID should be loaded and when lol.launcher tried to load {629f8434-0530-41e6-b7c5-61a82faa3df2} I modified the paramter dwClsContext from CLSCTX_LOCAL_SERVER (0x4) to CLSCTX_INPROC_HANDLER (0x1). Like this the DLL in loaded into the lol.launcher instead of running it into a seperate process. After i continued the execution of the process it did not crash anymore and the launcher window opened. It even downloaded and applied the latest patch.
A proper solution would probably be to check for the DllSurrogate key of the AppID entry in the registry and then try to start a surrogate server. It seems lol.launcher does this because these are started from a windows service and have other permissions then the process that loaded the com object (see http://leagueoflegends.com/board/showthread.php?p=79566#post79566). So may not be needed on wine and the DLL can just be loaded in-process.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #16 from Christoph Hohmann reboot@gmx.ch 2010-01-10 09:25:40 --- Created an attachment (id=25646) --> (http://bugs.winehq.org/attachment.cgi?id=25646) Registry keys for the COM class missing after running the installer
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #17 from Jan Zerebecki jan.wine@zerebecki.de 2010-01-11 13:28:32 --- Created an attachment (id=25672) --> (http://bugs.winehq.org/attachment.cgi?id=25672) ole-force-inproc-instead-of-local.patch
This probably should do the same as what you did in the debugger, right? Btw: CLSCTX_INPROC_SERVER == 0x1 . But it doesn't open any window for me, it seems like it just exits again.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #18 from Jan Zerebecki jan.wine@zerebecki.de 2010-01-11 16:50:54 --- With this patch the installer correctly registers the dll and thus the .reg file is not necessary (checked with regedit and it gets loaded). My test was with 1.1.36 + my hacks.git + this patch in a new, clean wineprefix (no winetricks or other natives/overrides).
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #19 from Christoph Hohmann reboot@gmx.ch 2010-01-12 14:50:35 --- I tried it with a clean wineprefix myself now. With your patch the lol.launcher.exe does not crash, without it crashes. But the launcher itself did not work, like it did with my normal wineprefix. I had to install "ie6" with winetricks before the launcher really worked. Without "ie6" I also got an error during the setup when DirectX is installed, the installer just reported an error and existed. With the patch and a clean wineprefix I could also start the client from the launcher (with my normal wineprefix the buttons in the launcher are missing, but they are still clickable if you know where they are). But the client then fails to login to the game and exists after that.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #20 from Jan Zerebecki jan.wine@zerebecki.de 2010-01-12 16:25:56 --- Created an attachment (id=25700) --> (http://bugs.winehq.org/attachment.cgi?id=25700) debug log of the launcher
The patcher from the launcher writes a few errors into the file patcher_lib.log (unable to get function [__launcher_getVersion], etc.). My guess is that the jscript fixmes are related to these errors. (That is in a clean wineprefix.)
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #21 from Jan Zerebecki jan.wine@zerebecki.de 2010-01-12 17:14:19 --- Created an attachment (id=25701) --> (http://bugs.winehq.org/attachment.cgi?id=25701) debug log of failure to log in
Now with winetricks ie6, I also get a failure when logging in (talking about a failed connection). The log shows a few secur32/gnutls errors, so I guess they show the problem.
http://bugs.winehq.org/show_bug.cgi?id=20296
desterigo gewinnlars@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gewinnlars@web.de
--- Comment #22 from desterigo gewinnlars@web.de 2010-01-28 13:49:39 --- Ok if I start the LolClient.exe I run into a Maestro Connection Error (because Maestro its only started with the lol.launcher.exe, which does not run for me.. for mor Info see this Thread: http://www.leagueoflegends.com/board/showthread.php?p=577901#post577901 ) but there is hope: The official LoL Website ( http://kb.leagueoflegends.com/questions/4/Maestro+General+Information ) says: "Once Adobe AIR 2.0 becomes available sometime after the beginning of the year, we will likely discontinue use of Maestro. This will allow PVP.net to launch the game client directly and communicate directly with it. Until then, we have Maestro."
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #23 from Christoph Hohmann reboot@gmx.ch 2010-01-28 16:12:33 --- As a software developer I would suggest that not every issue why LoL does not run is added to this bug. It is about the crash of the launcher, which is caused by an unimplemented Windows API in Wine as shown with the small hack. Other issues should probably be discussed in the AppDB entry for LoL or added as other bugs.
For your information, with the information and patch on this bug it is possible to run the launcher, patch the client, start the PVP.net client and with Wine 1.1.37 and the last LoL patch it is even possible to login, but if you try to start a game the real game client crashes due to an unimplemented DirectX API.
http://bugs.winehq.org/show_bug.cgi?id=20296
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #24 from Dan Kegel dank@kegel.com 2010-03-21 22:21:53 --- Please file a new bug for the DirectX problem, with a complete recipe for repeating.
http://bugs.winehq.org/show_bug.cgi?id=20296
Amos Wenger amoswenger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amoswenger@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Matej Spindler spindler.matej@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|matej.spindler@auspuh.com |
http://bugs.winehq.org/show_bug.cgi?id=20296
Nick Bowler nbowler@draconx.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nbowler@draconx.ca
http://bugs.winehq.org/show_bug.cgi?id=20296
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbmj@verizon.net
--- Comment #25 from Austin English austinenglish@gmail.com 2010-08-19 02:59:17 --- *** Bug 22777 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20296
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #26 from Hans Leidekker hans@meelstraat.net 2010-08-19 10:02:10 --- The game installed here with the patch from comment #4, after running "winetricks ie6 adobeair" in a clean prefix. I didn't need the registry keys from comment #16.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #27 from Dan Kegel dank@kegel.com 2010-08-19 10:11:56 --- Right, I also used the patch and not the registry keys. I didn't need winetricks adobeair.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #28 from Austin English austinenglish@gmail.com 2010-08-19 12:06:20 --- (In reply to comment #26)
The game installed here with the patch from comment #4, after running "winetricks ie6 adobeair" in a clean prefix. I didn't need the registry keys from comment #16.
Don't you meant the patch from comment #17?
I can confirm the same, though there are other installer bugs to workaround (bug 22152, bug 24017, bug 24020).
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #29 from Hans Leidekker hans@meelstraat.net 2010-08-19 12:23:14 ---
Don't you meant the patch from comment #17?
Yes, of course. I needed winetricks adobeair because the updater tried to update the runtime and failed.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #30 from Christoph Hohmann reboot@gmx.ch 2010-08-19 12:41:09 --- It seems the registry keys are not need anymore. Maybe it was just a messed up installation. They were correctly created the last time I tried to install LoL. The launcher crashes when it can not load the COM class, so the missing keys had the same effect as the real problem that Wine does not support loading COM classes in surrogate servers.
http://bugs.winehq.org/show_bug.cgi?id=20296
Severin Heiniger severinheiniger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |severinheiniger@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Anton Romanov theli@ukr.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli@ukr.net
http://bugs.winehq.org/show_bug.cgi?id=20296
Artem Semendyaev lifeissecret@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lifeissecret@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Renaud Chaput renchap@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |renchap@gmail.com
--- Comment #31 from Renaud Chaput renchap@gmail.com 2011-03-15 08:41:54 CDT --- Latest LoL version does not work for me with wine 1.3.14, but works with the ole-force-inproc-instead-of-local.patch patch.
Any news on the inclusion into a future wine release ?
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #32 from Christoph Hohmann reboot@gmx.ch 2011-03-15 14:04:19 CDT --- The patch is a hack, it doesn't make sense to include it in a Wine release.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #33 from Amos Wenger amoswenger@gmail.com 2011-03-15 14:09:53 CDT --- (In reply to comment #32)
The patch is a hack, it doesn't make sense to include it in a Wine release.
What, like this would be the first hack integrated in wine mainline? Haha :)
Seriously though, the real question is: does it break other applications. If not, I don't see why it couldn't be merged.
http://bugs.winehq.org/show_bug.cgi?id=20296
oiaohm oiaohm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm@gmail.com
--- Comment #34 from oiaohm oiaohm@gmail.com 2011-04-02 00:25:17 CDT --- (In reply to comment #33)
(In reply to comment #32)
The patch is a hack, it doesn't make sense to include it in a Wine release.
What, like this would be the first hack integrated in wine mainline? Haha :)
Seriously though, the real question is: does it break other applications. If not, I don't see why it couldn't be merged.
Serous. You don't know wine rules. No it would not be the first hack integrated into wine mainline. But it would be the first hack to get into mainline against the rules since the rules were formed. Please be aware this rules has been there for over 10 years.
This is not a functional stub. That is a permitted form of hack.
It is a operational altering hack. These have been found to be longterm major problem causing so are 100 percent classed as hacks never to be merged mainline. Since its crossing functionality that should not be related.
CLSCTX_LOCAL_SERVER should be implemented then the patch can be included.
Even if its ugly like duplicating CLSCTX_INPROC_SERVER code base to perform CLSCTX_LOCAL_SERVER tasks. So that CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER are two independent code lines and that LOCAL_SERVER can keep on progressing until it has full functionality.
Basically the patch is way way too small and could get in the way of creating the future functionality. So its forbin in it current form.
Basically to quote Ghostbusters. "Don't cross the streams".
Also lot of the hacks against the rules have been in a slow process of being removed since the rules where placed.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #35 from Dan Kegel dank@kegel.com 2011-04-02 10:19:49 CDT --- I like the Ghostbusters quote, but the short answer is: it's so wrong, it probably breaks other applications.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #36 from Austin English austinenglish@gmail.com 2011-04-02 13:33:15 CDT --- (In reply to comment #35)
I like the Ghostbusters quote, but the short answer is: it's so wrong, it probably breaks other applications.
A user reported adobe air not installating when using this patch in #winehq.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #37 from Amos Wenger amos@official.fm 2011-04-05 07:55:47 CDT --- Created an attachment (id=33948) --> (http://bugs.winehq.org/attachment.cgi?id=33948) ole-try-inproc-even-when-local.patch
(In reply to comment #34)
(In reply to comment #33)
(In reply to comment #32)
The patch is a hack, it doesn't make sense to include it in a Wine release.
What, like this would be the first hack integrated in wine mainline? Haha :)
CLSCTX_LOCAL_SERVER should be implemented then the patch can be included.
Even if its ugly like duplicating CLSCTX_INPROC_SERVER code base to perform CLSCTX_LOCAL_SERVER tasks. So that CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER are two independent code lines and that LOCAL_SERVER can keep on progressing until it has full functionality.
Okay, I understand, apologies for the making fun of.
So here's my attempt at an ugly patch ;) that duplicates INPROC_SERVER codebase in the LOCAL_SERVER code path. As far as I can tell, it allows me to launch LoL correctly, and it shouldn't break other applications, although I haven't tested yet.
I haven't fully understood what Christoph Hohmann said in comment #15 about checking the DllSurrogate key and starting a surrogate server - I'm very much an OLE noob, just trying to sort out through this mess reading a bit of msdn now and then.
Is there any drawback to the current approach? Ie. some cases where dwClsContext might have the CLSCTX_LOCAL_SERVER flag and it *should* fail to look up a given class, and with my patch it would (wrongly) succeed if we can find it inproc?
Or could we even consider a League-of-legends-specific fix? (ie. hardcoded check for CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2}). I really don't like app-specific hacks, but at least it wouldn't touch any other app afaik.
I'm really just looking for a solution so that wine mainline could run LoL only with a few winetricks (d3dx9, vcrun2005, ie6 - those seem to be the winning trio)
P.S: also, I wasn't too sure how to format my 'patch', it's really just the output of git diff right now, is there a better way?
http://bugs.winehq.org/show_bug.cgi?id=20296
Amos Wenger amos@official.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amos@official.fm
--- Comment #38 from Amos Wenger amos@official.fm 2011-04-05 07:58:13 CDT --- (In reply to comment #37)
So here's my attempt at an ugly patch ;)
Oh, I forgot to tell: it's a patch against my HEAD, which was git commit 5c57185060ce9863119d310ed380772866cb21bb at the time I wrote this patch.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #39 from Dan Kegel dank@kegel.com 2011-04-05 09:35:12 CDT --- Sorry, that's even worse. The objection is that the patch is a kludge, whether or not it includes duplicated code.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #40 from Amos Wenger amos@official.fm 2011-04-05 09:40:50 CDT --- (In reply to comment #39)
Sorry, that's even worse. The objection is that the patch is a kludge, whether or not it includes duplicated code.
I agree, I understand this patch will never be accepted as-is, just trying to gain a little momentum. Can anyone give directions for a cleaner approach? Christoph seems to suggest that a "surrogate server" (not sure what it is) is needed, but ends his comment with "So may not be needed on wine and the DLL can just be loaded in-process." so I'm not sure what he really meant.
There's good will here, I just need better feedback :/
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #41 from oiaohm oiaohm@gmail.com 2011-04-05 23:25:18 CDT --- (In reply to comment #40)
(In reply to comment #39)
Sorry, that's even worse. The objection is that the patch is a kludge, whether or not it includes duplicated code.
I agree, I understand this patch will never be accepted as-is, just trying to gain a little momentum. Can anyone give directions for a cleaner approach? Christoph seems to suggest that a "surrogate server" (not sure what it is) is needed, but ends his comment with "So may not be needed on wine and the DLL can just be loaded in-process." so I'm not sure what he really meant.
There's good will here, I just need better feedback :/
First thing is understanding how CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER are different. So that you have the patch heading down the right line to implement CLSCTX_LOCAL_SERVER.
http://msdn.microsoft.com/en-us/library/ms693716%28v=vs.85%29.aspx Very important read on the subject.
Same process space as the caller is INPROC SERVER . Own process is LOCAL SERVER. Also as a own process is shared between all callers. This is why applications will snap if you just redirect LOCAL to INPROC. The reverse would have stood a kind of a chance but also would cause random breakages.
This is why I said you might have to duplicate sections of the INPROC code base into a new Local Server code base.
The pure difference between the two is why I said "Dr. Egon Spengler: Don't cross the streams.".
I guess never you watched ghost busters. Dr. Egon Spengler: Don't cross the streams. Dr. Peter Venkman: Why? Dr. Egon Spengler: It would be bad. Dr. Peter Venkman: I'm a little fuzzy on the whole "good/bad" thing, here. What do you mean, "bad"? Dr. Egon Spengler: Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
Anyone who watches the full movie at the end they do cross the streams and live but is a rare case event that you will live through it. Currently you are in that lucky location.
Basically you are doing something so far on the scale of bad really don't want to be doing that. Crossing INPROC functionally with LOCAL is crossing the streams.
INPROC and LOCAL are basically two different code paths. Local requires creating a new process and other things so it works right. Sections of Inproc operations maybe recyclable.
For a patch to be accepted that is kinda a hack. It will have to show a plan to get from the kind of a hack to correctly functional or at least it will not hinder getting to correct functionality.
Basically if I am quoting ghost busters to you have got something critically wrong.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #42 from Amos Wenger amos@official.fm 2011-04-06 04:46:05 CDT --- (In reply to comment #41)
(In reply to comment #40)
(In reply to comment #39)
Sorry, that's even worse. The objection is that the patch is a kludge, whether or not it includes duplicated code.
I agree, I understand this patch will never be accepted as-is, just trying to gain a little momentum. Can anyone give directions for a cleaner approach? Christoph seems to suggest that a "surrogate server" (not sure what it is) is needed, but ends his comment with "So may not be needed on wine and the DLL can just be loaded in-process." so I'm not sure what he really meant.
There's good will here, I just need better feedback :/
First thing is understanding how CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER are different. So that you have the patch heading down the right line to implement CLSCTX_LOCAL_SERVER.
http://msdn.microsoft.com/en-us/library/ms693716%28v=vs.85%29.aspx Very important read on the subject.
Okay, so let me try to summarize to see if I've got it right:
CLSCTX_INPROC_SERVER creates and manages OLE objects in the same process as the application that uses them. This is fine if the object is not shared between multiple applications, for example, because each instance of an application can only use its 'own version' of the OLE object, which is different in every process.
CLSCTX_LOCAL_SERVER creates and manages OLE objects on the same machine, but on a different process than the user application. Ie. the application containing the object we want to use has to be launched, it will itself call CoRegisterClassObject on startup, thus registering itself as an OLE object (in our case, with the CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2}) so that any application on this machine can access the same, shared instance of this object running in a dedicated process.
Right? And if I understood correctly, right now there is no separate process being launched when CLSCTX_LOCAL_SERVER is used in Wine, so the object never gets registered and it fails with:
err:ole:create_server class {629f8434-0530-41e6-b7c5-61a82faa3df2} not registered err:ole:CoGetClassObject no class object {629f8434-0530-41e6-b7c5-61a82faa3df2} could be created for context 0x4
(see attachment #23993)
I'm not sure yet how to 'start a surrogate server' so that the OLE object gets loaded in a different process, I'll continue to read Wine's ole codebase, it seems create_server should do this but fails somehow (Christoph mentioned the lack of a 'LocalService' entry under the 'AppId' entry - I'm still not too clear what the relation is between the registry and our problem with OLE objects here).
What I don't understand though, is why does it work at all to force INPROC instead of LOCAL for our specific bug. For CoGetClassObject to work, the object still has to be loaded somewhere somehow right? So that means it's "accidentally" already loaded in the same process as the launcher and thus the hack works? I must be missing something.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #43 from oiaohm oiaohm@gmail.com 2011-04-06 08:23:51 CDT ---
Okay, so let me try to summarize to see if I've got it right:
CLSCTX_INPROC_SERVER creates and manages OLE objects in the same process as the application that uses them. This is fine if the object is not shared between multiple applications, for example, because each instance of an application can only use its 'own version' of the OLE object, which is different in every process.
This is what you missed. INPROC SERVER has a CLSID
CLSCTX_LOCAL_SERVER creates and manages OLE objects on the same machine, but on a different process than the user application. Ie. the application containing the object we want to use has to be launched, it will itself call CoRegisterClassObject on startup, thus registering itself as an OLE object (in our case, with the CLSID {629f8434-0530-41e6-b7c5-61a82faa3df2}) so that any application on this machine can access the same, shared instance of this object running in a dedicated process.
And Local Server has a CLSID.
CLSCTX_INPROC_SERVER and CLSCTX_LOCAL_SERVER start something to handle a CLSID call. One is in the same process one is not.
That is why the alteration works for your application. Problem is this is not always the case. Yes more often than not it will not be the case. Because if it was the programmer would have used inproc instead.
Problem is also handler for INPROC and LOCAL could be two different things as well ment to give application 2 different results even that is the same CLSID.
CLSID is a point in the road where you can cross the streams and appear to have everything working when really its a timebomb waiting to explode. Since CLSID does not tell if it what is for is INPROC or LOCAL. Call flags to operations tell it if its INPROC or LOCAL that should be connected to.
LOCAL Server is one group of trouble. INPROC is another.
Some of this is a question do you need test cases.
Basically there is a devil here. I would recommending testcasing how windows handles no LOCAL_SERVER but a INPROC_SERVER being on hand yet a connection to LOCAL_SERVER has been requested. I would not be surprised if windows has some strange fail through system. But this would not be override flag every time. Sometimes connecting to LOCAL_SERVER would happen.
At this stage not enough information to know exactly what is going wrong. Either is something warped in windows or LOCAL_SERVER is not registering in the installer for some reason. Basically something has gone wrong.
Patch you had created is just masking not fixing.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #44 from Christoph Hohmann reboot@gmx.ch 2011-04-06 15:38:01 CDT ---
From what I understood from the Wine code and reading some MSDN is that there
are 2 different ways for an LOCAL server.
The first is that the AppID entry in the registry specifies an executable, that provides a COM object of the class. When an object of a CLSID is requested by a process that has not been started yet, the executeable that is specified in the registry is started, it then registers an object of the class with the COM system and the requesting process can then access it. Wine seems to support this and it starts the executable.
The second possibility is, that the AppID contains DllSurrogate. In this case there is no executeable to start. Only a DLL specified in the CLSID entry. Windows then starts the program dllhost with the AppID as a parameter. This program loads the DLL, creates an instance of the COM object and registers it as a local server in the COM system. This method is not supported by Wine. So to support this, Wine would have to check for the DllSurrogate entry and then start dllhost.exe. I have tried to run the original dllhost.exe of a Windows XP on Wine and it seems to load the DLL and then fails to register the COM object because a call is not implemented. Wine would probably have to implement dllhost.exe and the missing call in the COM system.
For League of Legends it is used to run some code as a Windows service with administrative priviledges. This process then gives the priviledges to the League of Legends launcher, because it has to write to the Program Files directory of League of Legends, what a normal user process can not do with User Account Control. As far as I know, Wine has no access control to files. It doesn't really need that, because it is already a user process that has to follow the access control of the host operating system. So I guess the code in the DLL has no effect on Linux anyway, and it does not matter if the DLL is loaded in process or into a service process started by dllhost.exe.
To make League of Legends run out of the box DllSurrogate would have to be supported. But maybe it would also be possible to simply modify the registry entry of the CLSID to load the DLL in process instead of patching wine.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #45 from Amos Wenger amos@official.fm 2011-04-06 16:13:25 CDT --- (In reply to comment #44)
From what I understood from the Wine code and reading some MSDN is that there are 2 different ways for an LOCAL server. [snip]
Yes, after digging into MSDN and Wine's OLE/COM/RPC implementation, things are now much cleaner in my head. I've played around, it's very easy to detect the presence of the DllSurrogate key and retrieve the correct dll path (from the InprocServer32 key). At first I was going to simply LoadLibrary and call DllRegisterServer but then I realized it would be the same as INPROC and that's not what we want to do here.
Then I read the documentation "Writing a Custom Surrogate" on MSDN, since I figured Wine didn't have a Surrogate implementation at all I might just write Wine's default surrogate server myself. I didn't know Window's default surrogate was in dllhost.exe, thanks for this information :) Although we can't really use it because it would then require a Windows install, right?
So my plan right now is to implement the ISurrogate interface in dlls/ole32/surrogate.c ie. only the LoadDllServer and FreeSurrogate functions as defined in include/objidl.idl I think LoadDllServer should do the LoadLibrary + GetProcAddr to call DllRegisterServer on the given dll, and FreeSurrogate should just, well, exit the process?
Then I thought I might add a hook to ole32.dll to start the surrogate server, so that in our LOCAL_SERVER case it would launch rundll32.exe with the help of CreateProcess calling the new hook (something like LaunchSystemSurrogate for example), which would then call LoadDllServer with the dll path retrieved from the registry using the clsid passed as an argument. *Phew*.
So anyway that's what I'm trying right now, let me know if you think it makes sense, unless someone tells me it's really stupid I'll continue that way ;) I think it might make sense to implement the surrogate a separate application (just like dllhost.exe), but right now I have no idea how to do that in Wine (add a .c file in tools/ ?) so I'm just trying to deal with how little I know of Wine's codebase right now.
Also, yes, I'm aware that League Of Legends' use of LOCAL_SERVER is probably useless in the case of Wine (because we don't do UAC etc., as you explained) but well, it shouldn't hurt anyway, and some other applications might depend on it so we're better off implementing it correctly anyway. Wish me luck!
But maybe it would also be possible to simply modify the registry entry of the CLSID to load the DLL in process instead of patching wine.
I'm not sure how that would be done. Deleting the DllSurrogate entry would still lead to failure since right now the LOCAL_SERVER code is expecting a LocalService entry, which (if I understood correctly) should be a .exe file launching a COM server of some sort. LoL doesn't provide this, just a Dll file with the symbols we need. So can we force inproc from the registry? That would be awesome, because then we could run LoL on stock wine without any patch :) (And without waiting for the next release with proper surrogate support)
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #46 from Christoph Hohmann reboot@gmx.ch 2011-04-06 17:59:27 CDT --- On Windows you can see, after the League of Legends launcher is started, that svchost.exe start a dllhost.exe process with the parameter "/Processid:{24D8BC2F-47F2-4A20-B7E4-F9394EEAFB1B}". The Processid is the AppID for League of Legends's CRiotLauncherElevateCOM.
If you run the Windows' dllhost.exe with Wine it fails with:
wine: Call from 0x7edc8b17 to unimplemented function ole32.dll.CoRegisterSurrogateEx, aborting wine: Unimplemented function ole32.dll.CoRegisterSurrogateEx called at address 0x7edc8b17 (thread 0058), starting debugger...
I don't know enough about COM to say how this really works. But for me it looks like you just have to start the dllhost.exe process, like Windows, and implement the missing function in ole32.dll. For testing the Window dllhost.exe could be used and implemented later, when the functions in the COM system are working.
Changing the registry to load a DLL in process doesn't seem to be possible, as the parameter that specifies how an instance should be created is passed as a parameter from the program (CoGetClassObject: dwClsContext) and not a value in the registry.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #47 from Dan Kegel dank@kegel.com 2011-04-06 18:02:13 CDT --- Yeah, implementing CoRegisterSurrogateEx() seems like the way to go. Start by writing tests for it.
Email me if you want a list of helpful COM books.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #48 from oiaohm oiaohm@gmail.com 2011-04-06 18:49:11 CDT ---
Also, yes, I'm aware that League Of Legends' use of LOCAL_SERVER is probably useless in the case of Wine (because we don't do UAC etc., as you explained) but well, it shouldn't hurt anyway, and some other applications might depend on it so we're better off implementing it correctly anyway. Wish me luck!
I guess never read bug http://bugs.winehq.org/show_bug.cgi?id=11112
At some point wine will have to implement secuirty to allow multi users to use the same prefix at the same time. It is one of the most requested features. Its also up there with one of the hardest to implement.
Implementing it of course is not simple.
http://wiki.winehq.org/WineReleaseCriteria Sign of highly wanted is when a bug becomes officially tagged as if complete it becomes a trigger for a new version.
Issue is that is unless today with wine. But wine in a few years time could have a issue with it done wrong since a secuirty system will come at some point.
This is part of the reason for the zero tolerance on hacks like you first did. It will explode in our faces. Not today but in a few years time it will for sure.
Now you look to be on the right path. Going after the real fault not hiding it.
Surrogate I wonder how many applications that is stopping from working right. I would guess quite a few.
This is the thing about fixing it right. You always fix more things at the same time.
http://bugs.winehq.org/show_bug.cgi?id=20296
Amos Wenger amos@official.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33948|0 |1 is obsolete| |
--- Comment #49 from Amos Wenger amos@official.fm 2011-04-09 19:57:27 CDT --- Created an attachment (id=34018) --> (http://bugs.winehq.org/attachment.cgi?id=34018) First try implementing dll surrogates in Wine
So here it is, after a few days of reading more than my fair share of DCOM docs, wine sourcecode, hacking around to see how stuff works under the hood, here's my first try at implementing dll surrogates in wine. Disclaimer: the patch is big. 22K, 690 lines, It still depends on a Windows dllhost.exe (I used the version from my Windows XP SP3 32-bit). FOR TESTING THIS PATCH, DLLHOST.EXE NEEDS TO BE IN $WINEPREFIX/WINDOWS/SYSTEM32 (or anywhere in your %PATH%, really, but that's where it belongs anyway). The reason I haven't provided a dllhost.exe is because I'm not sure how to add a program to tools/ but it should be really easy to code, afaik it just does CoInitializeEx, then parses command-line arguments and goes CLSIDFromString, then calls CoRegisterSurrogateEx and that's it. If CoRegisterSurrogateEx returns, it just CoUnitializeEx and shuts down!
it probably needs a good cleanup and I can't guarantee it's 100% right - especially I'm not entirely sure I'm using the right CLSCTX and REGCLS values everywhere, but everything seems to go find on the local rpc server, generic marshalling/unmarshalling works like a charm and functions are called remotely correctly - there might be some apartment handling I haven't looked into yet, but I think this is pretty much what we had in mind. Also, I'm not sure where to draw the line between compobj.c and surrogate.c, sometimes I feel some of compobj.c belongs in surrogate.c, but oh well I'm not sure. Feedback greatly appreciated!
So here are my observations:
- When run naively (wine lol.launcher.exe), it shows the patcher, sleeps till I click "Play", then shows a dialog box telling me LolClient.exe has crashed, sleeps till I close this dialog box, and *then* the login screen comes up, but I can't login successfully (obviously it's LolClient.exe that's handling the login and since it crashed well... it's not even trying to log in with the data provided). - When run with a few debug options (WINEDEBUG=ole,+tid,+relay wine lol.launcher.exe), it's slow as fuck, but... it works! LolClient.exe doesn't crash, it displays the patcher then the login screen correctly, I can log in and even start a game and it begins to load :) (I haven't tested the actual gameplay because it was so slow and LoL complained about my graphic drivers.. nouveau actually).
So I've done some more investigation on the LolClient.exe crash, by running it manually (something like winedbg air/LolClient.exe -runtime air air/META-INF/AIR/application.xml air/) which obviously should fail since Maestro is not running, but that's not the problem here - it seems to crash in:
Backtrace: =>0 0x7c574eac ssleay_rand_add+0x30c() in libcrypto.so.1.0.0 (0x0f65c0bc) 1 0x00956d01 (0xafd17daf)
So now I'm really puzzled, it seems my patch solves the same issue as attachment #25672, except it does it correctly, because it starts a separate process to load the dll in, and does everything by rpc after that, so... problem solved. Now why does the rest crash? Apparently people had the whole client working only with ole-force-inproc-[...] but I don't. I'd appreciate if other people could test it, especially on 32-bit distros, I think it might be the culprit.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #50 from Christoph Hohmann reboot@gmx.ch 2011-04-09 20:44:41 CDT --- I tried the patch on the latest wine source from git and Debian unstable (32 bit). It seems to work fine. The dllhost.exe process was started and the launcher did not crash. I could login and I could play the tutorial.
I noticed that the dllhost.exe process is not terminated when the lol.laucnher.exe exits.
On Windows the dllhost.exe process is started by scvhost.exe and not a child process of lol.launcher.exe. If you have multiple processes using a shared instance of a surrogate it could be a problem if the surrogate is a child process of one of the processes that uses it and is terminated when it's parent process exits.
I think it would be better to discuss the SSL problem you have on the AppDB page.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #51 from Amos Wenger amos@official.fm 2011-04-10 10:28:34 CDT --- (In reply to comment #50)
I tried the patch on the latest wine source from git and Debian unstable (32 bit). It seems to work fine. The dllhost.exe process was started and the launcher did not crash. I could login and I could play the tutorial.
I noticed that the dllhost.exe process is not terminated when the lol.laucnher.exe exits.
Did you notice a fixme:ole:FreeSurrogate stub in the logs? If yes, it's a pretty easy fix. If not, I'm not sure how to make it called (does CoFreeUnusedLibraries handle that?)
On Windows the dllhost.exe process is started by svchost.exe and not a child process of lol.launcher.exe. If you have multiple processes using a shared instance of a surrogate it could be a problem if the surrogate is a child process of one of the processes that uses it and is terminated when it's parent process exits.
Alright, it makes sense, but how do we do that? I've read wine's svchost sources (for reference: http://source.winehq.org/source/programs/svchost/svchost.c ), but there are a few things I don't know yet:
- How is svchost.exe actually started if not by CreateProcess? Is is launched everytime wine itself is launched? - If svchost.exe is not started by CreateProcess how can I pass it arguments? - Also, svchost's arguments seem to be Service names/group names. We have no services for dllhost.exe/Lol's DLL we're loading
svchost.exe usage is still rocket science to me, I've tried to find docs but there seems to be very little useful tech info on the interwebs :/
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #52 from Christoph Hohmann reboot@gmx.ch 2011-04-10 14:58:20 CDT --- I checked for svchost.exe on Windows: The process that starts dllhost.exe has the commandline "svchost.exe -k DcomLaunch". This is the "DCOM Server Process Launcher" Windows Service. Process Explorer shows the DLL rpcss.dll for this service. When I run a program with Wine there is already another svchost.exe running, so Wine is already able to run services. It is started by services.exe just like it is on Windows. I guess that the process that needs the surrogate sends a "message" to the DCOM Server Process Launcher service and the service then starts dllhost.exe.
I'll check the log about the other issue with dllhost.exe later.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #53 from Amos Wenger amos@official.fm 2011-04-10 15:28:18 CDT --- (In reply to comment #52)
I checked for svchost.exe on Windows: The process that starts dllhost.exe has the commandline "svchost.exe -k DcomLaunch". This is the "DCOM Server Process Launcher" Windows Service. Process Explorer shows the DLL rpcss.dll for this service.
Okay, thanks a lot for the service name, so it means I could modify wine so that it registers dllhost.exe as a service with the name DcomLaunch?
It's weird that Process Explorer shows rpcss.dll for this service because rpcss.dll "primarily provides the infrastructure for COM, but a portion of rpcss.dll is used for the EPM. An RPC server contacts the EPM to receive dynamic endpoints and register those endpoints in the EPM database. RPC clients contact the EPM from the protocol-engine level to resolve endpoints when establishing a connection with an unknown RPC server endpoint." (see http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx )
Then again, I don't think we can register services as .exe, but only, DLLs right? I've just checked in regedit (in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DcomLaunch\Parameters), and it's indeed rpcss.dll I've also just grepped wine for rpcss and.. well there's an rpcss.exe (itself not exactly interface-compatible with windows') but no trace of a .dll whatsoever. Afaik it needs to be a DLL that has a Service EntryPoint, so it could be any DLL we create, really?
One thing is bugging me though - even if we could do svchost.exe -k DcomLaunch, how do we finally know which CLSID (and thus which dll) to load? At least when we do CreateProcess(dllhost.exe) we can pass an argument to dllhost.exe. But passing through svchost.exe I don't see how we can do the same?
When I run a program with Wine there is already another svchost.exe running, so Wine is already able to run services. It is started by services.exe just like it is on Windows. I guess that the process that needs the surrogate sends a "message" to the DCOM Server Process Launcher service and the service then starts dllhost.exe.
Ah.. so let me recap:
- A process needs a DLL to be loaded in a surrogate - This process tries to communicate with the service DcomLaunch - If it fails, it starts it with svchost.exe -k DcomLaunch - It somehow "sends a signal" to the DcomLaunch service that it needs such CLSID to be loaded - The DcomLaunch service (apparently implemented in rpcss.dll) starts dllhost.exe via CreateProcess, with the right command-line argument - When the process knows that dllhost.exe has correctly registered the required CLSID, it retrieves it via CoGetClassObject and uses it
Now the remaining fuzzy parts are: how do we "send a signal" to a service (via COM, too?), and when do we know when a CLSID is registered (currently I do an optimistic Sleep(5000L) but it's fugly)
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #54 from Christoph Hohmann reboot@gmx.ch 2011-04-10 17:15:11 CDT --- I think you mixed up the DcomLaunch service and dllhost.exe a bit in the first part.
What I understood is:
1. services.exe is the service manager. When it is started it checks the registry for services that have to be started. Services are executables (.exe). I think this is already implemented in Wine.
2. DcomLaunch is a service (Found in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services) - Service name: DcomLaunch - Display name: DCOM Server Process Launcher - Commandline: svchost.exe -k DcomLaunch
3. svchost.exe is a wrapper for services in DLLs. It get the registry entry specified as the -k parameter from HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\SvcHost, splits it into service names, gets the service DLLs from ServiceDll in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services%servicename\Parameters, loads the DLL in the Parameters as a DLL, and invokes the service entry point (ServiceMain). I think this already implemented in Wine.
4. rpcss.dll implements the DCOM Server Process Launcher service. When it receives a request to start a surrogate it launches dllhost.exe. This seems to be only a part of what the DLL contains, but that is what would be needed for League of Legends.
5. dllhost.exe loads the DLL that implements the COM interface and calls CoRegisterSurrogateEx.
I have no idea how the communication between the application and the COM Server Process Launcher works. That it provides a COM object itself that is used by ole32.dll to start the surrogate server could be possible.
services.exe and svchost.exe already seems to do what they do on Windows. So all that is needed is to implement rpcss.dll, add it to the registry and find a way to tell it to start a dllhost.exe process from the application that needs a COM server. DcomLaunch itself is always running, it gets the AppID it should pass to dllhost.exe when it receives a request to start a COM server.
Maybe it would be better to ask on the wine-devel mailinglist how Wine's COM implementation works. There seems to be some support for LOCAL_SERVER that is not using DllSurrogate, so there has to be a way to wait for a COM server that provides a CLSID to become available.
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #55 from Amos Wenger amos@official.fm 2011-04-10 20:29:39 CDT --- (In reply to comment #54)
I think you mixed up the DcomLaunch service and dllhost.exe a bit in the first part.
Yeah, sorry about that. I was a bit confused at first
- rpcss.dll implements the DCOM Server Process Launcher service. When it
receives a request to start a surrogate it launches dllhost.exe. This seems to be only a part of what the DLL contains, but that is what would be needed for League of Legends.
Yeah, I think I can get started with only implementing the service. I'm not sure how to add a dll to wine (ie. what to add in Makefiles etc.) but I'll try to figure it out from other existing dlls
- dllhost.exe loads the DLL that implements the COM interface and calls
CoRegisterSurrogateEx.
Yeah, I also need to implement dllhost.exe so we can do away with Windows XP's one, but it's pretty basic from what I saw, so np.
I have no idea how the communication between the application and the COM Server Process Launcher works. That it provides a COM object itself that is used by ole32.dll to start the surrogate server could be possible.
Well that's how I would do it, I think - no matter how it's done on Windows.
So all that is needed is to implement rpcss.dll, add it to the registry and find a way to tell it to start a dllhost.exe process from the application that needs a COM server. DcomLaunch itself is always running, it gets the AppID it should pass to dllhost.exe when it receives a request to start a COM server.
Maybe it would be better to ask on the wine-devel mailinglist how Wine's COM implementation works. There seems to be some support for LOCAL_SERVER that is not using DllSurrogate, so there has to be a way to wait for a COM server that provides a CLSID to become available.
Well if you look at dlls/ole32/rpc.c, in the RPC_GetLocalClassObject function, there's code that waits till a local_server COM object is fully loaded apparently (up to 30 seconds)
I think the basic algorithm stays the same, while loop with max_tries and Sleep.. no rocket science here :) Also see http://msdn.microsoft.com/en-us/library/ms686321(v=vs.85).aspx here for interesting docs
http://bugs.winehq.org/show_bug.cgi?id=20296
dufoli olivier.duff@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier.duff@gmail.com
--- Comment #56 from dufoli olivier.duff@gmail.com 2011-09-15 04:49:29 CDT --- any news/review about the amos 's patch ?
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #57 from Amos Wenger amos@official.fm 2011-09-15 04:52:31 CDT --- (In reply to comment #56)
any news/review about the amos 's patch ?
Sorry, no recent news.
As far as I can tell, the situation has evolved and dll surrogates are not really the main problem that occurs when launching LoL.
I lacked the time to finish the patch and I doubt it would've been included in Wine's core anyway. It's more likely to introduce subtle bugs than to really fix anything.
It's a pity though I would've loved to actually get this fixed properly. Guess well have to wait for somebody actually knowledgeable about DCOM to fix this.
http://bugs.winehq.org/show_bug.cgi?id=20296
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://cds008.am4.hwcdn.net | |/h2f4b5v4/cds/installer/lol | |/LOL_Setup.exe | CC| |focht@gmx.net Summary|League of Legends: crash |Multiple apps crash due |after eula |missing support for COM dll | |surrogate, dllhost.exe | |(League of Legends | |08_18_2009_04, 3dmark03)
--- Comment #58 from Anastasius Focht focht@gmx.net 2012-03-27 15:48:18 CDT --- Hello,
came here because I looked for duplicates after investigating bug 22392 "3dmark03, 3dmark06 crash on startup when trying to get system info (Wine lacks support for COM dll surrogate, dllhost.exe)"
--- quote --- As far as I can tell, the situation has evolved and dll surrogates are not really the main problem that occurs when launching LoL. --- quote ---
I managed to dig up an old installer (game version 08_18_2009_04) because some people still seed that old stuff ;-)
$ du -sh LOL_Setup.exe 507M LOL_Setup.exe
$ sha1sum LOL_Setup.exe 47506d55493c6755c72cc33178e1ea0c398b37c5 LOL_Setup.exe
$ wine --version wine-1.5.0-147-g4c6a198
The missing dll surrogate support _is_ the problem for the old "League of Legends" installer but not for newer versions (>2009).
"patcher_lib.log" gives:
--- snip --- 03/27/2012 22:25 [INFO] Solid LauncherLib [1.0.0.32] initializing... 03/27/2012 22:25 [INFO] CElevateHelper::RegisterServer() success 03/27/2012 22:25 [INFO] Failed to re-register 80040152 03/27/2012 22:25 [WARNING] LAUNCHERERRORTYPE_ELEVATECOMFAIL --- snip ---
Trace log reveals it tries standard COM surrogate instanciation.
"{629f8434-0530-41e6-b7c5-61a82faa3df2}" lives in "CRiotLauncherElevateCOM.dll"
--- snip --- ... 0024:Call ole32.CoCreateInstance(00450394,00000000,00000004,00450384,0032d428) ret=00403e00 0024:trace:ole:CoCreateInstance (rclsid={629f8434-0530-41e6-b7c5-61a82faa3df2}, pUnkOuter=(nil), dwClsContext=00000004, riid={5e30ffab-3b7c-4990-9281-7da8b43d1416}, ppv=0x32d428) 0024:trace:ole:CoGetClassObject CLSID: {629f8434-0530-41e6-b7c5-61a82faa3df2},IID: {00000001-0000-0000-c000-000000000046} 0024:trace:ole:RPC_GetLocalClassObject rclsid={629f8434-0530-41e6-b7c5-61a82faa3df2}, iid={00000001-0000-0000-c000-000000000046} 0024:trace:ole:RPC_GetLocalClassObject waiting for L"\\.\pipe\{629F8434-0530-41E6-B7C5-61A82FAA3DF2}" 0024:Call KERNEL32.WaitNamedPipeW(0032d14c L"\\.\pipe\{629F8434-0530-41E6-B7C5-61A82FAA3DF2}",ffffffff) ret=7e941f7c 0024:Ret KERNEL32.WaitNamedPipeW() retval=00000000 ret=7e941f7c 0024:Call KERNEL32.CreateFileW(0032d14c L"\\.\pipe\{629F8434-0530-41E6-B7C5-61A82FAA3DF2}",c0000000,00000000,00000000,00000003,00000000,00000000) ret=7e941fbd 0024:Ret KERNEL32.CreateFileW() retval=ffffffff ret=7e941fbd 0024:trace:ole:create_local_service Attempting to start Local service for {629f8434-0530-41e6-b7c5-61a82faa3df2} 0024:Call advapi32.RegOpenKeyExW(80000000,0032ce22 L"CLSID\{629F8434-0530-41E6-B7C5-61A82FAA3DF2}",00000000,00020019,0032ce1c) ret=7e907a3f 0024:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=7e907a3f 0024:Call advapi32.RegQueryValueExW(00000114,7e9d7400 L"AppId",00000000,0032ceb0,0032cf1a,0032ceb8) ret=7e907b64 0024:Ret advapi32.RegQueryValueExW() retval=00000000 ret=7e907b64 0024:Call advapi32.RegCloseKey(00000114) ret=7e907b78 0024:Ret advapi32.RegCloseKey() retval=00000000 ret=7e907b78 0024:Call advapi32.RegOpenKeyExW(80000000,0032cebe L"AppId\{24D8BC2F-47F2-4A20-B7E4-F9394EEAFB1B}",00000000,00020019,0032cfb8) ret=7e907bfc 0024:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=7e907bfc 0024:Call advapi32.RegQueryValueExW(00000114,7e9de91a L"LocalService",00000000,0032cfb4,0032cfbe,0032cfb0) ret=7e941c59 0024:Ret advapi32.RegQueryValueExW() retval=00000002 ret=7e941c59 0024:warn:ole:create_local_service No LocalService value 0024:Call advapi32.RegCloseKey(00000114) ret=7e941e12 0024:Ret advapi32.RegCloseKey() retval=00000000 ret=7e941e12 0024:Call advapi32.RegOpenKeyExW(80000000,0032ccd2 L"CLSID\{629F8434-0530-41E6-B7C5-61A82FAA3DF2}",00000000,00020019,0032cccc) ret=7e907a3f 0024:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=7e907a3f 0024:Call advapi32.RegOpenKeyExW(00000114,7e9de964 L"LocalServer32",00000000,00020019,0032cff4) ret=7e907a9c 0024:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=7e907a9c 0024:Call advapi32.RegCloseKey(00000114) ret=7e907aad 0024:Ret advapi32.RegCloseKey() retval=00000000 ret=7e907aad 0024:err:ole:create_server class {629f8434-0530-41e6-b7c5-61a82faa3df2} not registered 0024:err:ole:CoGetClassObject no class object {629f8434-0530-41e6-b7c5-61a82faa3df2} could be created for context 0x4 0024:Ret ole32.CoCreateInstance() retval=80040152 ret=00403e00 ... --- snip ---
The launcher does a recovery after first failure by re-registering COM server and instanciating again:
--- snip --- 0024:Call KERNEL32.CreateProcessW(00000000,0032b9b8 L"regsvr32 /s "C:\Riot Games\League of Legends\CRiotLauncherElevateCOM.dll"",00000000,00000000,00000000,00000400,00000000,00000000,0032b060,0032b050) ret=7e4ed23f ... 0024:Ret KERNEL32.CreateProcessW() retval=00000001 ret=7e4ed23f ... 0024:Call ole32.CoCreateInstance(00450394,00000000,00000004,00450384,0032d428) ret=00403e31 0024:trace:ole:CoCreateInstance (rclsid={629f8434-0530-41e6-b7c5-61a82faa3df2}, pUnkOuter=(nil), dwClsContext=00000004, riid={5e30ffab-3b7c-4990-9281-7da8b43d1416}, ppv=0x32d428) ... 0024:Ret ole32.CoCreateInstance() retval=80040152 ret=00403e31 ... 0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x405f01 ip=00405f01 tid=0024 0024:trace:seh:raise_exception info[0]=00000000 0024:trace:seh:raise_exception info[1]=00000000 0024:trace:seh:raise_exception eax=00000000 ebx=00890140 ecx=cb66c139 edx=00450684 esi=00890140 edi=00000000 0024:trace:seh:raise_exception ebp=0032d56c esp=0032cf1c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212 0024:trace:seh:call_stack_handlers calling handler at 0x4494fb code=c0000005 flags=0 --- snip ---
It ultimately fails because another failure is not expected.
Refining summary as this affects several apps and to collect them here.
Download link is busted but you will find torrents still alive with "LOL_Setup.exe" (507 MiB version).
Regards
http://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #59 from Anastasius Focht focht@gmx.net 2012-03-27 15:50:06 CDT --- *** Bug 22392 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20296
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20296
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t.artem@mailcity.com
--- Comment #60 from Anastasius Focht focht@gmx.net --- *** Bug 36548 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20296
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=20296
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.futuremark.com/d | |ownload/3dmark03/
https://bugs.winehq.org/show_bug.cgi?id=20296
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #61 from Austin English austinenglish@gmail.com --- *** Bug 39674 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=20296
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #62 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Austin English from comment #61)
*** Bug 39674 has been marked as a duplicate of this bug. ***
As we know now the bug 39674 has no relation to this bug. 3DMark03 is working just fine now without implementing surrogates. But I don't know the exact reason why LoL is crashed.
https://bugs.winehq.org/show_bug.cgi?id=20296
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=20296
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz Summary|Multiple apps crash due |Multiple apps crash due |missing support for COM dll |missing support for COM dll |surrogate, dllhost.exe |surrogate, dllhost.exe |(League of Legends |(League of Legends |08_18_2009_04, 3dmark03) |08_18_2009_04, 3Dmark03, | |3Dmark05, 3Dmark06)
--- Comment #63 from Wylda wylda@volny.cz --- Still present in wine-1.9.3.
Not all 3Dmarks are affected, some of them show correct System Info (depends on shipped System Info version):
3Dmark 2003: * v3.6.0 ... shows SI * v3.6.1 ... error * v3.6.2 ... error
3Dmark 2005: * v1.0.0 ... shows SI * v1.2.0 ... shows SI * v1.3.0 ... shows SI * v1.3.1 ... error * v1.3.2 ... error
3Dmark 2006: * v1.1.1 ... error * v1.2.0 ... error * v1.2.1 ... shows SI
https://bugs.winehq.org/show_bug.cgi?id=20296
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24015|0 |1 is obsolete| |
--- Comment #64 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Comment on attachment 24015 --> https://bugs.winehq.org/attachment.cgi?id=24015 hnetcfg: Add a stub implementation of INetFwOpenPorts and INetFwOpenPort.
This patch is now part of wine.
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #65 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Wylda from comment #63)
Still present in wine-1.9.3.
Not all 3Dmarks are affected, some of them show correct System Info (depends on shipped System Info version):
Yes, they stopped working. It looks to be new regression?
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #66 from Wylda wylda@volny.cz --- (In reply to Sergey Isakov from comment #65)
Not all 3Dmarks are affected, some of them show correct System Info (depends on shipped System Info version):
Yes, they stopped working. It looks to be new regression?
No, because you can take SI3.DLL from working 3Dmark and place it to non-working 3Dmark and it begins to work. It really depends on version of SI3.DLL.
Actually replacing of SI3.DLL is the only way, how to run "latest" 3Dmark 2003, because parameter -nosysteminfo does not work for "latest" 3Dmark 2003.
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #67 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Wylda from comment #66)
(In reply to Sergey Isakov from comment #65)
Not all 3Dmarks are affected, some of them show correct System Info (depends on shipped System Info version):
Yes, they stopped working. It looks to be new regression?
No, because you can take SI3.DLL from working 3Dmark and place it to non-working 3Dmark and it begins to work. It really depends on version of SI3.DLL.
Actually replacing of SI3.DLL is the only way, how to run "latest" 3Dmark 2003, because parameter -nosysteminfo does not work for "latest" 3Dmark 2003.
Where did you get 3DMark03 v3.6.2? Official download is v3.6.0 http://www.futuremark.com/benchmarks/legacy
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #68 from Artem S. Tashkinov t.artem@mailcity.com --- (In reply to Sergey Isakov from comment #67)
Where did you get 3DMark03 v3.6.2? Official download is v3.6.0 http://www.futuremark.com/benchmarks/legacy
Where did you see version 3.6.2?
(quoting Wylda, comment #63)
3Dmark 2006:
- v1.1.1 ... error
- v1.2.0 ... error
- v1.2.1 ... shows SI
That's exactly the version posted on the 3DMark website.
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #69 from Sergey Isakov isakov-sl@bk.ru --- I downloaded 3DMark06 from official futuremark website. It appears to be 1.2.0. SI3.dll dated 02.02.2009 as well as in 3DMark03 folder. I reinstalled FutumarkSystemInfo to be version 4.28. Both application 3DMark03 and 06 works with systeminfo after bug 39674 patch applied. (wine-1.9.3 + patch 39674 by Austin English).
https://bugs.winehq.org/show_bug.cgi?id=20296
--- Comment #70 from Wylda wylda@volny.cz ---
Where did you see version 3.6.2?
That's the version on their page. I know that their presented version says v360, but that's just an "inaccurate" file name... When you run the installer, it will tell you the exact version. Also when you upgrade older version installer will tell you already installed version and exact version you are going to install.
So SHA1's from my private software repository:
19e043f9f359c81a48b85fd3cb690d4e41d092a3 *3dmark03-v3.4.0_(2003-11-07).exe ee2b8256785854c54c078ae9078382b07887b774 *3dmark03-v3.5.0_(2004-11-16).exe 4f7db8515a02f3247cf08cf9ef560227146922f1 *3dmark03-v3.6.0_(2005-01-24).exe e7608bc653ba6975678053aa40ef5890997c7327 *3dmark03-v3.6.1.0906_(2009-05-27)ask com_installer.exe 078030e2b4e5e93e4fc2e7f10cd5ce1decd08a1b *3dmark03-v3.6.1.0906_(2009-05-27).exe 46a439101ddbbe3c9563b5e9651cb61b46ce0619 *3dmark03-v3.6.2.1901_(2010-02-03).exe
The dates are taken from electronic timestamps signature. Release dates are usually few days latter...
https://bugs.winehq.org/show_bug.cgi?id=20296
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=20296
exposight exposight@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |exposight@gmail.com
--- Comment #71 from exposight exposight@gmail.com --- 3DMark versions can be downloaded from https://benchmarks.ul.com/legacy-benchmarks
Current behavior on wine devel 4.18 x64 is a bit different. Here is what was performed in order and what was the result: 1. Install 3DMark03 and run: error message box about System Info not installed/not working appears, 3DMark then closes. Console output errors:
0009:err:ole:create_server class {f21aabf7-4f63-48fb-9524-822429922224} not registered 0009:err:ole:CoGetClassObject no class object {f21aabf7-4f63-48fb-9524-822429922224} could be created for context 0x4
2. Install 3DMark05 and run: error message box about System Info not installed/not working appears, 3DMark then closes. Console output errors:
0077:err:ole:create_server class {f21aabf7-4f63-48fb-9524-822429922224} not registered 0077:err:ole:CoGetClassObject no class object {f21aabf7-4f63-48fb-9524-822429922224} could be created for context 0x4 wine: Unhandled page fault on read access to 0x00000004 at address 7D96FF0E (thread 0077), starting debugger...
3. Install 3DMark06 and run: process runs, spams into console and hangs. Other process 'fmsiscan.exe' consumes one core. Killing it manually makes 3DMark proceed and it opens. 4. After that, behavior for 3DMark03 and 3DMark05 starts to be the same: hang on open, need to kill one 'fmsiscan.exe' process consuming CPU in order to proceed.
Not sure if this is the same issue, but some bug is still there.
https://bugs.winehq.org/show_bug.cgi?id=20296
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #72 from mirh mirh@protonmail.ch --- Yes, I think it's still the same issue.
If you use WINEDEBUG=+ole on 3DMark03 (3DMark03_v360_1901.exe at least, not sure what the Systeminfo version actually is), before it complains about {f21aabf7-4f63-48fb-9524-822429922224} you can see the same "No LocalService value" warning of LoL.
3DMark06 1.2.1 somewhat seems to run past this issue, only to get stuck on some unhandled privileged instruction thing.
https://bugs.winehq.org/show_bug.cgi?id=20296
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kle@bluewin.ch
--- Comment #73 from C. Leu kle@bluewin.ch --- Hi to all
Here follows a short update to this topic. I can confirm for Wine 6.0 stable that all listed benchmarks (3Dmark03, 3Dmark05, 3Dmark06) including 3Dmark2001SE are installing and running fine in a 64bit prefix. (This should be also true for a 32bit prefix.)
The only somewhat troublesome benchmark may be 3Dmark05 which doesn't starts properly because the "system information component" seems missing. However, it starts to work after 3Dmark06 is installed. It looks that the "system information component" of 3Dmark06 is also functional in 3Dmark05. ;-)
Finally, 3Dmark06 requires that the original 'd3dx9_28.dll' file (winetricks -q d3dx9_28) is installed. The built-in Wine d3dx9_28.dll will NOT work, the Shader Model 3.0 / HDR tests will all crash. I had to install also the d3dcompiler_47 file (winetricks -q d3dcompiler_47).
With these tweaks, everything is working GREAT, especially if Gallium Nine (winetricks -q galliumnine) is installed. (It may bring similar performance to DX9VK).
From my point of view this bug report here can be closed. ;-)
https://bugs.winehq.org/show_bug.cgi?id=20296
Amos Wenger amoswenger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|amoswenger@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=20296
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |f9cd4c915f1929db439aa527dc9 | |22cbfd9953327 Status|NEW |RESOLVED
--- Comment #74 from Dmitry Timoshkov dmitry@baikal.ru --- With f9cd4c915f1929db439aa527dc922cbfd9953327 implementation of dllhost.exe is now landed to wine.git. What remains to be done is proper termination of dllhost.exe and wow64 support.
https://bugs.winehq.org/show_bug.cgi?id=20296
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #75 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.4.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla