BiliBili version doesn't launch since March 4th on my Arch Linux, intel+nvidia setup with proprietary driver. I've tried using Vanilla wine, Proton or Lutris wine GE, and re-downloading the game. Sometimes a black window appears, but most of the time just nothing happens.
However, when I use the same game files to launch to CN server, it works. Let me explain this. The game files of the BiliBili version and the CN version are exactly the same but two: PCGameSDK.dll in YuanShen_Data/Plugins, which is only needed by the BiliBili version, and the config.ini in the game folder, which describes which server to connect. After modified the two files, I can successfully launch the game to CN server.
BiliBili version doesn't launch since March 4th on my Arch Linux, intel+nvidia setup with proprietary driver. I've tried using Vanilla wine, Proton or Lutris wine GE, and re-downloading the game. Sometimes a black window appears, but most of the time just nothing happens.
However, when I use the same game files to launch to CN server, it works. Let me explain this. The game files of the BiliBili version and the CN version are exactly the same but two: PCGameSDK.dll in YuanShen_Data/Plugins, which is only needed by the BiliBili version, and the config.ini in the game folder, which describes which server to connect. After modified the two files, I can successfully launch the game to CN server.
Here is the log from steam proton:[https://pastecord.com/imahehufiz.rb](https://pastecord.com/imahehufiz.rb)
Downloaded Proton experimental-9.0-20240307b and the CN MHYPBase.dll.
Backtrace ntdll.dll + 0xF3FF points to RtlUserThreadStart (generic thread starter)
Backtrace kernel32.dll + 0x1473D points to BaseThreadInitThunk (generic thread starter)
Backtrace MHYPBase.dll + 0x2F44BF (call handler, from rip 0x6ffff86944bf) is located in uninitialized, executable program area. Cannot perform static analysis.
According to the stack dump, it attempts to create multiple threads
Interestingly, PCGameSDK.dll does yet not appear in the log. Does the game still start with the DLL being present but config.ini set to the main CN server?
Also: Have you yet tried Proton 8.0 to ensure that this issue wasn't introduced by the recent Proton Experimental update?
Downloaded Proton experimental-9.0-20240307b and the CN `MHYPBase.dll`.
1. Backtrace `ntdll.dll + 0xF3FF` points to `RtlUserThreadStart` (generic thread starter)
2. Backtrace `kernel32.dll + 0x1473D` points to `BaseThreadInitThunk` (generic thread starter)
3. Backtrace `MHYPBase.dll + 0x2F44BF` (call handler, from `rip 0x6ffff86944bf`) is located in uninitialized, executable program area. Cannot perform static analysis.
4. According to the stack dump, it attempts to create multiple threads
5. Interestingly, `PCGameSDK.dll` does yet not appear in the log. Does the game still start with the DLL being present but `config.ini` set to the main CN server?
Also: Have you yet tried Proton 8.0 to ensure that this issue wasn't introduced by the recent Proton Experimental update?
Thanks for your reply!
Yes, the game still start with the DLL being present but config.ini set to the main CN server. In this case, the game will connect to the CN server.
I have tried Proton 8.0-5. It doesn't help. What's more, after changing to Proton 8.0-5, even the CN version didn't launch. Switching back to Proton experimental didn't help. Here's the log(CN version with Proton 8.0):https://pastecord.com/orypahapah.rb
EDIT: There must be something wrong with my Proton 8.0-5. Any prefix that once used the Proton 8.0-5 cannot launch whatever version of the game. But Proton experimental and GE Proton 8-32 work with CN version(no Bilibili version though). So I may not be able to test the Proton 8.0.
Thanks for your reply!
Yes, the game still start with the DLL being present but `config.ini` set to the main CN server. In this case, the game will connect to the CN server.
I have tried Proton 8.0-5. It doesn't help. What's more, after changing to Proton 8.0-5, even the CN version didn't launch. Switching back to Proton experimental didn't help. Here's the log(CN version with Proton 8.0):[https://pastecord.com/orypahapah.rb](https://pastecord.com/orypahapah.rb)
EDIT: There must be something wrong with my Proton 8.0-5. Any prefix that once used the Proton 8.0-5 cannot launch whatever version of the game. But Proton experimental and GE Proton 8-32 work with CN version(no Bilibili version though). So I may not be able to test the Proton 8.0.
Proton 8.0-5c is not too important. After all, you already tried several other - and more importantly - slightly older Wine versions.
Whereas your new log file looks slightly different, it also fails in presumably the same manner: in RtlUserThreadStart. **** Crash! **** indicates that a crash dump was generated (to %TEMP%) and sent to miHoYo (unless you blocked all servers).
Since there is no notable file difference between CN and BiliBili, it might be caused by server-sent code upon startup. UserAssembly (used for running Lua bytecode) is yet not loaded, thus mhypbase is a possible culprit.
Theory 1: The game launches when mhypbase.dll is renamed or removed.
Upon entering the door, it is very likely that error 32-4302 appears.
Theory 2: The game launches when you're not connected to the internet.
If not, there must be a difference in the setup or game installation.
Proton 8.0-5c is not too important. After all, you already tried several other - and more importantly - slightly older Wine versions.
Whereas your new log file looks slightly different, it also fails in presumably the same manner: in `RtlUserThreadStart`. `**** Crash! ****` indicates that a crash dump was generated (to `%TEMP%`) and sent to miHoYo (unless you blocked all servers).
Since there is no notable file difference between CN and BiliBili, it might be caused by server-sent code upon startup. UserAssembly (used for running Lua bytecode) is yet not loaded, thus mhypbase is a possible culprit.
Theory 1: The game launches when `mhypbase.dll` is renamed or removed.
* Upon entering the door, it is very likely that error 32-4302 appears.
Theory 2: The game launches when you're not connected to the internet.
* If not, there must be a difference in the setup or game installation.
When mhypbase.dll is removed, the game launches, but crashes immediately after the "mihoyo" logo.
If I restore the mhypbase.dll, disconnect to the Internet, launch the game, reconnect to the Internet after the logo, then the game works. I've played the game for several minutes. But sometimes the game report a connection timeout at login page even after reconnecting to the Internet.
I've tried block the servers using the 440 patch. The game still crashes when connected.
When mhypbase.dll is removed, the game launches, but crashes immediately after the "mihoyo" logo.
If I restore the mhypbase.dll, disconnect to the Internet, launch the game, reconnect to the Internet after the logo, then the game works. I've played the game for several minutes. But sometimes the game report a connection timeout at login page even after reconnecting to the Internet.
I've tried block the servers using the 440 patch. The game still crashes when connected.
Unfortunately I cannot reproduce your crash issue on the OS version. It would be very helpful if another CN or BiliBili player could confirm or deny this behaviour.
dnstop -l 4 NETWORKDEVICE can show you any ordinary DNS queries. On my side, minor-api-os and apm-log-upload-os are resolved upon startup. However, blocking these might result in mixed results as you already have found previously: #401
Unfortunately I cannot reproduce your crash issue on the OS version. It would be very helpful if another CN or BiliBili player could confirm or deny this behaviour.
`dnstop -l 4 NETWORKDEVICE` can show you any ordinary DNS queries. On my side, `minor-api-os` and `apm-log-upload-os` are resolved upon startup. However, blocking these might result in mixed results as you already have found previously: https://notabug.org/Krock/dawn/issues/401#issuecomment-37799
The problem appears again today, and I have found the solution. Block dispatchcnglobal.yuanshen.com is enough.
The log uploading server in the script is also outdated, which is apm-log-upload.mihoyo.com now for Bilibili version. But in my case, there's no need to block it if you just want to play the game. Others may still want to block it if they don't want to upload logs to Mihoyo.
The problem appears again today, and I have found the solution. Block `dispatchcnglobal.yuanshen.com` is enough.
The log uploading server in the script is also outdated, which is `apm-log-upload.mihoyo.com` now for Bilibili version. But in my case, there's no need to block it if you just want to play the game. Others may still want to block it if they don't want to upload logs to Mihoyo.
Thank you for sharing your results. If dispatchcnglobal works similarly to the OS version, you might end up in an error while loading the server list. However, BiliBili version might only have one server, thus circumventing that issue.
With the 4.6.0 update being near, I will eventually add the domain to the 4.6.0 script in case of BiliBili versions - unless you ran into side-effects in the meantime.
EDIT: What about the other logging servers? Are they still up-to-date and in use?
Thank you for sharing your results. If dispatchcnglobal works similarly to the OS version, you might end up in an error while loading the server list. However, BiliBili version might only have one server, thus circumventing that issue.
With the 4.6.0 update being near, I will eventually add the domain to the 4.6.0 script in case of BiliBili versions - unless you ran into side-effects in the meantime.
EDIT: What about the other logging servers? Are they still up-to-date and in use?
I don't find log-upload.mihoyo.com in one-minute play. The other two are still in use. Note that I test the CN server with a Bilibili installation instead of a normal CN one.
EDIT: I found out later that I'm actually using a CN installation.
I don't find `log-upload.mihoyo.com` in one-minute play. The other two are still in use. Note that I test the CN server with a Bilibili installation instead of a normal CN one.
EDIT: I found out later that I'm actually using a CN installation.
Added to the patch script in 0f419d1ef566. Please let me know when there's any issue. Until then I consider this issue fixed.
Thank you for the feedback.
Added to the patch script in 0f419d1ef566. Please let me know when there's any issue. Until then I consider this issue fixed.
BiliBili version doesn't launch since March 4th on my Arch Linux, intel+nvidia setup with proprietary driver. I've tried using Vanilla wine, Proton or Lutris wine GE, and re-downloading the game. Sometimes a black window appears, but most of the time just nothing happens.
However, when I use the same game files to launch to CN server, it works. Let me explain this. The game files of the BiliBili version and the CN version are exactly the same but two: PCGameSDK.dll in YuanShen_Data/Plugins, which is only needed by the BiliBili version, and the config.ini in the game folder, which describes which server to connect. After modified the two files, I can successfully launch the game to CN server.
Here is the log from steam proton:https://pastecord.com/imahehufiz.rb
Downloaded Proton experimental-9.0-20240307b and the CN
MHYPBase.dll
.ntdll.dll + 0xF3FF
points toRtlUserThreadStart
(generic thread starter)kernel32.dll + 0x1473D
points toBaseThreadInitThunk
(generic thread starter)MHYPBase.dll + 0x2F44BF
(call handler, fromrip 0x6ffff86944bf
) is located in uninitialized, executable program area. Cannot perform static analysis.PCGameSDK.dll
does yet not appear in the log. Does the game still start with the DLL being present butconfig.ini
set to the main CN server?Also: Have you yet tried Proton 8.0 to ensure that this issue wasn't introduced by the recent Proton Experimental update?
Thanks for your reply! Yes, the game still start with the DLL being present but
config.ini
set to the main CN server. In this case, the game will connect to the CN server.I have tried Proton 8.0-5. It doesn't help. What's more, after changing to Proton 8.0-5, even the CN version didn't launch. Switching back to Proton experimental didn't help. Here's the log(CN version with Proton 8.0):https://pastecord.com/orypahapah.rb
EDIT: There must be something wrong with my Proton 8.0-5. Any prefix that once used the Proton 8.0-5 cannot launch whatever version of the game. But Proton experimental and GE Proton 8-32 work with CN version(no Bilibili version though). So I may not be able to test the Proton 8.0.
Proton 8.0-5c is not too important. After all, you already tried several other - and more importantly - slightly older Wine versions.
Whereas your new log file looks slightly different, it also fails in presumably the same manner: in
RtlUserThreadStart
.**** Crash! ****
indicates that a crash dump was generated (to%TEMP%
) and sent to miHoYo (unless you blocked all servers).Since there is no notable file difference between CN and BiliBili, it might be caused by server-sent code upon startup. UserAssembly (used for running Lua bytecode) is yet not loaded, thus mhypbase is a possible culprit.
Theory 1: The game launches when
mhypbase.dll
is renamed or removed.Theory 2: The game launches when you're not connected to the internet.
When mhypbase.dll is removed, the game launches, but crashes immediately after the "mihoyo" logo.
If I restore the mhypbase.dll, disconnect to the Internet, launch the game, reconnect to the Internet after the logo, then the game works. I've played the game for several minutes. But sometimes the game report a connection timeout at login page even after reconnecting to the Internet.
I've tried block the servers using the 440 patch. The game still crashes when connected.
Unfortunately I cannot reproduce your crash issue on the OS version. It would be very helpful if another CN or BiliBili player could confirm or deny this behaviour.
dnstop -l 4 NETWORKDEVICE
can show you any ordinary DNS queries. On my side,minor-api-os
andapm-log-upload-os
are resolved upon startup. However, blocking these might result in mixed results as you already have found previously: #401After 4.5 upgrade today, the issue disappears. I will keep an eye on it and report if it happens again or any progress is made.
The problem appears again today, and I have found the solution. Block
dispatchcnglobal.yuanshen.com
is enough.The log uploading server in the script is also outdated, which is
apm-log-upload.mihoyo.com
now for Bilibili version. But in my case, there's no need to block it if you just want to play the game. Others may still want to block it if they don't want to upload logs to Mihoyo.Thank you for sharing your results. If dispatchcnglobal works similarly to the OS version, you might end up in an error while loading the server list. However, BiliBili version might only have one server, thus circumventing that issue.
With the 4.6.0 update being near, I will eventually add the domain to the 4.6.0 script in case of BiliBili versions - unless you ran into side-effects in the meantime.
EDIT: What about the other logging servers? Are they still up-to-date and in use?
I don't find
log-upload.mihoyo.com
in one-minute play. The other two are still in use. Note that I test the CN server with a Bilibili installation instead of a normal CN one.EDIT: I found out later that I'm actually using a CN installation.
Have played 4.6.0 with dispatchcnglobal blocked, no side-effects found.
Thank you for the feedback.
Added to the patch script in 0f419d1ef566. Please let me know when there's any issue. Until then I consider this issue fixed.