https://bugs.winehq.org/show_bug.cgi?id=47817
Bug ID: 47817 Summary: Gameforge Client: Cannot launch TERA Product: Wine Version: 4.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: pdot@tutanota.com Distribution: ---
Created attachment 65308 --> https://bugs.winehq.org/attachment.cgi?id=65308 Terminal output
Hello!
I can't launch TERA from the new Gameforge Client. The game instantly crashes after clicking the Play button, without showing any splash screen. Also, you can't relaunch as the button is stuck with the "In Game" text.
The online installer can be downloaded here: https://install.gameforge.com/download?download_id=79616a07-e3d9-4234-a459-b... a6b4c4110221039f0926ae220ceba58dd75c2a88 GameforgeInstaller.exe
Alternatively, you can download the offline installer here: http://dl.tnt.gameforge.com/tnt/final-ms3/GameforgeClientSetup_190918115147.... 0f7a11df5d6529232ab7ba0de2d0226295674f0c GameforgeClientSetup_190918115147.exe
Tested on a clean 32-bit prefix (also affects 64-bit). Wine was built with the backtrace patch mentioned in the Winedbg's page.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #1 from pdot@tutanota.com --- Created attachment 65309 --> https://bugs.winehq.org/attachment.cgi?id=65309 Backtrace
https://bugs.winehq.org/show_bug.cgi?id=47817
nkb pdot@tutanota.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=47817
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- Tera is 60 GB, so I tried to take a stab at debugging this with the more managable Matins 2.
One thing that looks suspicious is a function that tries to call GetTokenInformation(TokenLinkedToken) and then DuplicateToken() and then goes into an infinite loop trying to unwind the stack. But even with those functions implemented, it still hangs.
Possibly this is entirely unrelated to the backtrace posted. I don't get a segmentation fault at all.
Note also the launcher needs corefonts to be installed before the launcher is installed, or it'll crash.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #3 from nkb pdot@tutanota.com --- (In reply to Zebediah Figura from comment #2)
Tera is 60 GB, so I tried to take a stab at debugging this with the more managable Matins 2.
One thing that looks suspicious is a function that tries to call GetTokenInformation(TokenLinkedToken) and then DuplicateToken() and then goes into an infinite loop trying to unwind the stack. But even with those functions implemented, it still hangs.
Possibly this is entirely unrelated to the backtrace posted. I don't get a segmentation fault at all.
I've tried running Matin2 as well - game hung, but no crashes either.
Also, here is a log from the gfservice.exe process after running TERA. You can enable it by creating a "log.conf" file in C:\Program Files (x86)\GameforgeClient with the following line:
threshold = trace
After restarting the client, the log file will be available at C:\users\username\Temp\gfservice.log.
Note also the launcher needs corefonts to be installed before the launcher is installed, or it'll crash.
It wasn't needed on my system. Maybe because I already got the fonts installed?
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #4 from nkb pdot@tutanota.com --- Created attachment 65331 --> https://bugs.winehq.org/attachment.cgi?id=65331 Generated log from gfservice.exe
https://bugs.winehq.org/show_bug.cgi?id=47817
wineuser sickam@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sickam@mail.ru
--- Comment #5 from wineuser sickam@mail.ru --- I'm having the same issue. I was about to file a bug for that anyway, but I'll contribute to this one instead, now.
Maybe this line is relevant:
00c4:fixme:gameux:GameExplorerImpl_VerifyAccess (081830F0, L"C:\Games\TERA\Client\Binaries\TERA.exe", 035C1FF8)
I don't really know what to do, though. I tried to disable gameux in winecfg, but that'll cause a crash with another error:
00f8:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\windows\system32\gameux.dll" 00f8:err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1
(In reply to nkb from comment #3)
(In reply to Zebediah Figura from comment #2)
Note also the launcher needs corefonts to be installed before the launcher is installed, or it'll crash.
It wasn't needed on my system. Maybe because I already got the fonts installed?
I guess that's why, see https://bugs.winehq.org/show_bug.cgi?id=47789
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #6 from nkb pdot@tutanota.com --- As mentioned in bug 47827, this also affects Nostale.
(In reply to wineuser from comment #5)
I'm having the same issue. I was about to file a bug for that anyway, but I'll contribute to this one instead, now.
Maybe this line is relevant:
00c4:fixme:gameux:GameExplorerImpl_VerifyAccess (081830F0, L"C:\Games\TERA\Client\Binaries\TERA.exe", 035C1FF8)
I don't really know what to do, though. I tried to disable gameux in winecfg, but that'll cause a crash with another error:
00f8:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\windows\system32\gameux.dll" 00f8:err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1
Hmmm, I've also disabled gameux, but it doesn't seems to affect anything on the launcher.
Also, what bothers me the most is the last line on gfservice.log:
2019-09-28 12:17:30.104 WARN [0x005a4080][GFService::ProcessInfoChain] (E:\Jenkins\slave_home\workspace\GFClient\master@2\src\service\localServiceServer\processService\ProcessInfoChain.cpp:60) () ##] Failed to create UnsecuredApartment. Error code = 0xffffffff80040154.
Maybe it has something to do with WBEM and/or administrator rights? Launching with "runas /trustlevel:0x20000" under staging doesn't seems to fix, though.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #7 from wineuser sickam@mail.ru --- (In reply to nkb from comment #6)
Also, what bothers me the most is the last line on gfservice.log:
2019-09-28 12:17:30.104 WARN [0x005a4080][GFService::ProcessInfoChain] (E:\Jenkins\slave_home\workspace\GFClient\master@2\src\service\localServiceServer\processService\ProcessInfoChain.cpp:60) () ##] Failed to create UnsecuredApartment. Error code = 0xffffffff80040154.
Maybe it has something to do with WBEM and/or administrator rights?
I'm getting a different error there:
2019-09-30 00:40:53.484 WARN [0x005b64f8][GFService::ProcessInfoChain] (E:\Jenkins\slave_home\workspace\GFClient\master@2\src\service\localServiceServer\processService\ProcessInfoChain.cpp:51) () ##] Could not set proxy blanket. Error code = 0xffffffff80004001.
Can you try 'winetricks wmi' and see if you get the same result after that?
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #8 from nkb pdot@tutanota.com --- (In reply to wineuser from comment #7)
Can you try 'winetricks wmi' and see if you get the same result after that?
Yup, same result. Setting both wbemprox and wmiutils as disabled gives another error:
Failed to create IWbemLocator object. Error code = 0xffffffff80070005.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #9 from nkb pdot@tutanota.com --- No changes in Wine 4.17 and git (as from commit b360cd67e8f7f8c01f09457bacb032fd4a248d0a). Tried Wine 4.0.2, but the main page won't load.
I'm pretty sure the launcher's background service (gfservice.exe) is making use of WMI/WBEM to run processes with admin rights, so it doesn't UAC prompt the user when running under Windows.
https://bugs.winehq.org/show_bug.cgi?id=47817
winehq_bugzilla@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq_bugzilla@yahoo.com
--- Comment #10 from winehq_bugzilla@yahoo.com --- Created attachment 65383 --> https://bugs.winehq.org/attachment.cgi?id=65383 Console output
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #11 from winehq_bugzilla@yahoo.com --- Hi,
Runes of magic is also affected since this week, as it is now lunched through the same gameforge client
Please fins attached the console output.
More relevant part part seems to be : 0061:err:ntdll:NtQueryInformationToken Unhandled Token Information class 19! [...] 0061:fixme:process:CreateProcessInternalW Creating a process with a token is not yet implemented
Tested with wine 7d954f23356f0aaf49b1ef0c4bed83041cb41c08
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #12 from winehq_bugzilla@yahoo.com --- The following lines at the end of console output, suggest that it migh be a duplicate of bug #30439 :
0061:err:ole:create_server class {49bd2028-1523-11d1-ad79-00c04fd8fdff} not registered 0061:err:ole:CoGetClassObject no class object {49bd2028-1523-11d1-ad79-00c04fd8fdff} could be created for context 0x4
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #13 from nkb pdot@tutanota.com --- Still present in Wine 4.18.
(In reply to winehq_bugzilla from comment #12)
The following lines at the end of console output, suggest that it migh be a duplicate of bug #30439 :
0061:err:ole:create_server class {49bd2028-1523-11d1-ad79-00c04fd8fdff} not registered 0061:err:ole:CoGetClassObject no class object {49bd2028-1523-11d1-ad79-00c04fd8fdff} could be created for context 0x4
I think you're right. Should this issue be marked as duplicate, then?
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #14 from wineuser sickam@mail.ru --- Still present in 4.19. Any progress on this anyone?
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #15 from winehq_bugzilla@yahoo.com --- Created attachment 65694 --> https://bugs.winehq.org/attachment.cgi?id=65694 Console output 4.20
Reproduced with 4.20 (console output attached).
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #16 from winehq_bugzilla@yahoo.com --- Created attachment 65836 --> https://bugs.winehq.org/attachment.cgi?id=65836 Console output 4.21
Still present in 4.21
https://bugs.winehq.org/show_bug.cgi?id=47817
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #17 from Paul Gofman gofmanp@gmail.com --- Created attachment 65852 --> https://bugs.winehq.org/attachment.cgi?id=65852 POC patch
I've tested the issue with Metin2 (as it is probably the smallest thing to download for Gameforge client).
I could not reproduce any crash but no game window appeared after pressing 'Play' (while it was starting OK manually from game install directory). So maybe I am not reproducing all the issues which the others had but I tracked down an issue which is definitely there and prevents the game from showing up if run from current Gameforge client.
Before going to the main issue, I should also note that while running with winehq build binaries for Fedora I spotted the game complaining about not being able to hotpatch NtProtectVirtualMemory(). This did not affect anything in my case, i. e., it didn't work without the fix for the main issue, and did work with the main issue worked around without fixing the hotpatching. Still I am attaching the second patch to the PoC fix just in case.
The issue is triggered by the application setting up a new desktop. The application does it with user32.CreateDesktopW() (without WSF_VISIBLE flag, which is important here), sets it with SetThreadDesktop() and later changes its attributes with SetUserObjectInformationW(). After that it tries to initialize a d3d interface (d3d9, d3d8) with all the same result:
009a:warn:d3d:wined3d_init Failed to create adapter.
This is due to the following reverse sequence of unfortunate events: - by the time wined3d_init is called, the display driver was not yet initialized for the process; - dlls/user32/driver.c:load_desktop_driver() tried to load driver, but GetPropW( hwnd, display_device_guid_propW ) returns NULL string, so that results in creating a "null" display driver which is not good enough for rendering; - the latter happened because the window propery had never been set; normally explorer.exe creates the desktop window and sets that property, but not in this case; - the desktop window without required property was created in wineserver, upon processing get_desktop_window (server/window.c) request from first user32.GetDesktopWindow(); - that happened because the winstation did not have WSF_VISIBLE flag, and as winstation was not visible, server decided to avoid roundtrip. So the first call to user32.GetDesktopWindow() for the thread did not properly initialize desktop window by running explorer.exe because it received nonzero top_window from server right away.
The attached patch contains a quick fix for that, which allowed me to start the game from Gameforge client normally. I suppose a better fix would be to properly handle desktop attribute change.
There is still a bug when virtual desktop is used: - upon starting Gameforge client, the second virtual desktop is now created (with the patch applied), as probably expected; - the game then starts OK; - if I quit the game, the second desktop is closed, so that the attempt to start the game again from client fails.
But this looks like a separate issue.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #18 from winehq_bugzilla@yahoo.com --- Hi,
Confirming that with this patch applied on top of 4.21, Runes of magic runs fine.
Thank you so much !
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #19 from wineuser sickam@mail.ru --- Created attachment 65872 --> https://bugs.winehq.org/attachment.cgi?id=65872 Terminal Output 4.21 with TERA (Virtual Desktop enabled)
Hi Paul and many thanks for your efforts!
Unfortunately I'm still not able to run TERA with the patch applied.
With virtual desktop enabled: I can see the splash screen appearing, kinda buggy in the bottom right corner of the launcher window, when I click the "Play" button in the launcher, but after that, the whole launcher window just goes black.
Without virtual desktop enabled: I can see the splash screen appearing and a second window for the game itself opening, although this window isn't responsive. The splash screen keeps loading the whole time, so it seems to get stuck somewhere in the process.
Attached a terminal output with virtual desktop enabled.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #20 from wineuser sickam@mail.ru --- Created attachment 65873 --> https://bugs.winehq.org/attachment.cgi?id=65873 Terminal Output 4.21 with TERA (Virtual Desktop disabled)
...and attached a terminal output with virtual desktop disabled.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #21 from Paul Gofman gofmanp@gmail.com --- Created attachment 65874 --> https://bugs.winehq.org/attachment.cgi?id=65874 Add traces
(In reply to wineuser from comment #20)
Created attachment 65873 [details] Terminal Output 4.21 with TERA (Virtual Desktop disabled)
...and attached a terminal output with virtual desktop disabled.
I wonder does TERA work with some other launcher besides Gameforge?
I had an intention to test TERA from launcher, but could not create TERA login through Gameforge (both client and website) and gave up.
I am attaching a patch which adds some traces to winstation functions.
Could you please run that with both patches applied and WINEDEBUG=+winstation,+win,+wgl,+d3d11,+d3d9,+d3d,+seh,+loaddll, and attach (compressed) full output.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #22 from Paul Gofman gofmanp@gmail.com --- After looking a bit more into it, I found that I missed the true reason for the problem in Comment #17, sorry.
Application itself does not actually mess with winstations and desktops. The desktop for which rendering is failing is "__wineservice_winstation\Default". That happens because the games themselves are started with by 'gfservice.exe' service ("Gameforge Client Service"). The service has flags 0x10 in registry, thus it is not an interactive service. Then, the service creates game client with CreateProcessAsUserW() providing user token. Which is supported to create process with default user desktop set instead of the invisible services one. Creating processes with user tokens are not currently supported in Wine. The only thing we need for this case though is to set the user desktop for the newly created process (if the process is created on behalf of user), probably just like services.exe sets the desktop for service processes without SERVICE_INTERACTIVE_PROCESS flag.
Current workaround is to change HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\GameforgeClientService\Type to 110 from 10 (hex DWORD value), without any patches. This marks service as interactive and it is created with default visible workstation itself, so that the processes it creates inherit that.
https://bugs.winehq.org/show_bug.cgi?id=47817
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65852|0 |1 is obsolete| |
--- Comment #23 from Paul Gofman gofmanp@gmail.com --- Created attachment 65878 --> https://bugs.winehq.org/attachment.cgi?id=65878 PROC_THREAD_ATTRIBUTE_PARENT_PROCESS
A bit of more info on this. gf_service creates the game process using EXTENDED_STARTUPINFO_PRESENT, and extended startup info contains _ATTRIBUTE_PARENT_PROCESS, which sets the parent of the game process to the Gameforge launcher process.
I am attaching the patch with draft implementation for that in Wine. Maybe it will help TERA (Comment #19), but I've got no idea yet if this is related.
This patch fixes the initial issue of game process getting incorrect winstation, while this might be an accidental effect: it looks like Wine default winstation assigment is a bit different from Windows, and it might be that the game process should be getting the default desktop regardless of this parent substitute.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #24 from wineuser sickam@mail.ru --- Created attachment 65910 --> https://bugs.winehq.org/attachment.cgi?id=65910 Terminal Output 4.21 with TERA (patches applied)
(In reply to Paul Gofman from comment #21)
I wonder does TERA work with some other launcher besides Gameforge?
Yes, there's a launcher from En Masse as well (http://tera.enmasse.com/), but those are entirely different servers, so I've never tried that one on Wine.
Could you please run that with both patches applied and WINEDEBUG=+winstation,+win,+wgl,+d3d11,+d3d9,+d3d,+seh,+loaddll, and attach (compressed) full output.
See attachment. I ran it with virtual desktop enabled. Let me know, if you need another one with virtual desktop disabled.
I've also tried to apply the patch from comment #23, but that leaves me with the initial issue, again (nothing happens after clicking the "Play"-Button in the launcher). Do I have to apply this patch together with the first one?
Thanks for your help!
https://bugs.winehq.org/show_bug.cgi?id=47817
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65878|0 |1 is obsolete| |
--- Comment #25 from Paul Gofman gofmanp@gmail.com --- Created attachment 65913 --> https://bugs.winehq.org/attachment.cgi?id=65913 Test patch
(In reply to wineuser from comment #24)
Could you please run that with both patches applied and WINEDEBUG=+winstation,+win,+wgl,+d3d11,+d3d9,+d3d,+seh,+loaddll, and attach (compressed) full output.
See attachment. I ran it with virtual desktop enabled. Let me know, if you need another one with virtual desktop disabled.
I've tested TERA with Gameforge by now. I could reproduce original crash with plain Wine. It starts and works just fine for me with workaround from comment #22 and also with the patch from comment #23 instead of the workaround.
I am attaching a bit updated patch instead of the one attached to comment #23, but I don't think it should make any difference here.
So something is working different on your site. Can we do a few things to try to sort it out?
1. Could you please describe if you have any specifics in your host setup, like multiple monitors?
2. It looks strange that you have the original problem with the newer fix. Can you please take a latest git upstream Wine without any additional patches, apply the patch from this comment and also the one (which will add a few additional log messages, replacing the logging patch from Comment #21) which I will put to the next comment, fully rebuild Wine (as the patch touches different components), and try this way? And double check that you are using the rebuilt Wine?
If you still have the issue, could you please attach WINEDEBUG=+winstation,+loaddll,+seh,+win,process,+d3d log?
I've also tried to apply the patch from comment #23, but that leaves me with the initial issue, again (nothing happens after clicking the "Play"-Button in the launcher). Do I have to apply this patch together with the first one?
No, please disregard the first patch (I already marked it obsolete). While it may be helping to start something it is not doing a correct thing as I figured out later and testing it seems not particularly interesting in its current form.
https://bugs.winehq.org/show_bug.cgi?id=47817
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65874|0 |1 is obsolete| |
--- Comment #26 from Paul Gofman gofmanp@gmail.com --- Created attachment 65914 --> https://bugs.winehq.org/attachment.cgi?id=65914 Add traces to winstation functions
Updated patch for tracing Winstation functions.
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #27 from wineuser sickam@mail.ru --- (In reply to Paul Gofman from comment #25)
Hi Paul. Forget about what I said in comment #24. Your patch works flawlessly!
I had to slightly modify your patch file in order to make it work with my wine version and I must've made a mistake, when I attempted that the first time. After doing it from scratch again, everything works fine, now.
I'll try it with your updated version of the patch in the next few days, as well.
Many thanks to you, again!
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #28 from Paul Gofman gofmanp@gmail.com --- Should be fixed by https://source.winehq.org/git/wine.git/commit/74a74556ddac24855fde742e77dc23...
https://bugs.winehq.org/show_bug.cgi?id=47817
--- Comment #29 from winehq_bugzilla@yahoo.com --- Created attachment 65972 --> https://bugs.winehq.org/attachment.cgi?id=65972 5.0-rc1 - Console output.txt
Hi,
Confirming fixed in 5.0-rc1 for Runes of magic, with plain 5.0-rc1, no patch applied and no workaround (10 --> 110 in registry key).
Console output attached for the record.
Thank you for the great work ! Very much appreciated.
https://bugs.winehq.org/show_bug.cgi?id=47817
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Keywords| |patch Fixed by SHA1| |74a74556ddac24855fde742e77d | |c232670ebcd94
--- Comment #30 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Marking as fixed.
https://bugs.winehq.org/show_bug.cgi?id=47817
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #31 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.0-rc2.
-
WineHQ Bugzilla