I have been building AutoCAD OEM based applications for years now. Just recently, I stumbled upon some freak error I have not been able to resolve.
With the AutoCAD OEM platform, there is an Installer Wizard that creates an installer for the (gargantuan) application. The application installer is started (of course) with calling the setup.exe.
With the last AutoCAD OEM versions up until AutoCAD OEM 2022, the signing of the setup.exe has been no problem at all.
Now, with the current AutoCAD OEM 2023 version, the signing of the setup.exe does not work anymore. When trying to sign the setup.exe, the error 0x800700C1 returns. This is a very generic error message, and googling after this does not bring any helpfull results.
error message of signtool.exe
Before signing the setup.exe, I always use the delcert tool (delcert-sign-strip-tool), which always works as intended.
When using this on the current setup.exe, delcert returns an error message:
error message of delcert tool
It seems that delcert succeeded, but when trying to sign the file again, it fails again with the same error message:
error message of signtool.exe
Looking with dumpbin on the headers, I noticed that the setup.exe for AutoCAD OEM 2023 is a x64 file:
dumpbin for setup.exe of AutoCAD OEM 2023
Whereas the previous versions setup.exe has been an x86 file:
dumpbin for setup.exe of AutoCAD OEM 2022 and lower
This seems to be a random correlation but may be the source of this problem.
Has anybody experienced a similar problem (not neccessarily in the AutoCAD ecosystem)?
Thanks,
Jens
Related
I'm working on a .dll - file that I will use for a program that is supposed to run on Windows XP. I am using VisualStudio 2017 on a Windows 10 machine for this and I want to build the project, consisting of all the necessary code for the .dll - file, thereby targetting Windows XP (64Bit).
Building the project for Windows 10 is no problem, I will show the settings I have selected for that below.
Trying to build with XP(64 Bit) as target, I get the following errors (a picture follows shortly):
Error C1083 Cannot open include file: 'processthreadsapi.h': No such file or directory
Error (active) E1696 cannot open source file "ip2string.h"
Error (active) E1696 cannot open source file "processthreadsapi.h"
Here are the configurations I have altered in both cases:
Windows 10 setup, build works fine
Windows XP setup, producing the error messages
error messages
I've already read
---> https://learn.microsoft.com/en-us/cpp/build/configuring-programs-for-windows-xp?view=vs-2017
and installed the apparently needed c++ runtime support, it still doesn't work. I am aware of choosing the Visual Studio 2015 toolsets.. I read multiple times about lacking support for the 2017 versions and people fixing their errors by choosing the 2015 option (choosing 2017 xp actually results in a few more errors in my case), which why I also tried it that way.
I would appreciate your help very much!
When you choose the XP toolset, Visual Studio uses a different include path with files from a older XP compatible version of the Windows SDK.
If you look at the functions defined in ip2string.h, the minimum version supported is Windows 7. I would imagine processthreadapi.h is an attempt at refactoring Windows.h and therefore isn't available in the XP SDK.
If you look at processthreadapi.h you will notice it is almost al guarded by
#pragma region Application Family or OneCore Family
Without seeing the code I am not sure exactly how to fix your problem, but I would suggest you try and use Windows.h everywhere instead of specific API includes.
My project uses Wix 7.x. We have a custom action DLL (written in C++) which is digitally certified with SHA2. This DLL was previously certified with SHA1.
There are no changes other than the digital certificate changes.
While installing we receive the below error messages.
CustomAction customaction_a returned actual error code 1157 (note this
may not be 100% accurate if translation happened inside sandbox)
Error 1723. There is a problem with this Windows Installer package. A
DLL required for this install to complete could not be run. Contact
your support personnel or package vendor. Action customaction_a ,
entry: FirstCustomAction, library: C:\Windows\Installer\MSICD2E.tmp
When the DLL was certified with SHA1, it installs successfully without any errors in Windows 7, Windows 8 and Windows 8.1.
When the DLL is certified with SHA2, it gives the above error in Windows 7, Windows 8. But installs successfully in Windows 8.1 and Windows 10.
I have searched the internet and tried the options suggested like providing permissions to %temp% folder, wrong path registered for msiexec etc... and nothing helped.
Is this a known issue / bug? Any solution / workaround would be a great help.
From the Windows Installer point of view there's nothing here relating to signing. The 1157 error is "One of the library files needed to run this application cannot be found.". In other words it's a missing dependency. If it has no dependencies on other Dlls of yours then it could be a missing version of a CRT/MFC/ATL etc, or the universal CRT, most of which have various redistributables which may or may not have been installed on some systems as prerequisites of other products.
You may be installing prerequisites, your post doesn't say. You may have included some version of the C++ merge modules in your MSI, but some SxS versions are not committed until after custom actions run and would cause this failure. So there are many reasons why this might fail that are unrelated to signing, given the 1157 error, unless there's an optional Dll related to signing that is not on all versions of Windows, and that seems unlikely. The simplest explanation is the one indicated by the error - a missing dependency.
Dependency Walker on the Dll might tell you what the missing Dll is if you simply copy the Dll to a system where it can't load and run the dependency walker on it there.
EndNote has been playing up for days for me and I've been meaning to upgrade from v6.0 to v7.0/v7.5. I don't know how it is for others but I think we have an institutional copy of EndNote that comes as an .exe. This .exe expands to: Install.cmd, Thomson Reuters Endnote (TRE) X7.5.MSI, TRE X7.5.mst and TRE X7.51.cab.
If you extract the .exe, you can click on the .MSI to try to install EndNote but it apparently does it without a license, so you're given the choice of purchasing a license or trialing the software for 30 days. However, if you click on Install.cmd, which is the script that the .exe runs if you click on the .exe itself, I get an error message: "Error applying transforms. Verify that the specified transform paths are valid." (against the background cmd.exe, with "C:\Documents and Settings[Username]\Desktop>msiexec.exe /i "Thomson Reuters Endnote X7.5.MSI" TRANSFORMS="Thomson Reuters Endnote X7.5.mst" /qb).
For context, I've recently (re)installed Microsoft Windows Installer 4.5 on my Windows XP computer running Service Pack 3 and those issues I've been having with EndNote 6.0 were to do with network issues, namely, Windows errors 12029 ("resolved" by resetting all settings in otherwise unused Internet Explorer 8.0) and 12157. If anyone has any tips on resolving these, mainly the latter now, or the EndNote 7.5 installation issue, that would be appreciated. Thanks.
If I understand correctly 'The Publisher Could not be verified..' alert appears in Windows7 and XP when you're trying to run digitally unsigned .exe or .msi file.
So, I created installer for my project (I use InstallShield 2012 Limited Edition for this purpose), built it and got Setup.exe. I didn't use any certificate to digitally sign my setup.exe.
May be I missed smth, but I cannot understand why I'm not getting Unknown Publisher Security Warning when launching my unsigned setup.exe and trying to install my app on my Win7 box?
The warning is only displayed if the EXE is manifested to request elevation. If you build it with the AsInvoker setting it won't need to therefore no prompt.
However, assuming it's a Per-Machine install, it'll prompt for elevation when you transition from the InstallUISequence to the InstallExecuteSequence.
We have an installer package authored with InstallShield 2009, targeting Windows Installer 3.1.
Recently, we started to notice that sometime, when installing on some Windows 2003 R2 x86 based hosts, the installation fails, and the installer log report a 1603 error code (which by the way, doesn't really help much, as it means ERROR_INSTALL_FAILURE, that is a very generic "A fatal error occurred during installation.").
As the installation is still working on some other hosts on that very same platform, after further investigation we found out it was happening on hosts where Sql Server 2008 R2 was already installed, which leaded us to find out the issue is really with Windows Installer 4.5.
Whenever Windows Installer 4.5 was installed by an installer package, our installer package is failing with 1603. So far, we found as a work around: if we manually uninstall Windows Installer 4.5 (running something like "C:\WINDOWS\$NtUninstallKB942288-v4$\spuninst\spuninst.exe"), we can then run our installer package successfully, but this has various drawbacks:
the user who uninstall Windows Installer 4.5 is prompted with a dialog listing all the various software products installed using that, and effectively the link between those products and Windows Installer 4.5 is lost after uninstalling that, even if we reinstall it after successfully installing our application;
as Microsoft released various version of Windows Installer 4.5, the location of the utility to uninstall that is not strictly the one given above;
It is awkward to ask customers to perform such a work around.
I suppose upgrading the installer package to target Windows Installer 5 may solve the issue, but if possibile I would like to avoid it, and continuing to use InstallShield 2009 to author this specific package.
I have scoured the Microsoft and Flexera Knowledge Bases (and I am continuing my investigation), with no avail so far.
Does anyone knows if Microsoft or Flexera, or any other third party, have published an hotfix, or some further info, about this issue?
Some info about the 1603 error code failure
We got verbose logs for this issue, from at least 3 different servers, and we have investigated that in depth, to not avail so far. Most actions return 1, some 0 (specifically IsolateComponents, MigrateFeatureStates, IsolateComponents, SetODBCFolders, MigrateFeatureStates, UnpublishComponents, UnregisterComPlus, UnregisterTypeLibraries, UnregisterMIMEInfo, RemoveShortcuts, RemoveFiles, CreateShortcuts, RegisterMIMEInfo, InstallODBC, RegisterTypeLibraries, RegisterComPlus and PublishComponents, but nothing has yet came out investigating those), the installer package seems actually to be almost able to install (perform all the sequence down to "INSTALL. Return value 1.", it even prints "Product: [Our Product] -- Installation operation completed successfully."), only then it starts to rollback everything, and as there are various errors on the rollback, I think some of those will cause the 1603 (probably some 1607 returned by MsiProvideAssembly on ISChainPackagesCleanup), but the point is that it shouldn't rollback, and with Windows Installer 3.1 (or 5.x for that matter) it doesn't, it does rollback only when there is Windows Installer 4.5 installed on a Windows 2003 x86 environment.
Most likely your package has an action which fails, either custom or standard. Try creating a verbose log of the installation which fails (it's very important to be verbose). After the failure, open the log with a text editor and search for the error code (1603) to see what triggers it.
As a side note, don't try to blame Windows Installer. There's nothing wrong with version 4.5 and there are no hotfixes or something like that. The problem is in your package. It does something which is either incorrect or unsupported.
EDIT:
From your post update it looks like a failed chained installation. No errors are shown in the log because the error occurs in a different installer process.
If you are not using chained packages, try looking for errors in the Event Viewer.
If you are using chained packages, you can try enabling the Windows Installer logging policy and check for logs generated by them. Most likely one of the packages is encountering a problem.