I get the exact same bug and the game just closes itself, must be the anti-cheat update thing, I’m not exactly sure
1 Like
Hello Fexler,
Thank you for providing the crash dumps. I took a quick, preliminary look, and it appears that the issue is not directly related to Hyperion. In other words, there is no badware issue on your machine; instead, something else (possibly a bug on our end) is causing the problem. We will continue to investigate further, but unfortunately, this is a case where I can’t provide an immediate solution.
1 Like
Hello Everybody,
A few words about getting the exact same bug. What people experience may show the same symptoms, but it doesn’t mean they have the exact same bug. In this thread alone, we have identified at least 50 different reasons why the client crashes. So, please do not assume that just because you see the same symptoms as other folks, it is necessarily the same root cause.
As always, the quickest and hopefully the least painful way to determine the cause is by creating a full crash dump and forwarding it to us. In cases of badware issues, we can usually resolve them relatively quickly. However, when there is a genuine bug, it takes us longer to resolve. Some of these bugs we have successfully fixed have taken several weeks before they made it into the release.
Anyone having High Ping spikes or nah?
Oh well. Also this may or may not be helpful but I looked a bit into my files to see when this “bug” appeared then compared it with the client versions online and I‘m 100% sure that It, atleast for me, started happening in v580.
v578 worked completely fine
seems like v579 wasn‘t released so this bug appeared somewhere between 579-580
1 Like
I followed what it said, created the ClientSettings and ClientAppSettings.json file, and for some reason there is no logs folder.
The crash dumps sometimes show up in other locations. Just do a search for *.dmp files.
This was a bug in the engine. It should be fixed by now.
I am a little curious as to why the UWP isn’t affected by any of the issues. Is it due to it running on a different engine?
1 Like
Hello Danny,
UWP is running the 32-bit engine without Hyperion. For example, the teleporting issue was a bug in the engine. While the code is shared between the 64-bit and 32-bit versions, the shutdown timing for the worker thread differed between the two. The reason teleporting also resulted in crashes was that essentially the same shutdown code that is executed when the client terminates is also executed during teleportation.
As mentioned a few times in various posts, with the introduction of the 64-bit client, we effectively launched two new products: the 64-bit client itself, along with the 64-bit engine and Hyperion.
3 Likes
Looking at this image, it looks like the version released 6/21 was most likely when the bug started happening. I wasn’t playing that day, but roblox wasn’t broken prior to that day, and the bug started for me 6/22.
I also had a similar problem on 6/13, which caused the same problem, though the issue was fixed the next day. However, I can’t confirm if it was the same bug.
2 Likes
.log (29.6 KB)
My first issue was that I would click play on the roblox web, the engine would start doing it’s stuff but roblox doesn’t load at all it just instantly crashes.
Then i was told to try typing this roblox-player:1+launchmode:app+channel:zwinplayer64 on the web, which i did, i notice that now the game load but I would get an error of 262 something about “There was a problem sending data”. So i reinstalled roblox and now I’m back to my original problem, it just wouldn’t load at all. I’ve had this problem since byfon was first released, tried everything, asked tech support, but eventually they couldn’t fix it. So i was stuck using Roblox Microsoft store (which works) but its laggy for me and i don’t like when the mouse cursor escapes the window. I came across this post today and decided to send this message with my logs.
What exactly does the z-winplayer64 channel do? Out of curiousity I ran the roblox-player:1+launchmode:app+channel:zwinplayer64 command and ended up creating a logs folder, AnalyticsSettings.xml file, LocalStorage Folder, a file named frm.cfg, and a GlobalBasicSettings_13.xml file
It also produced 3 crash dumps instead of 1 when the roblox player crashed, with 2 of them being 888MB and 951MB, which are much larger than the usual 350-360MB crash dumps I usual produce.
Update: It apparently somehow opened an older version of roblox (Version 574) that existed before I started having the issues with crashes. My current issue has not been solved as thr command did not fix the issue, it just opened an outdated version that didn’t have the issue.
Switching channels is not recommended nor officially supported. We have received a number of reports from individuals getting stuck on older channels, and we suspect that this occurs due to client-side channel switching.
It is no secret that Roblox employs various channels for different purposes. However, by forcing a channel switch, you might end up with a build that was never intended for public use, which could lead to serious issues down the road.
1 Like
I see.
Fortunately I did not end up getting stuck in an older version, I will avoid switching channels in the future.
1 Like
So i’m not gonna get a report to my log?
Hello Blaze,
The client that produced the log file was version 574.1. The current version of the client is 589.0. The version gap is too big, and RCC rejects the connection.
ahh i see alright thx.
Ok so i reinstalled roblox and got the latest update but I’m not getting a log folder now.
The game doesn’t load whatsoever.
I tried this link you sent Going places and I can’t load in game at all so thats probably why I don’t get log file.
Thanks for replying, yh i just tried it and it’s the same issue. The roblox window doesn’t even appear, it gives that little ui saying starting roblox and after that nothing happens, roblox is just removed from the background (i checked using task manager to monitor everything)