Hi, recently upgraded our project from UE 5.0.3 to UE 5.4.4 and we were able to create an initial build of the project in UE 5.4 no problem but all recent packaged builds (in development binary configuration) return the “CreateProcess() returned 5” error.
Upon initial search I saw that this was a permissions issue and attempted to run with admin privileges to no success. I’ve also tried the solution recommended in the post below however that refers to someone unzipping the project in a different computer. I am receiving the error immediately after packaging a build. [Content removed]
This issue began when we started doing Pixel Streaming docker image tests based on the UnrealContainers documentation: https://unrealcontainers.com/blog/offscreen\-rendering\-in\-windows\-containers/ which suggested updating our Target.cs to include the following values:
`using UnrealBuildTool;
using System.Collections.Generic;
// Note that this is the standalone target file for the project (e.g. MyProject.Target.cs),
// NOT the Editor target file for the project (e.g. MyProjectEditor.Target.cs)
public class MyProjectTarget : TargetRules
{
public MyProjectTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
DefaultBuildSettings = BuildSettingsVersion.Latest;
ExtraModuleNames.AddRange( new string { “MyProject” } );
// This instructs UBT to build an additional executable with the CONSOLE subsystem
bBuildAdditionalConsoleApp = true;
// This enables log output in builds packaged in the Shipping configuration, which is handy
// if you don’t want to package in the Development configuration just to see log output
bUseLoggingInShipping = true;
}
}`We have since returned our target.cs file to the default but this has not removed that CreateProcess () Error. Excerpt of our target.cs is below.
`using UnrealBuildTool;
using System.Collections.Generic;
public class YourProjectEditorTarget : TargetRules
{
public YourProjectEditorTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
DefaultBuildSettings = BuildSettingsVersion.Latest;
IncludeOrderVersion = EngineIncludeOrderVersion.Latest;
ExtraModuleNames.Add("YourProject");
}
}`Tests we have attempted to try fixing this issue but did not work:
- Upgrading from VS 2022 17.4 - 17.8
- Ensuring that we are using the correct Windows 10 SDK
- Removing the pixel streaming plugin
- In the Epic Games launcher we hit “Verify” over UE 5.4
- Tested on multiple machines and received the same error
- Deleted “Binaries, DerivedDataCache, Intermediate, Saved and the VS SLN” folders, regenerated Visual Studio Project Files tried packaging a build from there.
- Launching through the Command Prompt - received an “Access is Denied” response
Steps to Reproduce
- Create a new third person template project C++
- Using VS Code 2022 LTSC 17.8
- Tested packaged build and was able to open successfully from template
- Added the plugins: Datasmith Content, Datasmith Importer, Datasmith Runtime, pixel streaming
- Try creating a packaged build
Actually received a different error when opening this build “Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item” (attached as screenshot 2)
Hi there!
Thank you for providing so many details regarding your setup, repro steps and use case. This helps a ton!
In order to better determine the issue, could you send the full log of the run attempt as well as any callstacks/minidumps you can provide? As you’re running in a Development build, there may be more information there.
A few ideas do come to mind however:
- It’s possible your anti-virus/firewall is quarantining some files. Try a re-package and running with it disabled.
- If this is a launcher build of Unreal Engine, try adding bOverrideBuildEnvironment = true; to the target.cs file
- Ensure the “Windows Movie Player” plugin is disabled. This shouldn’t be the cause of the run error, but it can stop a container image from running.
- Try running the -Cmd.exe in the \Binaries\Win64 directory of the packaged project. This will be the one you need to run in the container.
If you try the 4 things above, make sure to re-package!
Let me know how it goes,
Kind regards,
Michael
HI Michael, thank you for your response!
I gave your suggestions a try and unfortunately was still getting the same error. It seems that it was indeed the Windows Security firewall that is blocking the .exe from running. I was able to trace back the first time that the “block” occurred and it was when we were doing our Docker testing with a windows build back in March. I imagine that the firewall has continued to raise a redflag since then as we’ve had this issue for majority of our packaged build tests since then - even ones that are meant for testing locally without docker. Curiously, some builds do succeed and I am unsure why that is.
We are testing whitelisting the SHA256 hash with the network security admin at our organization for the .exe of our build to see if that does the trick. I will update this forum if it does work.
One question - with my repro steps provided, would you happen to know if I can change anything on the UE side to avoid raising this firewall issue in the future?
You’re very welcome! It’s a bit of a tricky issue so I’d like to get to the bottom of it.
The only variance I can think of that may result in some packages being caught by the firewall and others not are plugin changes. Any plugins that start an active network connection could feasibly be triggering the firewall. I’m not currently aware of any UE trickery that can avoid this, as the issue lies in Windows being sensitive.
As the firewall was triggered once back in March, it’s very likely that it’s cached that trigger and is automatically untrusting of the packaged project, even with re-packages. I recommend clearing your Firewall cache and seeing if it will prevent the trigger from happening again.
I’ve been unable to reproduce the issue on my end with your repro steps, but as I’m using basic template projects it may not be a perfect 1-to-1 replica of the results. I will try a few more times to get it to trigger however.
Please let me know if the SHA256 hash whitelist works, as this will be excellent information!
Hi Michael, the SHA256 hash whitelist does indeed work provided that you apply it to the -Cmd.exe in the \Binaries\Win64 directory. In our case, we were able to get an entire drive whitelisted and now are able to run the packaged build without issue!
If you would still like to reproduce it, the only other piece of info that I can provide is to change the target.cs file if you have not already done so to include the info from Unreal Containers. After our conversation + further testing, we believe this change alongside a full rebuild triggered the firewall. I’ve pasted it below for your convenience.
`using UnrealBuildTool;
using System.Collections.Generic;
// Note that this is the standalone target file for the project (e.g. MyProject.Target.cs),
// NOT the Editor target file for the project (e.g. MyProjectEditor.Target.cs)
public class MyProjectTarget : TargetRules
{
public MyProjectTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
DefaultBuildSettings = BuildSettingsVersion.Latest;
ExtraModuleNames.AddRange( new string { “MyProject” } );
// This instructs UBT to build an additional executable with the CONSOLE subsystem
bBuildAdditionalConsoleApp = true;
// This enables log output in builds packaged in the Shipping configuration, which is handy
// if you don’t want to package in the Development configuration just to see log output
bUseLoggingInShipping = true;
}
}`
Great news! I’m glad you’ve managed to get around the issue.
We’ve done quite a lot of container testing using the Unreal Containers, so it was a bit surprising to see your project trigger the firewall like this.
However having the SHA256 whitelist applied should prevent this from occurring again with this project, so I believe it’s safe to call this solved.
Thank you for sharing your solution! I’ll close the ticket here, but if you have any more questions, please feel free to re-open the ticket or create a new one.
Kind Regards
Michael