So I am asking, why are official microsoft windows tools reporting the generated .exe of a packaged build as invalid?
Hi ,
Outright, I cannot say why you are getting this error, but here are a couple of links that discuss why this happens in general:
Why Sign Tool returns error: 0x800700C1
Error 0x800700c1 when I resign setup.exe with signtool
To narrow down how this is applicable to your project, you’ll need to provide the following:
Thanks,
Going by the first answer in the first link above, it looks like it’s not a matter of a bad .exe, but rather it is reported as invalid as it is already signed by UE4.
Also in that first link is another link on how to remove the original signature, which may resolve this issue. However, as was discussed in your related AnswerHub post here: SignTool Error: SignedCode::Sign returned error: 0x800700C1 , we do not support signing your own Windows build.
We will leave this post open in the event a community member might have information that will help you accomplish this.
1: The build as originally tested was built in vs 2015 from source as included from launcher. It was not a pure launcher build. It was not built using git sources.
2: Config: shipping
full rebuild: yes
for distribution: yes
include debug: no
nativise blueprints: no
use pak: yes
generate chunks: no
chunk hard ref: no
Build http chunk: no
include prereq: yes
3: yes
Creating a new project using the 3rd person template and doing nothing except from changing the project-packing as shown above will reproduce this issue.
It will reproduce for 32 or 64 bit builds
For this test I built entirely in UE4 and never launched VS 2015
This was tested with 4.12.5 as installed by the UE launcher.
The generated, packaged, .exe runs normally
To restate to make sure I understand correctly
I was really hoping someone at Epic knew what their build system is actually building. As someone that needs to sign and ship to customers, I’m getting really nervous when the tool developers cannot tell me what the tools are doing.
The primary reason we don’t support this is because there’s a myriad of factors beyond the engine itself that might cause signing to fail…
Looking up the primary reason Windows Signtool reports a packaged .exe as invalid, in the link above it states that “the same error code might be reported when you are trying to re-sign an already signed binary file,” I mistakenly assumed that if the end user is not readily able to sign it themselves, that there must be a generic Epic signature assigned. While this is the case for Blueprint Only projects, it is not the case for C++ projects.
According to the build team, everything is unsigned unless someone chooses to sign it. Again we do not support this, so if you choose to sign your executable, it is up to you to determine why the Windows Signtool is reporting the packaged .exe as invalid. (Of course, another community member may be able to help you resolve this so you are welcome to post your question here.)
The only exception being, as I mentioned above, Content-Only (or Blueprints Only) projects - since they use executables built by us, they are signed with Epic’s certificate. If this is the case with your project, that would explain the error.
I realize a many factors could cause it to fail beyond the engine, however, it is failing building the ue4 example, unmodified. That pretty much makes it an engine issue.
I just re-tried with a c++ 3rd person example as you stated that this might make a difference. This also fails.
Now having said that I did partially solve the problem. After looking though the build system I tried signing the intermediate outputs from the compile. This works.
Lets say the project name is MyProject
then in:
packaged_dir/WindowsNoEditor/MyProject.exe <<< cannot sign this
packaged_dir/WindowsNoEditor/Arps/Binaries/Win32/MyProject.exe << works!
The first exe is shown as unsigned by
.\signtool verify /pa MyProject.exe
So it doesn’t appear to be conflicting signature.
However, I can delete it and run the other, larger, .exe fine. So that may be a work around
However: Packaging Projects | Unreal Engine Documentation
Indicates I’m supposed to run the first .exe which I am guessing has something to do with the pre-reqs check. What is the purpose of this smaller .exe?
I’m also having signing issues. The bizarre thing is I have two development systems (both using identical projects and 4.16.2) and ONE creates a signable .exe and the other doesn’t. (error 0x800700C1)
They are identical .exe sizes, but have around 20 bytes difference if I compare the .exe files using fc from DOS. Why does only one system make signable .exe files?! I assume an Unreal utility is doing something with the header and breaking the file just enough that signtool.exe can get confused.
These suddenly started cropping up for us in one of our projects. We haven’t done anything strange (as far as we know) to suddenly make them occur. And it’s not all projects.
This is a bug in Unreal Engine due to Epic’s internal deployment process for pre-build UE versions.
Epic signs the Engine\Binaries\Win64\BootstrapPackagedGame-Win64-Shipping.exe
And when you download the pre-build Engine from the launcher this executable comes with Epic’s signature.
However, .rc file of this executable gets altered via “StageBootstrapExecutable” method of “Engine/Source/Programs/AutomationTool/Win/WinPlatform.Automation.cs”
Thus, signtool rightfully complains that signature of the executable is invalid.
Here is the potential solutions:
a. Remove the Epic’s signature via signtool:
b. Build the engine from source:
c. Fix from Epic: