#481 As of 2024-06-11, 4.7.0 runs at 90%+ CPU usage

Also reported in:

• Issue #480
• /r/linux_gaming

Upgraded packages since last known good (2024-06-10):

• libgif7:amd64 (5.1.9-2build2)

Testing setup

1. Mixed ESync enabled/disabled states
   • wineserver CPU usage formula: (ESync OFF) - (ESync ON) = 10 % (in this case)
2. CPU usage measured at the "Start game" login screen.

Startup with active internet connection:

• HoYoProtect.sys is attempted to load (EDIT 2024-06-13)
• Game process: 90 %
• Wineserver: 9 % (before the door, wineserver rises to ~20%)

Startup with no active internet connection:

• HoYoProtect.sys is not attempted to load (EDIT 2024-06-13)
• Game process: 23 %
• Wineserver: 1 % (esync on)

With mhypbase renamed:

• N/A. Game crash (this is a new behaviour)

With mhypbase 4.1.0 or 4.6.0, active internet connection:

• Game process: 32 %
• Wineserver: 10 % (esync off)

Blocking dispatchosglobal.y* replaces the CPU usage problem with being unable to login

• Domain is contacted at startup
• query_security_file grew from 16188 bytes (2024-06-05) to 16392 bytes
• Spoofing the domain in UnityPlayer.dll will eventually replace the CPU usage issue with error 31-4302.

What makes no difference:

• Logging servers blocked / unblocked
• Renaming the logging libraries

Result

• Like in game version 3.1.0 (and later), mhypbase again runs VERY inefficiently. Considering the wineserver load, I assume there's plenty of Windows kernel function calls, which includes file I/O.
• As of now, the game can still be entered when re-connecting to the internet after the Hoyoverse logo appears. It will then rest at 55 % CPU usage (instead of 90+ %) through the game.

TODO

• Spend more hours in backtracing
• Possibly provide a new patch unless it gets fixed in the next few days

In my case:

• DNS entries unblocked (no blocks in hosts and in adguard)
• Using upstream launcher (HoyoPlay)
• Using Proton via Steam
• Genshin Impact 4.7 (latest), mhypbase untouched

Findings:

• Not sure about wineserver, it's kind of 0%?
• GenshinImpact.exe hovers around 29.8% CPU, but I'm on a Ryzen 9 7900 so this might be making up for the extra use?
  • Admittedly, like 4 or 5 game sub-processes are blasting at 100% of a core each and the total CPU% is >700%, but that's on a 12c24t CPU.

An additional thought: We're fresh out of what we were calling the "grace period" in the days of old (heh). Maybe the anticheat is being "flipped on" and that's why there's an additional CPU load? (I'm just thinking here, I'm probably wrong)

(sorry for the email spam. notabug being itself.)

Can confirm. On 7735HS the difference between launching and running the game normally and with the disconnect trick is 700% CPU VS 300% CPU.

Using wine staging 9.8 with Esync, vanilla game launched with the original launcher patched due to #478 (not the new hoyo launcher).

The only blocked domains are those that got dunked by the old pathcer (also HSR ones).

Whereas I could again tamper the binary, I will instead try to create a helper application that automatically disables the internet connection on its startup and re-enables it on shutdown. The app should shut down itself as soon the game loaded far enough (e.g. 1 GiB RAM usage).

EDIT (after investing 5 hours): The application runs, but it seems that the proxy is ignored if the domain is not reachable. Hence, this might be a dead end.

@Krock In Linux - to turn off internet for application - you can crated group and launch application in this group.

But - it so annoying to do, and you need root access, it easier to just turn off internet for a moment.

(obviously you can turn off internet from root by service network stop then start, but for me it still easier to just turn off cable once when I play this game)

(you also can proxy winhttp dll or some unity/mono network stuff - idk if you have motivation to do it xD)

P.S. from comments in https://github.com/an-anime-team/an-anime-game-launcher/issues/383

nmcli n off ; %command% & sleep 15 ; nmcli n on

(it for steam obviously, for wine just replace %command% with wine script sh file)

@danilw Out out curiosity: which Wine version results in the fixme:sync:NtCreateTransaction spam? I cannot reproduce this with Wine 9.10.

you also can proxy winhttp dll or some unity/mono network stuff

Do you mean to compile winhttp with modifications to detect the process name upon opening sockets? Of course, nmcli is also a convenient solution, but comes at the cost of disabling network access system-wide.

Are there any users that are not affected by this issue - if so, I would like to know their Wine version as well.

spam? I cannot reproduce this with Wine 9.10.

wine-staging 9.10-1120.1

same as default wine 9.10-1120.1

both from OpenSuse distro packages - default OpenSuse wine there https://build.opensuse.org/package/show/openSUSE:Factory/wine

When wine 9.10-1.1 - previous version available in package manager - does not have this spam, same in staging.

@danilw Do you happen to know which git commit these two Wine (vanilla) builds are based on? Wine 9.10-1.1 appears to be "Revision 440", then what about 9.10-1120.1? Might there be additional information contained within your installed package?

Workaround documented as of 7a8c524

Time invested so far: about 18 hours

Gathered information as of now:

• The kernel driver is only attempted to load when the new payload is received upon startup.
• When the kernel driver fails to load, mhypbase becomes inefficient
  • Depending on the Wine version, another code path is taken, resulting in NtCreateTransaction call spam.
• A "VM" is used to process the bytecode payload and load the driver (also using XORfuscated data), which makes static analysis impossible.
• The active proxy settings in inetcpl.cpl are ignored if the server is unreachable.

This network off/on switching workaround does work, but I yet have to find a better solution.

Do you happen to know which git commit these two Wine (vanilla) builds are based on? Wine 9.10-1.1 appears to be "Revision 440", then what about 9.10-1120.1?

They updated to wine-9.11-1122.1 - latest now, I use it now.

It also spam NtCreateTransaction.

I linked wrong original wine 9.10 before in previous mesage - that does not spam, sorry for missinformation.

wine-9.11-1122.1 is:

https://build.opensuse.org/package/show/Emulators/wine

https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/x86_64/ - binary builds, type wine in search there.

I do not have additional information.

Obviously you should not have export WINEDEBUG=-all to see wine log.

Using an i7-4710MQ if I launch with WINEDEBUG="-all" I get 70-80% cpu usage from genshin.exe and 1-3% from wineserver. If I launch without that variable and have default debug of WINEDEBUG="warn+virtual,fixme+virtual,err+virtual" then I get 1-2% from wineserver and 20-30% from genshin.exe and 11% from the terminal output spam, e.g a net gain of 20-30% processing time. The NtCreateTransaction is clearly saturating the client from wineserver with ignored fixme's and genshin has clearly changed something with 4.7.0.

Or said another way, wineserver's client spends more time on terminal spam then processing the useless mmhypbase chatter. Should I be worried if I log in and mhypbase is falling behind the game in real time? I'm going to go with no since it never did anything for so many versions.

That was launching without the internet trick. Turning off internet then launching results in 11% cpu for genshin.exe and 1% for wineserver. All of this at the door for testing.

This terminal spam issue does yet not occur with stock Wine 9.11. Hence it is likely that the issue is limited to wine-staging and derivatives.

I wrote a basic performance measurement tool to analyze the high CPU issue directly in Wine. Result:

• Two threads do call RtlWakeAddressAll in a grand total of 500k times per second (at a slight logging bottleneck)
  • This includes a busy lock wait
  • No thread name provided.
• Rtl[Acquire|Release]SRWLockExclusive called 36000 1/s (issue) or 19000 1/s (with workaround)
• Rtl[Acquire|Release]SRWLockShared called 3500 1/s (issue) or 20000 1/s (with workaround)
  • This includes a busy lock wait

However, there is not a clear difference in time spent on specific functions.

I used the opportunity of the new 5.0 patch to try launching the game without temporarily disconnecting from the internet and it seems the issue has disappeared as my CPU usage remains within the expected region. Can anyone else confirm?

However, considering how new patches also used to pause some of the anti-cheat mechanisms for a few days for previous patches, it may just be a temporary change.

Never mind, I spoke too soon. I used to also see the high CPU usage during the login screen but that seemed not to be the case today anymore. After entering the game, CPU usage was still abnormally high, though. With the disconnect workaround, it went back to normal-ish (still a bit higher than previously but lower than without the workaround).