Issues with Dynamic Debugging in MSVC 14.44

Development Pipeline & Plugins
, ,
1

My team has been testing out Dynamic Debugging with MSVC 14.44 in UE 5.6.1, and it is really great for what it’s advertised to do, but it seems to integrate in a broken way with some other UE systems. In both cases, it seems to be because the process of compiling this way generates files like *.alt.exe, *.alt.dll, and so on, and certain systems aren’t handling that.

First, when running the game from UAT (via BuildCookRun, or whatever Quick Launch in the Editor is doing), it attempts to load the wrong exe and fails.

From ushell: .run invokes BuildCookRun -project=P:\P4\MyWorkspace\MyGame\MyGame.uproject, which tries to run P:\P4\MyWorkspace\MyGame\Saved\StagedBuilds\Windows\MyGame\Binaries\MyGame\MyGame.alt.exe and silently fails.

From Quick Launch: Attempts to run the same file, but “Found 0 temp logs to copy” from the temp folder (because it didn’t generate any), and then “Client exited with error code: -1073741819”.

Second, dynamic debugging seems to break Live Coding. After making a change to a .cpp file in a module that should work, it compiles fine, but the output from LC has this at the end:

The module ‘P:\P4\MyWorkspace\Engine\Plugins\MyCompany\MyModule\Binaries\Win64\UnrealEditor-MyModule.alt.dll’ has not been loaded by any process. Changes will be ignored.

On the VS side, a breakpoint I’ve placed in the file now says the breakpoint won’t be hit because the source code is different from the original version. This output and breakpoint issue both happen even if I place the breakpoint in the file before executing the compile, which should theoretically make it so the .alt.dll is in use by something.

The first issue is a blocker for us adopting Dynamic Debugging at all. The second would make it a tough choice between Dynamic Debugging and Live Coding, as both are extremely useful for different situations. Please let me know if there are any fixes for these issues in 5.7, 5.7.1, or any future versions with changes that I can pull early.

[Attachment Removed]

2

The usage we’ve done with it has been on local developer machines only, as in the builds are not generated with BuildCookRun and are instead built from Visual Studio (via UnrealBuildTool) and directly debugged. There was no work done to support BuildCookRun or other UAT scripts. We also have not tested it with Live Coding as far as I am aware. I do not believe there were any major fixes for 5.7.

[Attachment Removed]

3

I figured out that in AutomationUtils, Platform.GetExecutableNames collects the build products that are .exes, and Project.SetupClientParams uses the first one. It just happens to find the .alt.exe first when collecting them, so that’s a simple fix. Though it begs a scary question of anywhere else in UAT or UBT that iterates for .exe, .pdb, or .dll files and assumes it’s going to find a single valid one.

[Attachment Removed]

4

We don’t have any current plans to improve the interaction between dynamic debugging and live coding.

[Attachment Removed]

5

Thanks for the response. In this scenario, the build is likely done via either VS or ushell, which does run UBT with basically the same command line as VS. It’s more that with dynamic debugging enabled at all, the “run” portion of BuildCookRun for Win64 is just inoperable. It’s not like we can selectively enable dynamic debugging only when running from VS, since it generates such different build products. So with the feature enabled, we can build from anywhere that invokes UBT, but we can only run from VS itself.

This workflow is common enough for us that I’ll either have to not enable dynamic debugging, or step through BuildCookRun to find where it’s picking the wrong exe. But as far as Live Coding is concerned, I don’t expect to be able to fix that here. Do you expect any changes for this kind of support in upcoming versions of UE? I’d be happy to cherry-pick some changes if any fixes are implemented.

[Attachment Removed]