0
votes

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.

1

1 Answers

1
votes

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.