This question already has answers here:
Inno Setup - Signing fails with "Sign Tool failed with exit code 0x1"
(2 answers)
Closed 4 years ago.
I have Inno Setup with Inno Script Studio installed, along with Visual Studio 2013. I have a digital certificate, protected with a password, named certificate.p12. I also have the Windows 8.1 driver SDK installed (although I'm running Windows 7 Professional x64). The compiled output I'm including in my installer is already signed.
I configured Inno Script Studio with a sign tool named my_signtool and with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /f "z:\full\path\to\certificate.p12" /p "password" $f
...and in my .iss file, I have:
SignTool=my_signtool
With this setup on my computer, it works perfectly. I compile the project and Inno Setup automatically signs the installer and its uninstaller.
But, I have a colleague with what should be the exact same setup. He has Visual Studio 2013, Inno Setup and Inno Script Studio, a copy of the certificate, and its password. When he tries to compile it, Inno Setup fails by saying attempting to run the signtool against uninst.e32.tmp returns 0x1. When he runs the exact command it tries to run manually in the command prompt, it fails by stating uninst.e32.tmp isn't available, but that seems normal because I suspect Inno Setup is just cleaning up after itself after the error (or is it?).
I've tried replacing the quotes with $q in the definition of the sign tool to no avail. In fact, aside from the path to signtool.exe itself, none of the paths involved have spaces in them anyway.
Both our outputs look like this initially. Immediately after this is where they diverge: mine continues to run, and his complains that the sign tool failed with 0x1.
Starting compile. [Monday, January 12 2015 at 10:11:03 AM]
Compiling script with Inno Setup 5.5.5 (a) [ISDLLCompileScriptA]
[PreCompile] Processing.
[PreCompile] Processing is still being tested.
[PreCompile] Processing finished.
[ISPP] Preprocessing.
[ISPP] Preprocessed.
Parsing [Setup] section, line 14
...
Parsing [Setup] section, line 41
Reading file (WizardImageFile)
File: C:\Program Files (x86)\Inno Setup 5\WIZMODERNIMAGE.BMP
Reading file (WizardSmallImageFile)
File: C:\Program Files (x86)\Inno Setup 5\WIZMODERNSMALLIMAGE.BMP
Preparing Setup program executable
Updating icons (SETUP.E32)
Running Sign Tool command: "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /f "z:\full\path\to\certificate.p12" /p "password" "Z:\full\path\to\uninst.e32.tmp"
Any guess what simple detail I'm overlooking where my environment works fine every time, but his fails even though it's configured the same way?
I had this same issue and just needed to run Inno Script Studio as Administrator and then I had no problem.
I also had this problem, but running as Admin did not solve the issue. In the end, I can't explain it, but I changed where I got my timestamp and then it all worked fine -- though there was something else that was throwing me off.
I am using InnoSetup 5.5.9 with signtool. I added a SignTool which I defined as:
"C:\PATH_TO_KSIGN\kSign\signtool.exe" sign /f "MYCERT.pfx" /t "http://tsa.starfieldtech.com" /p "MYPASSWORD" $f
The standard timestamp field from the example pages is "http://timestamp.comodoca.com/authenticode". If I use that, the process fails with the errors from the original question.
The other thing that threw me was that if I run the resulting setup build through InnoSetup, it tells me "Publisher: unknown". However, if I take the same installer and run it on a different machine, then it gets the Publisher correct.
I hope this can help someone!
-jonathan
Related
I defined a post-build-event in Visual Studio 2008:
%ProgramFiles%\TortoiseHG\xy.exe
When compiling under Windows 7 or Windows 8.1 (x64) I got the following error-message:
Error 1 The command "%ProgramFiles%\TortoiseHG\xy.exe" exited with code 9009. MyProjektName
The program is here:
C:\Program Files\TortoiseHg
In Windows XP (x86) it is working perfectly - also did I try to set quotation marks but it didn't help. Any ideas what could be wrong? Is it a problem due to the fact that there are two program-paths (one for x86 and one for x64)? But even when I copy the xy.exe to C:\Program Files (x86)\TortoiseHg\, I do get the same error.
Help is appreciated! Thank you.
under Windows 7 or Windows 8.1 (x64)
That's certainly one of the basic problems, Visual Studio is a 32-bit process. The file redirector will act up and redirect any access from c:\program files to c:\program files (x86). To die there, you don't have TortoiseHG installed there.
But not your only problem, the redirection will produce error code 3, not 9009. So you did not get this far yet, 9009 is a general failure code produced when the program you start exits with an error code. Missing double quotes is enough to trigger it, also the program itself failing for whatever reason. Pretty important to look in the Output window for any error message.
Short from an error message we don't know about, you'd get closer with:
%windir%\sysnative\cmd.exe /c "%programw6432%\TortoiseHG\xy.exe"
Which starts the 64-bit command processor, thus ensuring that the file system redirector stays out of the way. The /c option asks it to execute the command that follows and then exit. The %programw6432% environment variable ensures you'll pass c:\program files and not the 32-bit path. Double-quotes around it to ensure that the spaces in the path don't cause misery.
Try $(ProgramFiles) instead %ProgramFiles%. I tried in VS2010 and it works. I suppose in VS2008 too. I normally use quotation, but I don't know if it is necessary.
After leaving my machine alone for a couple weeks, I returned to do some Qt-using-VC10 work. The first sign of trouble was a QtCreator error about "cl" not being recognized, which led me to discover that C:\Windows\System32 had somehow been removed from PATH. The inability to identify the "reg" command was making vcvarsall.bat fail to set VS100COMNTOOLS, as described here.
The aforementioned thread directed me to this, which suggested simply adding C:\Windows\System32 back to PATH.
However, my troubles were not over. Once C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvars32.bat (a script invoked by vcvarsall.bat) was able to invoke "reg", it failed to find the key necessary for setting VS100COMNTOOLS. The failure occured at the following line:
for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v "10.0"') DO (
#if "%%i"=="10.0" (
#SET "VS100COMNTOOLS=%%k"
)
)
The output I got from vcvars32.bat (with unsuppressed output) was:
C:\Users\Bob\Desktop>for /F "tokens=1,2*" %i in ('reg query "HKLM\SOFTWARE\Micro
soft\VisualStudio\SxS\VS7" /v "10.0"') DO ()
ERROR: The system was unable to find the specified registry key or value.
Sure enough, the indicated location in my branch does not exist. The relevant subset of my registry tree looks like this:
HKEY_LOCAL_MACHINE\
SOFTWARE\
Microsoft\
VisualStudio\
10.0\
Debugger\
11.0\
...
9.0\
...
Debugger\
...
Does anyone know what is going on here? Could the automatic windows updates after my two weeks of absence be responsible? How do I fix my system so vcvarsall.bat can manage to set VS100COMNTOOLS?
I had essentially the same problem. In my case I was trying to install only the Visual Studio compilers and redistributables without any instances of the Visual Studio IDE. I took a long time looking into it, trying to resolve it 'correctly' without unnecessarily forcing environment variables or modifying or adding registry values.
Most advice starts with uninstalling any Visual Studio 2010 redistributes and/or compilers and then re-installing them in a particular order, usually after having installed the Windows SDK.
In my case this seemed to help but not completely resolve problems. I ended up doing the following. First in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat
I commented out line 10 because if goto setup_buildsku is taken, the %VisualStudioVersion% variable never ends up getting set as it normally would later down in the file. (It doesn't matter that vcbuildtools.bat won't be called again, because I have that called first when I start my command prompt.)
Then, in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
in the labeled section GetVSCommonToolsDir, it goes looking in the registry at both HKLM and HKCU for
SOFTWARE\Microsoft\VisualStudio\SxS\VS7
and
SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7
The problem I had was (that because only the Build Tools are installed ?) there are no VS7 keys, only VC7 keys so the lookup fails.
Consequently I commented out lines 99-103 in vcvarsall.bat and my %VS140COMNTOOLSDIR% and %VS100COMNTOOLSDIR% variables are untouched. (They are already set in my environment before calling vcvarsall.bat).
Later, I see many "ERROR: Cannot determine the location of the VS installation." But my builds and compiles still proceed OK!
Yes, that's right. I had the same problem with the missing regKey SxS.
After re-installing my Visual Studio 10.0 - update SP1 - the SxS HKM-RegKey was re-defined in the HKM.
Recently I installed Build Tools for Visual Studio 2019 on Wine and found that vcvars64.bat doesn't work.
It is mainly due to the difference of cmd between Wine and Windows.
In addition, Wine(Windows) Registry doesn't have .NET Framework setup information.
What I added to Wine Registry is as below:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\SxS\VC7]
"FrameworkDir32"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkDir64"="C:\\WINDOWS\\Microsoft.NET\\Framework64"
"FrameworkVer32"="v4.0.30319"
"FrameworkVer64"="v4.0.30319"
I've built an installer using InstallShield 2011. I need to do a silent install so I ran the setup.exe with the -r flag to record the response file. However, the installer doesn't appear to actually generate a file (I've looked in the windows directory for the .iss file - in fact I've looked over my entire hard disk for .iss files)
I'm installing on Windows 7 64 bit Ultimate Edition and running from an elevated command prompt
Has anyone seen this before or have any ideas why the file isn't getting generated?
I am having an issue generating resources in VS.Net 2010, windows 7 64bit. It am able to compile the solution in Visual studio. But when I try to compile the solution in command prompt using msbuild, it fails generating the resources.
I went through the below link and find a solution to get it compiled in command prompt using msbuild.
http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx
I used option 2 from the above article.
Before compiling in command prompt I have to execute the below two commands.
CorFlags /32BIT+ /Force Resgen.exe
set RESGENTOOLARCHITECTURE=Managed32Bit
And after finishing the compilation I have to execute the below remove 32 bit command. Other wise it fails in visual studio.
CorFlags /32BIT- /Force Resgen.exe
One weird thing is non of my team members are having any issue with this. I only have the problem.
Could you please let me know why it's only me?
Also any other permanent solution if you have, with out running the above commands again and again.
Thanks in Advance
Sometimes it has issues with the privileges.
Just make sure that you have tried running your command prompt with full privileges.
i.e. Run as administrator
I am taking over a bit of a legacy project, and having issues getting it to install in Windows 7.
The project is coded in VB, and our IDE for it is Visual Studio 2005 with VSS (fun I know). It was originally created for XP. The original dev is around to coordinate with, but is off the maintaince team for this project, and admits that the code is quite poorly formatted and commented it was his first large project.
The project runs fine when I generate a debug or release build in Visual Studio 2005, and I can run it on the Windows 7 machine that built it just fine. However, the MSI that I generate to install with fails when run on Windows 7.
It looks to be an issue where the DLLs that are packaged with the project are not correct for Windows 7, but they were generated via an MC file. I have the source MC files, so attempted to use MS's mc.exe tool and its counterparts to create the dll, but am not seeing any output.
The only walkthroughs I have seen on using MC files are not terribly helpful: mc_tutorial
MS mc.exe page
Could someone else walk me through what steps are nessary, or point me toward some more helpful resources?
An actual high quality man page for mc.exe would be quite nice, instead of the rather limited MS documenation, but maybe I am spoiled these days.
look for mc.exe in you machine (mc.exe is part of windows sdk usually located at C:\Program Files (x86)\Windows Kits\10\bin\10.0..\x64\mc.exe).
in windows command prompt run : "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\mc.exe" -U sample.mc
after above command run: "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe" -r sample.rc
above command will generate header in your sample.mc file location.
run this command to generate dlls: link -dll -noentry -out:sample.dll sample.res