Upgraded packages since last known good (2024-06-10):
libgif7:amd64 (5.1.9-2build2)
Testing setup
Mixed ESync enabled/disabled states
wineserver CPU usage formula: (ESync OFF) - (ESync ON) = 10 % (in this case)
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
Also reported in:
* Issue #480
* [/r/linux_gaming](https://www.reddit.com/r/linux_gaming/comments/1ddlfly/genshin_100_cpu_usage_since_today/)
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
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.)
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).
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.
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)
@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)
(it for steam obviously, for wine just replace %command% with wine script sh file)
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.
@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.
When wine 9.10-1.1 - previous version available in package manager - does not have this spam, same in staging.
> 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.
@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.
Obviously you should not have export WINEDEBUG=-all to see wine log.
> 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.
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.
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.
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).
~~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).
Also reported in:
Upgraded packages since last known good (2024-06-10):
Testing setup
Startup with active internet connection:
Startup with no active internet connection:
With mhypbase renamed:
With mhypbase 4.1.0 or 4.6.0, active internet connection:
Blocking
dispatchosglobal.y*replaces the CPU usage problem with being unable to loginquery_security_filegrew from 16188 bytes (2024-06-05) to 16392 bytesWhat makes no difference:
Result
TODO
In my case:
Findings:
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 stopthen 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:NtCreateTransactionspam? I cannot reproduce this with Wine 9.10.Do you mean to compile winhttp with modifications to detect the process name upon opening sockets? Of course,
nmcliis 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.
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:
NtCreateTransactioncall spam.inetcpl.cplare ignored if the server is unreachable.This network off/on switching workaround does work, but I yet have to find a better solution.
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=-allto 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:
RtlWakeAddressAllin a grand total of 500k times per second (at a slight logging bottleneck)Rtl[Acquire|Release]SRWLockExclusivecalled 36000 1/s (issue) or 19000 1/s (with workaround)Rtl[Acquire|Release]SRWLockSharedcalled 3500 1/s (issue) or 20000 1/s (with workaround)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).