As in the title, If I launch UE5, or just have the Epic Games store open, the Epic Webhelper task will just continue to eat up ram until either my PC crashes bc im not on it at the moment, or I ALT+F4 it from task manager
Hey there @Starcrater21! Sounds like the Epic Web Helper subtasks might be having some form of memory leak. I can help us get that reported to the correct team, though I have to gather a bit more information.
May I know your system specs?
Does the leak occur every time you use EGS or is it only sometimes?
It’s these specific subtasks right?
Do they multiply in number or just take more resources individually?
If you right click and go to details, how much difference in memory for the process change over the course of an hour? (I’m currently testing this as well to verify things).
1 Like
AMD Ryzen 3600 6 Core CPU, 2 TB SSD + 500NvME drive, 32 GB of RAM, and a AMD RX 5500 XT 8GB GPU
The leak only seems to happen after a while of leaving EGS running, its just one single helper, usually when I leave my PC running to go do something for a few hours or so, one of the helpers takes up the entirety of my PCs free RAM
1 Like
Great, thanks for reporting! I personally couldn’t get the leak to be nearly as heavy, so I’m worried there’s environmental factors here. Though we have enough information to pass a report to the team nonetheless and see if it’s replicable on their side.
3 Likes
I just had something similar occur in UE 5.1.1. My computer was near-unresponsive and task manager showed 99% of my RAM was being used. Whilst the two open Epic WebHelper processes didn’t show a lot of RAM usage, when I force-quit them my RAM usage dropped down to normal idle levels. I didn’t have the Epic Games Store open and was running Unreal via Visual Studio.
I’ve being doing plugin development and I’m using the built in Unreal CEF browser to browse for and download some files but hadn’t touched the browser during the current run of the engine.
Specs:
Ryzen 9 5900X
64GB Ram
Windows 11
Hey there @Mystfit! Welcome back to the community! Great information! So it confirms what Starcrater was saying and it’s likely one of the web helpers the engine creates instead of the web store. Fantastic information.
Awesome capture! If it’d be alright, I’d like to ask you add another report separate from my own would be great in case there needs to be follow-up since it seems the leak itself isn’t as bad for some other users, there may be a mix of environmental things exasperating the issue that might be identified.
2 Likes
I posted my leak here, 4 gigs, been happening a lot on windows 11. I dont see my comment though. Its not isolated to him though, i dont go to 26gigs but still 4gigs with the web helper is gg
Hey there @KeanuPianu! Welcome to the community! Thanks! We’re getting a couple of reports of this sporadically. This is one of those elusive ones only the internal teams can wrangle. I’m keeping an eye out for when an issue is created to track it but haven’t come across it yet.
me too, ram usage 100%, without epic open 32gb only used 25%, then after some time epic open / UE opened, it suddenly unresponsive because of epicwebhelper eat all the rest of ram usage + chaced 20++ GB too
Hey there @ryan.af! Welcome to the community! Thanks for your input! May I also know your specs/OS for reporting purposes?
same as you, the ram usage increase every second, I had to delete epic game and never install this again on my pc.
Hey there @Hichem47! Welcome to the community! It seems this issue is currently only relegated to 5.1 - 5.3 in some very specific instances. You should still be able to run 5.03 and down without this issue while it’s being investigated!
Can confirm this is an issue. I and several others at my company have been dealing with this for several months. Today I had to kill EpicWebHelper processes six separate times. Seems to trigger when I launch the editor/PIE from VS (DebugGame Editor config).
Looking at the command that launches the offending processes, they seem to be related to telemetry of some sort? I don’t know if both processes having duplicate arguments creates a problem.
Interestingly, I found similar memory leak issues for almost identical arguments to a chrome process (Electron `chrome --type=renderer --field-trial-handle=...` won't shut down, eats up Memory - Ask Ubuntu). This suggests to me that there is a common component (electron?) which is at fault.
I do not see an open bug ticket for this issue. Downgrading (or upgrading) are not options for us at the present time.
The Command Line:
Edit to add the indicated log file contains several repetitions of these two lines:
[1215/164834.060:ERROR:gpu_init.cc(426)] Passthrough is not supported, GL is disabled
[1218/080324.930:WARNING:dns_config_service_win.cc(712)] Failed to read DnsConfig.
Dunno if it’s fixed already, but It’s reproduced for me. Epic web helper ate almost all my ram(I have only 8gb). I closed the process so I don’t have screenshot for this topic(
BTW it was a separate task. My EGS was closed.
I can confirm it’s still not fixed. Happened multiple times here through the week.
My setup is:
Unreal 5.2.1, Rider IDE, happened with unreal launcher open and closed.
Just got this issue today. PC slowed to a crawl so I checked taskmgr. Two EpicWebHelpers taking up 30+gb each of 96gb total. I had to kill both of them because they were both still climbing. Didn’t even have EGS open, what’s the deal? Need more communication on this.
Hey there @MPinoBM and @Freznosis! Welcome to the community and welcome back respectively. Were these processes entirely in editor or occurring in standalone builds as well? Some user’s had experienced that issue being corrected with more recent versions, though it doesn’t seem universal.
Taking a bit of a dive into the web helper in the source, while I can’t determine the cause exactly. Judging by the layout of the classes, it’s used by other calls inside the engine to handle some rendering tasks. Though I haven’t ascertained what all passes through it. More than likely some task given is likely hung up and being sent over and over. I’m filing an updated bug report myself, but any more information you could provide it could assist: