How do I prevent InstallShield 1158 errors?

Question

Sometimes, when running an InstallShield installation, an error dialog will appear containing the text "1158", and OK button, and nothing else. InstallShield error 1158 means there was a problem with loading strings from the associated ini file, but Flexera's troubleshooting steps have not worked for me. Also, I doubt that there is actually a problem with the strings; the information on that page suggests that a problem with strings would not be intermittent.

Here are the results of my investigation so far:

• The problem occurs before any other dialogs are displayed (including the prerequisites dialog), which leads me to believe this is a problem with the bootstrapper (setup.exe), not Windows Installer.
• The problem is intermittent, occurring frequently on some machines and almost never on others.
• The problem is not related to a particular build of the installation. The same setup.exe might fail one time and succeed if run again on the same machine.
• The problem appears to be related to Windows Explorer. I've never been able to reproduce this by launching the setup.exe through other means (e.g. cmd.exe).
• This hampers debugging efforts, since passing command line arguments to generate debug logs causes the installation to succeed.
• I've only seen this problem on Windows XP.
• This may not mean anything since newer versions of Windows are not used often within my company.

Has anyone else encountered this problem or know of a fix?

Answer 1

I opened a support ticket with Flexera to get to the bottom of this. Based on their responses, this is a translation problem with the setup.exe bootstrapper. In InstallShield 2009, if the "Setup Launcher Type" field (on the "Setup" tab of a release) is set to Unicode, this problem might happen sometimes. Setting the "Setup Launcher Type" to ANSI seems to fix the problem. Also, I have not experienced the problem in InstallShield 2010, so they might have already fixed it.

As a side note, I was told that InstallShield 2009 was the first version to allow a "Setup Launcher Type" of Unicode, so this bug was probably introduced in that version. Prior versions always used ANSI.