Wine Regression in 17.04 Ubuntu, 16.04 works

[Igor Polyakov]

https://bugs.winehq.org/show_bug.cgi?id=43011

I did a clean install of 17.04, installed Wine staging 2.10, and I experienced this bug. I formatted that partition, did a clean install of 16.04, installed Wine staging 2.10, and no bug.

It seems that this is not an issue with Wine, but a regression in Ubuntu 17.04

[Igor Polyakov (iopq)]

Created attachment 58153
first file that gets loaded

I built this version of Wine to run StarCraft 1.18: https://github.com/awesie/wine-starcraft

The single player works fine. However, when I click on Multiplayer, there's a slight delay and it loads http://127.0.0.1:42475/gamedata/webui/dist/LANProtocolSelectionPanel/LANProtocolSelectionPanel.html?port=42475&guid=6334

then it loads http://127.0.0.1:42475/gamedata/webui/dist/GatewayPanel/GatewayPanel.html?port=42475&guid=41

then it loads http://127.0.0.1:42475/gamedata/webui/dist/InfoPanel/InfoPanel.html?port=42475&guid=18467

after that, it starts to load the corresponding JS files

and only after all of that, there's a longer delay and it starts to download http://127.0.0.1:42475/gamedata/webui/dist/lib/fonts/Eurostile-Reg.otf

once that is done, I see text in the Battle.net menu

Also, it starts to download http://127.0.0.1:42475/gamedata/webui/dist/lib/fonts/EurostileExt-Reg.otf and when that is done, the text changes in appearance

All in all, it takes a little bit over 30 seconds to finish loading this menu. It takes as long to show the login modal. It takes this long to show the create game modal. It takes as long to show player names in the game menu.

While the game is playable when I start it, the delay in making the game often makes people leave before I can even select my race or see their chat messages.

[Igor Polyakov (iopq)]

Created attachment 58154
second file that gets loaded

[Igor Polyakov (iopq)]

Created attachment 58155
third file that gets loaded

[Igor Polyakov (iopq)]

Created attachment 58156
The logs starting from when you go to the battle.net menu up until it gets loaded

[Olivier Dierick (o-dierick)]

(In reply to Igor Polyakov from comment #0)
> I built this version of Wine to run StarCraft 1.18:
> https://github.com/awesie/wine-starcraft
>

This is a custom patched wine version.
Please retest with plain wine or wine-staging (development version is currently 2.7).

[Bruno Gonçalves de Jesus (00cpxxx)]

(In reply to Olivier F. R. Dierick from comment #4)
> This is a custom patched wine version.
> Please retest with plain wine or wine-staging (development version is
> currently 2.7).

This bug depends on bug 42741, it is currently not testable in plain nor staging.

[BadBrainJohnson (badbrainjohnson)]

@Igor I still didn't experience this behaviour. Can I provide any information about my setup that might help find the cause?

[Igor Polyakov (iopq)]

(In reply to Tim from comment #6)
> @Igor I still didn't experience this behaviour. Can I provide any
> information about my setup that might help find the cause?

Sure, I'd like to see who has this issue and who doesn't. I am on Ubuntu 17.04, I have an Intel i7-4770k processor and an AMD R9 290 graphics card.

https://www.twitch.tv/videos/141235185

you can see how it happens in my video

[BadBrainJohnson (badbrainjohnson)]

(In reply to Igor Polyakov from comment #7)
> (In reply to Tim from comment #6)
> > @Igor I still didn't experience this behaviour. Can I provide any
> > information about my setup that might help find the cause?
>
> Sure, I'd like to see who has this issue and who doesn't. I am on Ubuntu
> 17.04, I have an Intel i7-4770k processor and an AMD R9 290 graphics card.

[...]

I'm on Zesty as well, running on a quite old laptop with an Intel P6200 (has integrated HD Graphics). Kernel is a custom 4.11 (could provide my .config, but I doubt that this is a kernel issue)

As I don't have much experience with wine, I struggled to get this to work and tried many things over two days. From memory and current config, here's what currently works for me:
1. set up a chroot to build wine and run the game as explained here: https://wiki.winehq.org/Building_Wine
2. apt-get build-dep wine32-development to satisfy the dependencies, added libva-dev manually, a plain ./configure then gives me no warnings that seem important, make && make install
3. winetricks corefonts
4. winecfg options:
- default Windows Version is Windows 7, for StarCraft.exe it's WinXP
- default Staging: checkboxes 1, 2 and 4 checked
- StarCraft.exe Staging: I just realized, that those options are also application specific...so no boxes checked, which confuses me as the STARCRAFT note in the src explicitly states to check box 4 to avoid crashes which do not happen for me
5. I used StarCraft-Setup.exe from Blizzard to install the game, the .exe for the public test realm also works

I'm not sure if this is any help, but I'd be happy to provide more information. Or even start from scratch to reproduce my exact steps.

[Igor Polyakov (iopq)]

I built it with LXC like it says here https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu

but I also have a binary from someone else that I test on, the results are the same

it also works with WINEARCH=win64 the same way, around the same amount of delay.

[Evren-demirk4n (evren-demirk4n)]

Hi Igor,
I created a custom installer for StarCraft 1.18.x on Ubuntu using the latest wine-staging source code. Andrew's build was based on 2.6, this uses 2.7 and you don't need to set XP mode for StarCraft.exe .It works with Global Settings (Windows 7) Actually, it crashes if you do otherwise :)

Give it a shot, maybe it helps your CEF latency issue.

https://github.com/aveferrum/wine-starcraft-installer

[Igor Polyakov (iopq)]

I just tried the script. It worked well to install the game and get to run. But it does not actually fix the issue.

[Igor Polyakov (iopq)]

I tried running this on 2.8 staging, I'm still getting this issue. I also switched to LXDE and that didn't affect it.

[Rfjdomingues (rfjdomingues)]

I have the same issue - running Fedora 25, GNOME X11, on a Intel CPU with HD3000 integrated graphics.

Using wine 2.8 staging the game installs, loads and plays perfectly without any modification to wine.

On the other hand, when connecting to BNET the UI interface appears without any text, unless I wait 2-3 minutes. Whenever I change menus I have to wait another 2-3 minutes for the text to appear.

This issue is not exclusive to Wine as there are people reporting this issue on Windows/MAC machines in the BNET forums.

I have another machine, running Windows 8.1, where I can play multiplayer flawlessly from a USB drive. Bizarrely, I run into the same issue if I start the game from a copy in the machine's HDD - menus without any text.

On another machine running Windows 7, I have no trouble playing from either the USB or the HDD.

Every time I load the game on the Windows machines, a popup appears asking if I want to add the game to the Windows firewall. On Wine the same popup never appears.

[Evren-demirk4n (evren-demirk4n)]

(In reply to R Domingues from comment #13)
> I have the same issue - running Fedora 25, GNOME X11, on a Intel CPU with
> HD3000 integrated graphics.
Hi,

In my current working no-delay-in-Bnet setup, I found that StarCraft.exe is spawning a ClientSdkFirewallHelper.exe process to check if StarCraft.exe is excluded from Firewall or not.

0009:Call KERNEL32.CreateProcessW(00000000,037991b4 L"ClientSdkFirewallHelper.exe -check \"C:\\local_games\\StarCraft\\StarCraft.exe\"",00000000,00000000,00000000,08000020,00000000,0390bf94 L"C:\\local_games\\StarCraft",0032f3cc,0032f410) ret=1006ee90

....
[snip]

with a return of:

0009:Ret KERNEL32.CreateProcessW() retval=00000001 ret=1006ee90

and generating a FIXME of "fixme:hnetcfg:fw_profile_get_FirewallEnabled 0x12fdb0, 0xc2f5a0"

Now, I am not sure what "retval=00000001" means...An error? A confirmation that StarCraft.exe is excluded from the firewall? Or something else. Afaik there's no firewall implementation in Wine.

Here, https://us.battle.net/forums/en/starcraft/topic/20754425833 Blizzard dev suggests checking/allowing StarCraft.exe on the firewall using the following command. (ClientSdkFirewallHelper.exe should be within the same folder with StarCraft.exe)

"ClientSdkFirewallHelper.exe -allow [Path to starcraft.exe]"

If this solves your popup and delay issue on Windows 8.1 we may narrow the issue to Firewall call. What I am thinking that, once you enter the multiplayer menu, ClientSdkFirewallHelper gets fired but unable to return immediately causing a timeout and delay for the main StarCraft.exe process. And following that for each subsequent action, called again..and again waiting for a timeout to continue.

Another workaround may be deleting/renaming "ClientSdkFirewallHelper.exe". Once I renamed that file, I didn't get a crash but SC asked me to "add StarCraft to the whitelist" each time I clicked on the Multiplayer menu. I selected OK/cancel and again once I got into the Bnet menu, there was no delay.

You can create a more detailed log adding the WINEDEBUG=+relay prefix and dump the output to a file for further inspection. Search for "FireWall", I hope your debug output may bring us one step closer to the solution.

WINEDEBUG=+relay WINEPREFIX="/home/ras/wine-prefix/sc/" wine /home/ras/wine-prefix/sc/drive_c/local_games/StarCraft/StarCraft.exe &>relmsg.log

[Igor Polyakov (iopq)]

I tried this, but renaming the file only gave me the prompt. The Battle.net menus are still slow. I reverted the change and ran it with WINEDEBUG set to +relay. I can't attach the whole file, since it's 400MB. I'll attach the relevant lines.

[Igor Polyakov (iopq)]

Created attachment 58253
Firewall calls

This is with ClientSdkFirewallHelper.exe present

[Igor Polyakov (iopq)]

Created attachment 58254
this is with ClientSdkFireWallHelper.exe renamed

[Rfjdomingues (rfjdomingues)]

(In reply to Evren from comment #14)
> Here, https://us.battle.net/forums/en/starcraft/topic/20754425833 Blizzard
> dev suggests checking/allowing StarCraft.exe on the firewall using the
> following command. (ClientSdkFirewallHelper.exe should be within the same
> folder with StarCraft.exe)
>
> "ClientSdkFirewallHelper.exe -allow [Path to starcraft.exe]"

I think you've got it wrong, the DEV asked a user to download and run a different utility than the one present in the game folder (same name, different files ~400kb vs ~250kb). I ran it and it simply added both starcraft.exe and mdnsresponder.exe to the Windows firewall. When I run the game, the pop up doesn't show anymore but the problem still remains.

I deleted starcraft.exe and mdnsresponder.exe entries from the firewall whitelist, and I ran StarCraft from the USB drive. The popup appears, I press OK but nothing is added to the firewall. The moment I select a gateway and try to login I get a message from the Windows Firewall asking to add StarCraft to the whitelist. mdnsresponder.exe is not whitelisted but the game still runs.

> If this solves your popup and delay issue on Windows 8.1 we may narrow the
> issue to Firewall call. What I am thinking that, once you enter the
> multiplayer menu, ClientSdkFirewallHelper gets fired but unable to return
> immediately causing a timeout and delay for the main StarCraft.exe process.
> And following that for each subsequent action, called again..and again
> waiting for a timeout to continue.

It may be worth noting that while the text is not rendered, the starcraft doesn't lock. I can't still go back in the menus.

[Igor Polyakov (iopq)]

I installed a fresh Ubuntu 17.04 on a separate hard drive; installed 32 bit drivers and installed the game fresh. I'm still running into this issue.

[Igor Polyakov (iopq)]

I tried a clean 16.04 Ubuntu install and this bug is gone. I did roughly the same steps as a clean 17.04 install which had this bug. This is regression in Ubuntu 17.04

[Winetest (winetest)]

(In reply to Igor Polyakov from comment #20)
> I tried a clean 16.04 Ubuntu install and this bug is gone. I did roughly the
> same steps as a clean 17.04 install which had this bug. This is regression
> in Ubuntu 17.04

Does your wine versions match also if you build from source do you have the same configuration at compile time?

[Igor Polyakov (iopq)]

(In reply to winetest from comment #21)
> (In reply to Igor Polyakov from comment #20)
> > I tried a clean 16.04 Ubuntu install and this bug is gone. I did roughly the
> > same steps as a clean 17.04 install which had this bug. This is regression
> > in Ubuntu 17.04
>
> Does your wine versions match also if you build from source do you have the
> same configuration at compile time?

I installed 2.10 staging on both by following the steps here:

https://wine-staging.com/installation.html#distro_ubuntu

[Jan Kroeze (thejcwk)]

This bug also affects StarCraft Remastered v1.20.2.2660 using wine 1.15 (staging).

The Battle.net forums have many reports of the same symptoms. Most of them seem to be related to anti-virus programs or firewalls.

Has anyone had any luck fixing this problem?

[Igor Polyakov (iopq)]

Yes, installing Ubuntu 16.04 instead of 17.04 resolved my issue.

[Konrad Błachnio (zbawcapiekiel)]

I confirm the bug. In lubuntu 17.04 after installing starcraft as described in https://appdb.winehq.org/objectManager.php?sClass=version&iId=35639 i have experienced ~30 lag in every battlenet window.

I confirm workaround. After downgrading to lubuntu 16.04 and installing starcraft again there is no lag and game is working.

[Winetest (winetest)]

Someone said bug 2467 is the same as this bug here.

[Winetest (winetest)]

(In reply to winetest from comment #25)
> Someone said bug 2467 is the same as this bug here.

actually no, but this bug is mentionedoed there.

[jre (jre-phoenix)]

Looking at this and the upstream bugreport you didn't use the Ubuntu Wine packages, but wine-staging from upstream (since only the latter allows to even install StarCraft Brood War). Therefore closing for "Wine in Ubuntu".

Not sure if this is a regression in other parts of Ubuntu, or something else, though.

[Arilou (arilou)]

Just wanted to update a workaround, it seems like the issue is that the API that Blizzard are using (is probably Winhttp) which ends up doing DNS lookups for wpad, which simply times out.

A simple solution that worked for me was to add to /etc/hosts
127.0.0.1 wpad
127.0.0.1 wpad.lan

[Hans-meelstraat (hans-meelstraat)]

Please attach a WINEDEBUG=+winhttp trace.

[Arilou (arilou)]

Created attachment 70023
Winhttp log showing the issue

The Wine winhttp log, I have submitted a patch which skips the WPAD flow in case the access is to localhost

[Arilou (arilou)]

Oops I stand correct the log is with my patch inside, but you can see see the requests to WinHttpGetProxyForUrl calls with 127.0.0.1

[Hans-meelstraat (hans-meelstraat)]

(In reply to arilou from comment #30)
> Oops I stand correct the log is with my patch inside, but you can see see
> the requests to WinHttpGetProxyForUrl calls with 127.0.0.1

Can you get a WINEDEBUG=+timestamp,+winhttp log without the patch?

[Arilou (arilou)]

Created attachment 70024
winhttp+timestamp

[Hans-meelstraat (hans-meelstraat)]

(In reply to arilou from comment #32)
> Created attachment 70024 [details]
> winhttp+timestamp

> 154383.366:03ec:trace:winhttp:resolve_hostname failed to get IPv4 address of L"wpad", retrying with IPv6

Resolving a hostname shouldn't take seconds. I can't reproduce it here, can you check your DNS configuration? What does 'dig wpad' give?

[Arilou (arilou)]

There is nothign fancy in my resolv.conf (It's Fedora 34)
there is simply
# Generated by NetworkManager
search lan
nameserver 192.168.1.1

192.168.1.1 is the router...

dig wpad does return immediately here is the output

; <<>> DiG 9.16.15-RH <<>> wpad
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63314
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wpad. IN A

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu May 20 14:06:35 IDT 2021
;; MSG SIZE rcvd: 22

[Robert Roth (evfool)]

After having the same issue as described here, and also having the wpad DNS query taking 3843 msec (dig wpad output below) I am also available for providing any more information to get this investigated, maybe having the logs from someone else too will help narrowing the issue down.

I have also tried adding wpad to /etc/hosts as 127.0.0.1 as suggested in workaround by arilou, but that broke multiplayer of Starcraft completely for me, so removed them.

; <<>> DiG 9.16.15-RH <<>> wpad
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31665
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;wpad. IN A

;; Query time: 3843 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon May 31 11:34:10 EEST 2021
;; MSG SIZE rcvd: 33

[Hans-meelstraat (hans-meelstraat)]

(In reply to robert.roth.off from comment #35)
> After having the same issue as described here, and also having the wpad DNS
> query taking 3843 msec (dig wpad output below) I am also available for
> providing any more information to get this investigated, maybe having the
> logs from someone else too will help narrowing the issue down.
>
> I have also tried adding wpad to /etc/hosts as 127.0.0.1 as suggested in
> workaround by arilou, but that broke multiplayer of Starcraft completely for
> me, so removed them.
>
> ; <<>> DiG 9.16.15-RH <<>> wpad
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31665
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;wpad. IN A
>
> ;; Query time: 3843 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Mon May 31 11:34:10 EEST 2021
> ;; MSG SIZE rcvd: 33

Is this also Fedora 34?

[Robert Roth (evfool)]

> Is this also Fedora 34?

Yes, this is also Fedora 34, but the issue happened also on Fedora 33 with wine staging.

[Hans-meelstraat (hans-meelstraat)]

(In reply to robert.roth.off from comment #37)
> > Is this also Fedora 34?
>
> Yes, this is also Fedora 34, but the issue happened also on Fedora 33 with
> wine staging.

Might be related to the switch to systemd-resolved in Fedora 33 then.

[Robert Roth (evfool)]

(In reply to Hans Leidekker from comment #38)
> (In reply to robert.roth.off from comment #37)
> > > Is this also Fedora 34?
> >
> > Yes, this is also Fedora 34, but the issue happened also on Fedora 33 with
> > wine staging.
>
> Might be related to the switch to systemd-resolved in Fedora 33 then.

Definitely was caused by that, as disabling systemd-resolved did solve the long waits. It also explains why Ubuntu had this since quite a long time, as they switched to systemd-resolved about 3 years ago, in 16.10. That explains why someone mentioned in a comment that 16.04 doesn't have the issue, and 17.04 has this issue.

I still can't connect to any battle net servers, which I will need to investigate and probably report separately (unless it was fixed by other bugfix, I saw some recent changes related to battle net games in wine), but at least the resources are loaded quickly.

[Deathtbo (deathtbo)]

Fedora 36 here. The long load times are a beat down, and I had no luck adding 127.0.0.1 wpad to the hosts file.

After some research tho, it seems some Windows 10 users found a way to "break" wpad by adding 255.255.255.255 wpad in their hosts file. Adding it to my hosts file makes all the menus instantly load.

But I'm not much of a networking guy. I don't know the ramifications of adding the broadcast address to your hosts file. I was hoping to share my findings and maybe gain some clarity on this.