Installer fails with 'Are you sure you want to cancel the installation?'

[gcb_toronto]

This installer is build using Advanced Installer 16.3 under Windows 10.

When I run the installer, instead of completing the installation, it fails by asking 'Are you sure you want to cancel the installation ?'

The installer was working correctly about a week ago. Maybe I am making some simple mistake.

The installer is a "single EXE setup (resources inside)".

Before building the installer I increment The Product Detail "version" to regenerate the Product Code.

Before running the installer I uninstall the program from the PC.

I then run the resultant installer executable.

The installer passes "Collecting Information", "Preparing Installation" and goes into the "Installing" step before prompting 'Are you sure you want to cancel the installation'.

Answering either yes or no stops the installation process.

Answering "No" causes it to exit the prompt and go back to the initial "Welcome" step.

Answering "Yes" causes the installer to announce "The program setup was interrupted. Your system has not been modified. etc. Click the Finish button to exit the wizard".

Question 1: Any ideas what is going on ?

Question 2: Is there a log somewhere I can look at ?

I have already tried msiexec as per the following but it fails to run altogether (cannot open the installation package, maybe expecting a .msi file not a .exe).

msiexec /i ".\My Installer.exe" /L*V .\log.txt

Any help is appreciated.
Gerry

[Catalin]

Hello Gerry and welcome to Advanced Installer forums,

In what regards the log file, indeed, the "msiexec.exe" is expecting an MSI file as input. In order to generate a log file for your .EXE, you can proceed as it follows:

Code: Select all

setup.exe /L*V log.txt

In what regards your issue, please have a look on our "Why the "Are you sure you want to cancel installation" message is thrown after clicking the [ Install ] button?" article which I think you may find useful.

Hope this helps.

Best regards,
Catalin

[gcb_toronto]

Hi Catalin, thanks for the super quick followup.

Actually I just noticed that article now. Based on the article I have further questions. I am quoting the article to hopefully make my questions clear. Sorry if I am being a bit of a newby.

One update: on Digital Signature page Enable Signing is NOT checked.

Article says: The signature mismatch may appear when the EXE setup package is signed outside of Advanced Installer.

Q: Do you know what other process outside of Advanced Installer could sign the EXE setup package ? Advanced Installer is the only application used to generate and run the package.

Article says: Since the MSI is embedded in the EXE, only the EXE will be signed and, therefore the MSI will remain unsigned. This will generate the conflict at install time.

Q: How can I ensure that the MSI is getting signed before it is embedded in the EXE?

Article: Setup packages signed with a SHA256 certificate or digest algorithm will not have their digital signature recognized on XP and Vista operating systems and, thus the installation will fail.

Q: Does the above information apply to a Windows 10 system? For now, I am building and running the installer under Windows 10.

Followup question: Can there be any issues if the installer project was originally created under Windows 7 then copied over to Windows 10?

2nd Followup question: is there a way to disable the package signature? Or is it recommended not to use the .EXE?

Thanks and regards,
Be Safe,
Gerry

[gcb_toronto]

I was able to work around this for now by building a .msi instead of .exe.

[Catalin]

Hello Gerry,

First of all, I am glad you have found a workaround for this.

Please allow me to elaborate on your questions:

One update: on Digital Signature page Enable Signing is NOT checked.

Indeed, this is most of the times the reason why this happens (the .EXE is not signed with Advanced Installer, but outside of it).

Q: Do you know what other process outside of Advanced Installer could sign the EXE setup package ? Advanced Installer is the only application used to generate and run the package.

Normally, in order to sign a file, signing tools are used, such as SignTool.exe. There is a probability that someone else has signed the .EXE (if you are not the only developer working with Advanced Installer). You can check this by going to the location of your setup file --> right click on it --> "Properties" --> "Digital Signatures" page.

digsign.png (21.52 KiB) Viewed 10851 times

By default, Advanced Installer also uses the same tool mentioned above (SignTool.exe) in order to sign the package. However, the difference here relies in the fact that Advanced Installer will automatically detect and sign the MSI file, so no mismatch error will be displayed at install time.

Q: How can I ensure that the MSI is getting signed before it is embedded in the EXE?

Please see the explanation above to this. Basically, to sign both the MSI and the EXE, you should use our predefined support ("Digital Signature" page).

Q: Does the above information apply to a Windows 10 system? For now, I am building and running the installer under Windows 10.

No, it should not affect Windows 10 systems.

Followup question: Can there be any issues if the installer project was originally created under Windows 7 then copied over to Windows 10?

No, I do not believe this should matter.

2nd Followup question: is there a way to disable the package signature? Or is it recommended not to use the .EXE?

In order to disable the package signature, simply do not sign the package (do not use the option from "Digital Signature" page and do not sign the executable outside of Advanced Installer - i.e. with a tool such SignTool.exe)

Hope this helps.

Best regards,
Catalin

[gcb_toronto]

Hi Caitln,

When I right-click my executable installer file I do not see a Digital Signatures tab. This leads me to think that the .exe file is not signed. Below is screenshot link.

https://www.dropbox.com/s/mmxjx57pqgcet ... t.png?dl=0

I have placed a log of the install attempt here:

https://www.dropbox.com/s/ep9utnse3l0pytz/log2.txt?dl=0

I hope you can have a quick look for any obvious problems. I don't see any obvious error messages in the log.

I do notice in the log that TARGETDIR and ROOTDRIVE are set to drive G:, which is unexpected but I don't think it's an issue.

Thanks again.
Gerry

[Catalin]

Hello Gerry,

I have had a look over the sent log file and everything seemed just fine.

From what I can see, there isn't indeed a "Digital Signatures" tab for your executable file.

However, could you please repeat this scenario with your MSI and let me know if the result is the same?

In addition to that, could you please try to verify the signature using the signcheck.exe tool? You can do so with a command line as it follows:

Code: Select all

signcheck.exe -i <path_to_your_executable>

Looking forward to hearing from you.

Best regards,
Catalin

[gcb_toronto]

Hi Catalin,

Thanks for looking over my log.

I did a sigcheck on one of my existing .msi files, then I built the installer to instead generate the executable.

The outputs from sigcheck are show below.

Then when I tried the install with the .EXE I got the same failure mode again - ' Are you sure you want to cancel the installation?'.

The MSI file installs correctly.

One thing I find odd is that the executable "Link Date" is completely wrong, even though the date of the executable itself is "4/1/2020 3:54 PM", as listed in File Explorer.

Question: Is there a way extract the .MSI file from the executable itself, to run sigcheck on it?

Gerry

Error message (program name blanked)

https://www.dropbox.com/s/tf14vm1kexeb8 ... t.png?dl=0

.MSI file:
Verified: Unsigned
File date: 9:05 PM 3/30/2020
Publisher: n/a
Company: n/a
Description: n/a
Product: n/a
Prod version: n/a
File version: n/a
MachineType: n/a

.EXE FILE
Verified: Unsigned
Link date: 10:52 AM 9/4/2019
Publisher: n/a
Company: My Company
Description: My Application Installer
Product: My Application
Prod version: 3.4.146
File version: 3.4.146
MachineType: 32-bit

[gcb_toronto]

I tried to open the executable using 7zip but it says 'can not open file as archive.'

But the file does start working as an installer until it fails as noted above.

Gerry

[Catalin]

Hello Gerry,

From what I see in the sigcheck.exe results, none of your .EXE or .MSI files are signed.

Question: Is there a way extract the .MSI file from the executable itself, to run sigcheck on it?

Yes. You can extract the MSI file out of your EXE file by running the following command line:

Code: Select all

setup.exe /extract

where "setup.exe" is your executable.

To be honest with you, I would like to further investigate this issue. If possible, could you please forward me the following resources:

- a copy of your .AIP file

- a download link for the MSI file (where the problem does not reproduce)

- a download link for the EXE file (where the problem does reproduce)

by e-mail at support at advancedinstaller dot com?

Looking forward to hearing from you.

Best regards,
Catalin

[gcb_toronto]

Hi Catalin,

I have emailed you with a link the the .aip and installers.

Note that the .exe installer will ask whether to install .net 4.8.

The fail happens after and regardless of either allowing or declining the .net 4.8 install.

Thanks,
Gerry

[Catalin]

Hello Gerry,

Thank you for the provided files.

I have had a look over the sent .EXE file and indeed it seems that it is not signed.

I have also run the setup (.EXE) and, to my surprise, everything worked as expected.

This makes me think that there might be something related to your development machine. Could you please try running the setup on a clean machine (i.e. a Virtual Machine with a clean snapshot) and let me know if the behavior reproduces there?

Best regards,
Catalin

[gcb_toronto]

Hi Catalin,

I have finally gotten to this test and was able to use the .exe-based installer to successfully install my program on a brand new Windows 10 install.

I then tried this again on my development Windows 10 machine, and got the same failure as before.

As before, the .msi-based installer works OK on my development PC and the Windows 10 PC.

So obviously you are correct in there being something different on my development PC with regards to the .EXE installer.

One difference in the install procedure was whether I allowed the installer to install a required version of .Net which is already on my development PC. But past tests indicates that this makes no difference in this failure occurring.

My development PC is a very new install, not more than 3 months old. The difference is the installation of various development tools and the usual applications found on a working PC. All installs were first checked through VirusTotal.com and virus scans indicate no problems.

Do you have any further suggestions as to how I can pursue this to find out why this is happening? I will keep you posted if I otherwise find a solution.

Thanks again for the help you have provided.
Gerry

[Catalin]

Hello Gerry,

I've done some further investigations in this matter and I may have found something interesting.

However, I would like to be sure you are in the same case as well. To do so, could you please send me a screenshot of your "User Account Control" settings? Simply type "user account control" in the Windows search bar and please forward me the screenshot for that (if possible, on both your developer machine and on the clean machine).

Looking forward to hearing from you.

Best regards,
Catalin

[gcb_toronto]

Hi Catalin,

Thanks for checking into this. I have placed screenshots here:

https://www.dropbox.com/sh/64w6kc25f8zi ... Y0exa?dl=0

I seems the setting are the same on each PC (both 'Never notify me').

Please let me know whether there are any other differences worth checking.

Regards,
Gerry