UE5 Preview breakpoints not working when using run modes other than New Editor Window (PIE)

I have all C++, Common Language Runtime and Win32 Exceptions enabled in VS2019, I have downloaded the symbols for UE5 Preview from Launcher and updated my Debug | Symbols path.

If I run my project using VS2019 to launch the editor, then choosing “Standalone Game” with Net Mode “Play As Standalone” in the Editor, even after I attach Visual Studio to the newly running client process after it starts I cannot get break points to hit. Also client crashes are not being caught by the attached debugger. Not sure if this is something others have seen. This work flow definitely worked in UE4 and UE5 Early Access. It’s as if something isn’t mapping properly when I attach to process and VS thinks my code doesn’t match what is running.

It works as expected if I instead change to run New Editor Window (PIE) which makes sense because it’s running in the same exe that I started when I hit F5 in VS.2019.

If I deattach from the editor after I’ve launched the standalone client process and attach ONLY to the client process I see this in my VS debug window (and break points still don’t work)

“This debug engine does not support exception conditions. The condition(s) will be ignored.”

^ this SHOULD be showing me a list of the various symbols being loaded.

Starting to think the UE5 Preview symbols don’t match. I went back to UE5EA editor / project, changed my symbols back to the UE5EA symbols and boom it works, so it’s definitely something with UE5 Preview.

I deleted all of the intermediate folders and still get the same issue. Very hard to work if you can’t debug :frowning: any help is appreciated :slight_smile: going back to EA for now!

I ran into this recently as well. It has to do with the number of DLLs allowed by windows when attaching a debugger to a process, which is capped at 500. It seems that UE5 has many more DLLs than previous versions so it’s hitting that cap, and depending on the order in which the DLLs are loaded, it will cause some to not show up in the list (you can view the loaded modules when attaching a debugger by going to Debug->Windows->Modules in Visual Studio). The solution to this issue is actually in this other thread, but it involves changing a registry key to increase the max number of DLLs. Hopefully this solves the issue for you as well.

2 Likes