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).
Version 5.2 - new update - offline launch does not work anymore as fix.
Always high CPU usage and some stutters. Compared offline/normal launch - same.
I do not know any fix around it.
Version 5.2 - new update - offline launch does not work anymore as fix.
Always high CPU usage and some stutters. Compared offline/normal launch - same.
I do not know any fix around it.
I have everything same as before. Offline launch solves the problem. But the first few days after the 5.2 release was without need to turn off internet. Strange hoyovers.
I have everything same as before. Offline launch solves the problem. But the first few days after the 5.2 release was without need to turn off internet. Strange hoyovers.
@Cha14kayou right - offline launch work again.
But for few days it was not working for sure.
This how my "offline launch" CPU-usage look like (in game)
One thread at 80% and everything else around 30-40-50% (and not stutters)
When it was not working - I had 90+% on every CPU-core and some stutters in game.
@Cha14ka **you right - offline launch work again.**
But for few days it was not working for sure.
This how my "offline launch" CPU-usage look like (in game)
One thread at 80% and everything else around 30-40-50% (and not stutters)
When it was not working - I had 90+% on every CPU-core and some stutters in game.
Cannot say the same. I get a constant CPU load of about 90% just in the title screen alone when not disabling my Internet.
Edit: Maybe it worked for the first few days again? Today is the first day I tested playing without disabling my connection.
Cannot say the same. I get a constant CPU load of about 90% just in the title screen alone when not disabling my Internet.
Edit: Maybe it worked for the first few days again? Today is the first day I tested playing without disabling my connection.
But if I launch with offline - no internet till login menu error popup - 60fps stable and ~60-70% CPU usage.
Today update in Zenles Zone Zero - 1.6
I think - same is there now.
No stutters but 100% CPU usage and FPS <60 ~30-50
But if I launch with offline - no internet till login menu error popup - 60fps stable and ~60-70% CPU usage.
P.S. launcher just updated - 1.5.2.229
... and launcher wont start in ProtonGE anymore - no logs
But I changed to system wine-10.4 (Staging) - and launcher launched there.
I can not even start Genshin game anymore - it does not work in Proton (I tried 5 different Proton 7/8/9 experimental/ge) - nothing worked.
Only wine-10.4 (Staging) worked (with offline launch)
I have myself and few people also confirmed - game wont start anymore when online. Offline launch is works.
I assume it this https://www.notabug.org/Krock/dawn/issues/494
P.S. launcher just updated - 1.5.2.229
... and launcher wont start in ProtonGE anymore - no logs
But I changed to system wine-10.4 (Staging) - and launcher launched there.
I can not even start Genshin game anymore - it does not work in Proton (I tried 5 different Proton 7/8/9 experimental/ge) - nothing worked.
Only wine-10.4 (Staging) worked (with offline launch)
On March 28, 2025 I noticed that Proton 9 Experimental did again result in the high CPU usage issue, whereas vanilla Wine 10.4 showed no such behaviour. I assumed this would be an A/B test, thus did not double-check later on. In 5.4.0 (with Wine 9.21), the CPU usage issue was present. Something must have changed in recent Wine versions or Genshin itself if it happens that this issue is resolved in recent Wine-staging.
Unfortunately I cannot yet confirm this using vanilla Wine. Starting the game with an active internet connection lead to surprising results:
With Wine 10.4: RpcAssoc_BindConnection returns error code 1726 after which the wineserver throws an assertion failure. The system becomes unresponsive to any inputs (keyboard/mouse/incoming ssh connection) and completely hangs after querying the available Xorg modes upon game startup.
With Wine 10.6: All keyboard inputs are captured, the window manager crashes (this time with a one-liner log entry) but at least the system can be recovered by TTY or SSH.
Well, great.
Cross-reference to https://notabug.org/Krock/dawn/issues/495#issuecomment-41680
On March 28, 2025 I noticed that Proton 9 Experimental did again result in the high CPU usage issue, whereas vanilla Wine 10.4 showed no such behaviour. I assumed this would be an A/B test, thus did not double-check later on. In 5.4.0 (with Wine 9.21), the CPU usage issue was present. Something must have changed in recent Wine versions or Genshin itself if it happens that this issue is resolved in recent Wine-staging.
Unfortunately I cannot yet confirm this using vanilla Wine. Starting the game with an active internet connection lead to surprising results:
* With Wine 10.4: `RpcAssoc_BindConnection` returns error code `1726` after which the [wineserver throws an assertion failure](https://github.com/wine-mirror/wine/blob/wine-10.4/dlls/ntdll/unix/server.c#L1132). The system becomes unresponsive to any inputs (keyboard/mouse/incoming ssh connection) and completely hangs after querying the available Xorg modes upon game startup.
* With Wine 10.6: All keyboard inputs are captured, the window manager crashes (this time with a one-liner log entry) but at least the system can be recovered by TTY or SSH.
Well, great.
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).
Version 5.2 - new update - offline launch does not work anymore as fix.
Always high CPU usage and some stutters. Compared offline/normal launch - same.
I do not know any fix around it.
I have everything same as before. Offline launch solves the problem. But the first few days after the 5.2 release was without need to turn off internet. Strange hoyovers.
@Cha14ka you right - offline launch work again. But for few days it was not working for sure.
This how my "offline launch" CPU-usage look like (in game) One thread at 80% and everything else around 30-40-50% (and not stutters)
When it was not working - I had 90+% on every CPU-core and some stutters in game.
Looks like everything is working again without disabling internet. No cpu 90%+ load.
Cannot say the same. I get a constant CPU load of about 90% just in the title screen alone when not disabling my Internet.
Edit: Maybe it worked for the first few days again? Today is the first day I tested playing without disabling my connection.
Today update in Zenles Zone Zero - 1.6
I think - same is there now.
No stutters but 100% CPU usage and FPS <60 ~30-50
But if I launch with offline - no internet till login menu error popup - 60fps stable and ~60-70% CPU usage.
Yeah, also noticed this on ZZZ today
I have myself and few people also confirmed - game wont start anymore when online. Offline launch is works. I assume it this https://www.notabug.org/Krock/dawn/issues/494
P.S. launcher just updated - 1.5.2.229 ... and launcher wont start in ProtonGE anymore - no logs
But I changed to system wine-10.4 (Staging) - and launcher launched there.
I can not even start Genshin game anymore - it does not work in Proton (I tried 5 different Proton 7/8/9 experimental/ge) - nothing worked. Only wine-10.4 (Staging) worked (with offline launch)
Cross-reference to #495
On March 28, 2025 I noticed that Proton 9 Experimental did again result in the high CPU usage issue, whereas vanilla Wine 10.4 showed no such behaviour. I assumed this would be an A/B test, thus did not double-check later on. In 5.4.0 (with Wine 9.21), the CPU usage issue was present. Something must have changed in recent Wine versions or Genshin itself if it happens that this issue is resolved in recent Wine-staging.
Unfortunately I cannot yet confirm this using vanilla Wine. Starting the game with an active internet connection lead to surprising results:
RpcAssoc_BindConnectionreturns error code1726after which the wineserver throws an assertion failure. The system becomes unresponsive to any inputs (keyboard/mouse/incoming ssh connection) and completely hangs after querying the available Xorg modes upon game startup.Well, great.