Why Would Visual Studio Lock Up My Computer? – Unreal Engine 4 (UE4) - VS2022/2019

I have had this topic posted on the Microsoft Forums, as I was unable to have it posted on here.

From that forum thread, I was informed to post it on here or: Developer Community.

Please let me know if you require additional details to solve the problem.

EDIT: (From the Rider Support forums): The problem was SpyHunter 5 (switching over to using Rider was not enough). After having this disabled, Rider was able to have the solution load into the UE4 Editor just fine. SpyHunter is quite a ‘powerful’ piece of anti-malware/anti-spyware software, so it might have caused issues for Rider (or even Visual Studio).

Out of curiosity, how long have you let it sit to see if the lockup resolves?

I have seen VS2019 Professional cause my computer to become nearly unresponsive for 5+ minutes when resolving symbols. Which is frustrating – and why I’m now using Rider for Unreal work, which does not seem to have the symbol resolution problem and has really tight integration with the engine as well – but it did always eventually recover.

1 Like

Ah, the longest I have left it on for (whilst trying to get the lockup issue resolved) was about 3/4 minutes. I will try leaving it on for a bit longer (when it locks up).

Thanks for the recommendation of Rider by the way, I will have to check that out :slight_smile:.

I have gone through the steps to have it launch into the UE4 Editor from VS2022 (again). This time, I left it for 7 minutes and 30.67 seconds. Coming back to it at that time, it had still not resolved from the (then) system wide lock-up.

I think I will have to move over to using Rider for UE4 work. I will be sure to take a look at that at the next available opportunity. Thanks again for the recommendation Packetdancer :slight_smile:.

I will note that, unlike VS Community Edition, Rider is a product that requires a paid license. However, they did have a free trial last I checked, so you can at least give it a shot and see if it works for you.

I will note that you want the EAP (Early Access Program) edition. E.g., the preview edition of the about-to-be-released next version. The expanded Unreal Engine integration in the new version is really nice, and this version supports UE5 as well. (And honestly, the EAP is release-level stable; I’ve swapped to the EAP as my only installed Rider version.)

You could inspect the RAM and processor usage on the Task Manager (windows). VS eats RAM and having a 100% full ram or processor usage will also lock the PC.

1 Like

If the machine is truly locked up, I suspect it’s difficult to get Task Manager or Process Explorer functioning well enough to collect that data.

1 Like

As noted, I cannot check the RAM and processor usage via the Windows Task Manager, as the whole of the computer gets locked up.

I have still yet to try out Rider, as I have had a few tests/video calls to attend, but I will get on it as soon as possible.

Windows has multiple performance tools built-in which let you record those statistics up to the actual lock up. You can get started with Perfmon (performance monitor).

I have found Perfmon… quirky, at times. Or inconsistent. Specifically, depending on when a hard system lock happens (and if it’s causing IO bottlenecks), I’ve had Perfmon completely fail to save out a log… thus providing no useful data.

That said, you’re right to bring it up; it is worth trying that, because while Perfmon doesn’t have a perfect batting average in my experience, I’ve also had situations where Perfmon does successfully tell me what the heck is going on. And I genuinely did forget to even mention it to Fio.

On that note… I might also go check the Windows event logs (Event Viewer) to see if there’s anything interesting in there.

1 Like

Thanks for your suggestion.Seda145 and thanks again for your insight PacketDancer (on your use of Perfmon, this time)*. I might try that out, but for now, I think I will try out Rider, a bit later (I intend to complete another test for a job quite soon).

I’m interested to see if switching IDEs again will help. As.Seda145 may have been suggesting, it sounds like a memory leak, or it may be GPU related. You should be able to monitor the RAM usage within VS during your debug session… just watch and see if it climbs to max. If so you might have created a loop just adding a bunch of items or something like that.

This was pretty common back in the day when we didn’t have all this newfangled smart-pointer stuff… actually had to pay attention and fixing memory leaks was a pain at times.

Also, it may be video driver related. I did have similar issues on a small older all-in-one box a year ago with intel graphics on board… UE4 would run and just lock up or bluescreen on me after some time. I chased it to the video driver hanging but was unable to fix it… hopefully you have better luck.

1 Like

Thanks for your insight too , I will take this into consideration. For now though, I will be trying out Rider, to see how that handles my project’s solution.

Okay then, I have had the correct plugins installed, Rider has built the project successfully and now…has ran the project successfully as well (loading into the editor).

I will try out a bit of development (there is a bug I should be able to resolve, using a debugger). For now though, I think that using Rider instead of Visual Studio, is the solution I was hoping for :slight_smile:.*

The most common memory leak with UE is a problem currently present in the engine. When you halt at a breakpoint in Visual Studio while the blueprint editor / game is running. Apparently waiting for too long in that situation causes memory to climb up to a system lock up.

@FloKron Let us know if Rider is a solution. I’d rather solve the problem at its roots instead of adding another layer of complexity, but who knows.

1 Like

Ah, that is a shame and yes, it would make sense to solve the problem at its root*…but for now, using Rider seems to work just fine.

1 Like