This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: InstallShield installation problem
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 14, 2016
05:34 AM
InstallShield installation problem
Hi, we have a problem with installing a new InstallShield version (2016). My associate tried to install new version of InstallShield from package InstallShield2016PremierComp.exe, but it won’t install. When doubleclicking the file it tries to extract it or something, but after couple of seconds it just stops and nothing happens. I installed from same file successfully so it is not corrupted.
What can be done?
Kind regards
Pete
What can be done?
Kind regards
Pete
20 Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 20, 2016
09:59 AM
It sounds like an error may be occurring during initialization of the installer. On the machine that has this issue, can you run the IS 2016 installer with logging enabled?
This should create a log file in the same folder as the EXE when it is run with this command line. Please attach the verbose log to this thread.
InstallShield2016PremierComp.exe /debuglog
This should create a log file in the same folder as the EXE when it is run with this command line. Please attach the verbose log to this thread.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 21, 2016
05:46 PM
The following line indicates an issue:
[code]9-21-2016[09:01:43]: UI resource exception: 80070057[/code]
We have seen this issue a few times recently but unfortunately we have not been able to track down what specifically is causing the issue. We do know that the error is being returned from the Win32 API required to succeed for the setup UI to function, but the error code (invalid parameter) does not make any sense as we have been able to verify in other cases that all the parameters are valid. This issue is also difficult to diagnose due to the machine specific nature that we have not been able to reproduce.
If possible, we have some troubleshooting test utilities we would like to try on the machine encountering this error. I will send you a private message containing further details regarding the tests we would like to try.
[code]9-21-2016[09:01:43]: UI resource exception: 80070057[/code]
We have seen this issue a few times recently but unfortunately we have not been able to track down what specifically is causing the issue. We do know that the error is being returned from the Win32 API required to succeed for the setup UI to function, but the error code (invalid parameter) does not make any sense as we have been able to verify in other cases that all the parameters are valid. This issue is also difficult to diagnose due to the machine specific nature that we have not been able to reproduce.
If possible, we have some troubleshooting test utilities we would like to try on the machine encountering this error. I will send you a private message containing further details regarding the tests we would like to try.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 22, 2016
12:42 AM
Ok. That's fine with me. I'm in the office in the next week.
Regards
Pete
Regards
Pete
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 03, 2016
11:10 AM
Any movement on this issue? I'm having trouble with the same installer running on a Win7 64 bit machine. Installer silently fails and log shows UI resource exception: 80070057...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 04, 2016
04:14 PM
David,
As mentioned before we are seeing multiple reports of this issue but we are unable to reproduce it in house. We have been able to obtain a fair amount of data about this issue from machines that are encountering it. We currently believe that a change we made in IS 2016 and a hotfix for IS 2015 SP1 to provide greater security when loading arbitrary third party DLLs is partly the cause of this behavior. It appears that the SetDefaultDllDirectories API used to accomplish this is causing certain functionality in other Win32 APIs to fail.
At this point we are still trying to track down a specific cause for this marshaling error (which results in the suite error "UI resource exception" in the suite debug log). I've attached a test EXE we have been able to put together that reproduces this behavior outside of an installer process. Can you do the following with the test EXE:
[LIST=1]
Extract the EXE from the zip file.
Open a command prompt window and run the EXE:
After the EXE writes 'Starting CoMarshalInterface test...' to the console, watch for any LoadLibrary errors with the error 0x00000057.
If such an error occurs, the EXE will wait for you to create a process dump in Task Manager. Open Task Manager, find MarshalTest.exe, right-click it and select 'Create Dump File...'.
Press a key to continue the test after creating a dump file.
Attach the dump file (zipped) and any output from the test EXE to this thread. (Note that it may not be possible to attach the dump due to its size; if possible, upload to a file sharing service that we would be able to access.)
As mentioned before we are seeing multiple reports of this issue but we are unable to reproduce it in house. We have been able to obtain a fair amount of data about this issue from machines that are encountering it. We currently believe that a change we made in IS 2016 and a hotfix for IS 2015 SP1 to provide greater security when loading arbitrary third party DLLs is partly the cause of this behavior. It appears that the SetDefaultDllDirectories API used to accomplish this is causing certain functionality in other Win32 APIs to fail.
At this point we are still trying to track down a specific cause for this marshaling error (which results in the suite error "UI resource exception" in the suite debug log). I've attached a test EXE we have been able to put together that reproduces this behavior outside of an installer process. Can you do the following with the test EXE:
[LIST=1]
MarshalTest.exe
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2016
10:43 AM
Pete,
Thanks for getting this information to us. It looks like the machine this test was run on is encountering the same exact behavior as other machines we are seeing. For some reason a call into MSI occurs on the machines with this issue when we make a call into CoMarshalInterface.
Would you be able to run the test posted above with the attached MarshalTest.zip? We believe we know the code change we made that is causing parts of Windows to behave unexpectedly, but we're looking for one last bit of data before making a decision on how to fix the issue. If you are able to run the test, the MarshalTest.exe process dump is likely going to be too large to attach here. If you can, try putting the file on a file sharing service (OneDrive, Drop Box, etc.) that we would be able to access.
Thank you for your patience as we try to get a fix available for this issue.
Thanks for getting this information to us. It looks like the machine this test was run on is encountering the same exact behavior as other machines we are seeing. For some reason a call into MSI occurs on the machines with this issue when we make a call into CoMarshalInterface.
Would you be able to run the test posted above with the attached MarshalTest.zip? We believe we know the code change we made that is causing parts of Windows to behave unexpectedly, but we're looking for one last bit of data before making a decision on how to fix the issue. If you are able to run the test, the MarshalTest.exe process dump is likely going to be too large to attach here. If you can, try putting the file on a file sharing service (OneDrive, Drop Box, etc.) that we would be able to access.
Thank you for your patience as we try to get a fix available for this issue.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 07, 2016
12:00 PM
Pete,
Thanks for trying this test. It looks like the test didn't go as expected due to changes in the underlying implementations of some Win32 functions starting with Windows 7. Microsoft refactored/reorganized a lot of the API surface which made our test not quite functional (the tests in the EXE were originally written to another issue we are seeing on Windows Vista/2008 Server).
I've attached an updated test EXE which should show the errors we are expecting. Please try the exact same steps again but using the test EXE in the zip file attached to this post. We're hoping this is the last test we need to run to capture the failure.
Thanks for trying this test. It looks like the test didn't go as expected due to changes in the underlying implementations of some Win32 functions starting with Windows 7. Microsoft refactored/reorganized a lot of the API surface which made our test not quite functional (the tests in the EXE were originally written to another issue we are seeing on Windows Vista/2008 Server).
I've attached an updated test EXE which should show the errors we are expecting. Please try the exact same steps again but using the test EXE in the zip file attached to this post. We're hoping this is the last test we need to run to capture the failure.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 10, 2016
02:59 AM
Hi Josh,
here is a link to dump file: https://www.dropbox.com/s/t2awq20kqfig0al/MarshalTest.DMP?dl=0
Regards,
Pete
here is a link to dump file: https://www.dropbox.com/s/t2awq20kqfig0al/MarshalTest.DMP?dl=0
Regards,
Pete
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 12, 2016
03:33 PM
Hello Pete, David,
We believe we have tracked down at least one potential cause of this issue to having any MSI package installed that includes the oleaut32.msm merge module. This merge module was originally available to provide OLE support for Windows 95 and NT. However, it is no longer necessary and shouldn't be used. It may be possible for either older MSI packages or more recent MSI packages that still include the merge module to be installed. When these MSI packages are installed per-user, the COM information they contain for PSDispatch (a system implemented proxy/stub class to support marshaling IDispatch interfaces) is registered in HKEY_CURRENT_USER\Software\Classes, overriding what is already on the machine in HKEY_LOCAL_MACHINE\Software\Classes. When we call into COM APIs to marshal interfaces that our setup.exe's use, the overridden PSDispatch is used instead of the system registered object. Along the way, MSI gets involved because it registered this COM class ID. For whatever reason, MSI returns the implementing DLL (oleaut32.dll) back to COM without a path. When COM then loads the DLL, the relative path is combined with specific flags to the LoadLibraryEx API. This call fails with ERROR_INVALID_PARAMETER which then fails the entire call back up to the CoMarshalInterface call.
Long story short:
- We can now reproduce this failure on Windows 7/2008 R2 machines by installing an MSI package in a per-user context that also includes oleaut32.msm (this is one possible cause of the failure, we are unsure if any causes are possible)
- We're attempting to get some guidance on this issue from Microsoft; the original code change we made that triggers this failure is related to attempting to lock down how DLLs can be loaded into an installer process which we don't want to completely remove
- In the meantime, you can see if these machines you can't run the IS 2016 installer on have PSDispatch registered per-user:
1. Open regedit.
2. Go to HKEY_CURRENT_USER\Software\Classes.
3. Look for CLSID\{00020420-0000-0000-C000-000000000046}, or Wow6432Node\CLSID\{00020420-0000-0000-C000-000000000046}
4. If either of these contain the {00020420-0000-0000-C000-000000000046} key, rename this key (export the key first as a backup) by adding underscore characters before or after the GUID. Renaming the GUID back to its original name will cause the failure to occur again.
After following the above steps, running the MarshalTest.exe test should no longer present an error after the output 'Starting CoMarshalInterface test...'. As long as this error doesn't appear with the test EXE, you should be able to launch the IS 2016 installer.
Thank you for your patience and assistance helping to work through this issue.
We believe we have tracked down at least one potential cause of this issue to having any MSI package installed that includes the oleaut32.msm merge module. This merge module was originally available to provide OLE support for Windows 95 and NT. However, it is no longer necessary and shouldn't be used. It may be possible for either older MSI packages or more recent MSI packages that still include the merge module to be installed. When these MSI packages are installed per-user, the COM information they contain for PSDispatch (a system implemented proxy/stub class to support marshaling IDispatch interfaces) is registered in HKEY_CURRENT_USER\Software\Classes, overriding what is already on the machine in HKEY_LOCAL_MACHINE\Software\Classes. When we call into COM APIs to marshal interfaces that our setup.exe's use, the overridden PSDispatch is used instead of the system registered object. Along the way, MSI gets involved because it registered this COM class ID. For whatever reason, MSI returns the implementing DLL (oleaut32.dll) back to COM without a path. When COM then loads the DLL, the relative path is combined with specific flags to the LoadLibraryEx API. This call fails with ERROR_INVALID_PARAMETER which then fails the entire call back up to the CoMarshalInterface call.
Long story short:
- We can now reproduce this failure on Windows 7/2008 R2 machines by installing an MSI package in a per-user context that also includes oleaut32.msm (this is one possible cause of the failure, we are unsure if any causes are possible)
- We're attempting to get some guidance on this issue from Microsoft; the original code change we made that triggers this failure is related to attempting to lock down how DLLs can be loaded into an installer process which we don't want to completely remove
- In the meantime, you can see if these machines you can't run the IS 2016 installer on have PSDispatch registered per-user:
1. Open regedit.
2. Go to HKEY_CURRENT_USER\Software\Classes.
3. Look for CLSID\{00020420-0000-0000-C000-000000000046}, or Wow6432Node\CLSID\{00020420-0000-0000-C000-000000000046}
4. If either of these contain the {00020420-0000-0000-C000-000000000046} key, rename this key (export the key first as a backup) by adding underscore characters before or after the GUID. Renaming the GUID back to its original name will cause the failure to occur again.
After following the above steps, running the MarshalTest.exe test should no longer present an error after the output 'Starting CoMarshalInterface test...'. As long as this error doesn't appear with the test EXE, you should be able to launch the IS 2016 installer.
Thank you for your patience and assistance helping to work through this issue.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 13, 2016
03:00 AM
Hi Josh,
unfortunately we didn't find those registry entries under HKEY_CURRENT_USER\Software\Classes.
Under HKLM were some, but not under HKCU.
Pete
unfortunately we didn't find those registry entries under HKEY_CURRENT_USER\Software\Classes.
Under HKLM were some, but not under HKCU.
Pete
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 14, 2016
05:04 AM
Hi Josh,
just tried at one of my customers. And 1st result was:
SetDefaultDllDirectories present...
SetDefaultDllDirectories result: succeeded (0x00000000)
Retrieving LoadLibrary pointers from kernelbase...
Starting shell link test...
LoadLibraryExW: C:\Windows\SysWOW64\shell32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
LoadLibraryExA: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Successfully created shell link
Shell link test complete
Starting CoMarshalInterface test...
LoadLibraryExW: msiltcfg.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: user32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msiltcfg.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: oleaut32.dll, 0x00000000, 0x00002008
LoadLibraryExW: error 0x00000057 <-- likely cause of failure
Please open Task Manager and create a process dump of MarshalTest.exe (process id 6208)
Press any key to continue with this test...
And yes after looking into registry this pc had the key:
HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{00020420-0000-0000-C000-000000000046}
And as suggested, after rename the key I got the following output from MarshalTest:
SetDefaultDllDirectories present...
SetDefaultDllDirectories result: succeeded (0x00000000)
Retrieving LoadLibrary pointers from kernelbase...
Starting shell link test...
LoadLibraryExW: C:\Windows\SysWOW64\shell32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
LoadLibraryExA: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Successfully created shell link
Shell link test complete
Starting CoMarshalInterface test...
LoadLibraryExW: C:\Windows\SysWOW64\oleaut32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
CoMarshalInterface succeeded
LoadLibraryExW: api-ms-win-appmodel-runtime-l1-1-1, 0x00000000, 0x00000800
LoadLibraryExW: error 0x0000007e
LoadLibraryExW: ext-ms-win-kernel32-package-current-l1-1-0, 0x00000000, 0x00000800
LoadLibraryExW: error 0x0000007e
LoadLibraryExA: ADVAPI32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ADVAPI32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
LoadLibraryExA: OLEAUT32.dll, 0x00000000, 0x00000000
LoadLibraryExW: OLEAUT32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Test thread exit code: 0x00000000
I made a dump file from 1st failure, if needed let me know.
I tried this at several pc from the customer and got on every pc the same results. May be a "base package" creates the key. The customer has > 1000 pc's
regards
Markus
just tried at one of my customers. And 1st result was:
SetDefaultDllDirectories present...
SetDefaultDllDirectories result: succeeded (0x00000000)
Retrieving LoadLibrary pointers from kernelbase...
Starting shell link test...
LoadLibraryExW: C:\Windows\SysWOW64\shell32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
LoadLibraryExA: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Successfully created shell link
Shell link test complete
Starting CoMarshalInterface test...
LoadLibraryExW: msiltcfg.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: user32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msiltcfg.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: msi.dll, 0x00000000, 0x00000022
LoadLibraryExW succeeded
LoadLibraryExW: oleaut32.dll, 0x00000000, 0x00002008
LoadLibraryExW: error 0x00000057 <-- likely cause of failure
Please open Task Manager and create a process dump of MarshalTest.exe (process id 6208)
Press any key to continue with this test...
And yes after looking into registry this pc had the key:
HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{00020420-0000-0000-C000-000000000046}
And as suggested, after rename the key I got the following output from MarshalTest:
SetDefaultDllDirectories present...
SetDefaultDllDirectories result: succeeded (0x00000000)
Retrieving LoadLibrary pointers from kernelbase...
Starting shell link test...
LoadLibraryExW: C:\Windows\SysWOW64\shell32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
LoadLibraryExA: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ole32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Successfully created shell link
Shell link test complete
Starting CoMarshalInterface test...
LoadLibraryExW: C:\Windows\SysWOW64\oleaut32.dll, 0x00000000, 0x00002008
LoadLibraryExW succeeded
CoMarshalInterface succeeded
LoadLibraryExW: api-ms-win-appmodel-runtime-l1-1-1, 0x00000000, 0x00000800
LoadLibraryExW: error 0x0000007e
LoadLibraryExW: ext-ms-win-kernel32-package-current-l1-1-0, 0x00000000, 0x00000800
LoadLibraryExW: error 0x0000007e
LoadLibraryExA: ADVAPI32.dll, 0x00000000, 0x00000000
LoadLibraryExW: ADVAPI32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
LoadLibraryExA: OLEAUT32.dll, 0x00000000, 0x00000000
LoadLibraryExW: OLEAUT32.dll, 0x00000000, 0x00000000
LoadLibraryExW succeeded
LoadLibraryExA succeeded
Test thread exit code: 0x00000000
I made a dump file from 1st failure, if needed let me know.
I tried this at several pc from the customer and got on every pc the same results. May be a "base package" creates the key. The customer has > 1000 pc's
regards
Markus
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 17, 2016
02:01 PM
Hello Pete, David,
We believe we have a fix for this issue. Please let me know what edition of IS 2016 you are attempting to install (Express, Professional, Premier) so that I can provide a link to download an installer that you can try on Windows 7 machines that exhibit this problem.
Markus,
Is this an issue with the IS 2016 installer, or with an installer you are building? If it is your installer, please let me know what type of project is failing: Suite, pure InstallScript, or InstallScript MSI. Also, is this failure occurring on a version of Windows older than Windows 8? We should have a fix available that you can try in this case. If this is related to installing IS 2016 please let me know what edition you are trying to install.
We believe we have a fix for this issue. Please let me know what edition of IS 2016 you are attempting to install (Express, Professional, Premier) so that I can provide a link to download an installer that you can try on Windows 7 machines that exhibit this problem.
Markus,
Is this an issue with the IS 2016 installer, or with an installer you are building? If it is your installer, please let me know what type of project is failing: Suite, pure InstallScript, or InstallScript MSI. Also, is this failure occurring on a version of Windows older than Windows 8? We should have a fix available that you can try in this case. If this is related to installing IS 2016 please let me know what edition you are trying to install.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 17, 2016
04:01 PM
None of them.
Next week I have a new project to build a suite installer for a customer. Last version I build with IS 2013 (works very well). Now I would like to use IS 2016 to build the new suite installer.
I read the thread and tried your test program on a few pc's of this customer to test if I run into trouble if I use IS 2016 to build the new suite.
The customer uses Windows 7 , Windows 8/8.1 and Windows 10 pc's, all with 64-Bit edition.
If necessary I can create a small "test suite" to check if the setup fails on the pc's where your "MarshalTest" program fails.
regards
Markus
Next week I have a new project to build a suite installer for a customer. Last version I build with IS 2013 (works very well). Now I would like to use IS 2016 to build the new suite installer.
I read the thread and tried your test program on a few pc's of this customer to test if I run into trouble if I use IS 2016 to build the new suite.
The customer uses Windows 7 , Windows 8/8.1 and Windows 10 pc's, all with 64-Bit edition.
If necessary I can create a small "test suite" to check if the setup fails on the pc's where your "MarshalTest" program fails.
regards
Markus
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 17, 2016
04:19 PM
Markus,
If you plan on building any suite installers with IS 2016, please make a backup of the following files and then replace the existing files with the files contained in the attached zip file:
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SetupSuite.exe
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SetupSuite64.exe
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SuiteAppxHelper.exe
The issue we have seen in the field is related to a change we made to lock down where third party DLLs can be loaded from in all of our setup launchers. On Windows 7 and older machine (back to Vista) an issue occurs partly due to this change that causes a failure in the CoMarshalInterface API the launchers rely on to implement certain parts of the setup UI functionality. As a result, suite launchers will fail to launch and will log a line such as 'UI resource exception: 80070057' in a debug log.
This failure is a combination of the code change we made, something installed on the machines where the failure occurs (one trigger is MSI packages that install the PSDispatch proxy/stub class that has been implemented by Windows for well over a decade), and then what appears to be a bug in the implementation of LoadLibraryEx with MS KB2533623 (or subsequent update that supersedes KB2533623) installed. The failure only occurs on Windows Vista/2008 or Windows 7/2008R2 machines as the behavior of LoadLibraryEx appears to have been changed on Windows 8.1 and newer.
Note that this issue also affects pure InstallScript and InstallScript MSI setup projects in the same circumstances, but the issue manifests itself as a crash during setup initialization (also as a crash while creating shortcuts on Vista/2008 machines that are fully updated).
If you plan on building any suite installers with IS 2016, please make a backup of the following files and then replace the existing files with the files contained in the attached zip file:
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SetupSuite.exe
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SetupSuite64.exe
\Program Files\InstallShield\2016\Redist\Language Independent\i386\SuiteAppxHelper.exe
The issue we have seen in the field is related to a change we made to lock down where third party DLLs can be loaded from in all of our setup launchers. On Windows 7 and older machine (back to Vista) an issue occurs partly due to this change that causes a failure in the CoMarshalInterface API the launchers rely on to implement certain parts of the setup UI functionality. As a result, suite launchers will fail to launch and will log a line such as 'UI resource exception: 80070057' in a debug log.
This failure is a combination of the code change we made, something installed on the machines where the failure occurs (one trigger is MSI packages that install the PSDispatch proxy/stub class that has been implemented by Windows for well over a decade), and then what appears to be a bug in the implementation of LoadLibraryEx with MS KB2533623 (or subsequent update that supersedes KB2533623) installed. The failure only occurs on Windows Vista/2008 or Windows 7/2008R2 machines as the behavior of LoadLibraryEx appears to have been changed on Windows 8.1 and newer.
Note that this issue also affects pure InstallScript and InstallScript MSI setup projects in the same circumstances, but the issue manifests itself as a crash during setup initialization (also as a crash while creating shortcuts on Vista/2008 machines that are fully updated).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 17, 2016
05:36 PM
Hi Josh,
thank you very much for your fast reply with Hotfix. I will try next week and will let you know if everything works.
regards
Markus
thank you very much for your fast reply with Hotfix. I will try next week and will let you know if everything works.
regards
Markus
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 28, 2016
08:30 AM
Hi Josh,
we tried to install Premier version of IS 2016.
Regards,
Pete
we tried to install Premier version of IS 2016.
Regards,
Pete
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 13, 2016
11:53 AM
I too am unable to install ( using the most recent installers) IS Premier 2016 on my Windows 7 machine, using either the full installer or the web installer. Are the official installers going to be fixed at some point?
