Shop

InstallShield
Advanced Installer
AdminStudio
more / weitere

InstallShield und AdminStudio Schulungen

weitere Infos

Bugs Bulletin

[ MSI Engine | MSMs | InstallShield 12 and newer | InstallShield 11.5 | DevStudio 9.0 | IS Dev 8.0 | IS Dev 7.0 | IPWI 2.0 | ISWI 1.x | IS Pro 7.x | IS Pro 6.x | IS Pro 5.x ]

InstallShield Professional - Windows Installer Edition 2.0

Last version: 2.03
Released: March 6, 2001
Downloads:
Registered owners of IPWI 2.0 can download the 2.03 maintenance release from http://support.installshield.com/download/ipwi203.asp.
Registered owners of IPWI 2.0 German Edition can download the 2.03 maintenance release at http://support.installshield.com/download/ipwi203_ge.asp
An updated Setup.exe to support MSI 2.0 is available from knowledge base article Q105501.
Release Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/download/ipwirelnotes.asp
Warning: After updating IPWI be sure to re-install your language packs before you open any project. Else all your string tables may be converted to English by the project update tool.

Known Problems in IPWI 2.03

Error 1406 on Windows 9x

Description:
While running your setup on Windows 95/98/Me you may get the following error message: "Error 1406: could not write value folders to key Software\Microsoft\Windows\CurrentVersion\Installer\InProgress. Verify you have sufficient access to that key, or contact your support personnel." The same setup works without problems on Windows NT/2000.
Cause:
In the Windows Installer, only directories in all upper-case are public and hence shared between the UI sequence and the execute sequence. In 2.03, upper-case entries are normally used to prevent surprising errors when a directory value is not maintained between the UI sequence and the execute sequence. Windows Installer stores all directory table entries that are in upper case in the above mentioned registry location. That is not a problem on NT systems, but may exceed the registry key size limit on Windows 9x if you have many directory table entries.
Workarounds:
Post process the MSI file to change the directory table entries to lower case so they won't get stored in registry. Or revert to IPWI 2.01 which did not store all the directory entries in upper case.
Status:
This is a limitation in the operating system.
Created: 2001-11-08

Setup with MDAC Merge Module Randomly Launches other Setup Program

Description:
While running the setup, another install program may be launched. This happens if another installer has left behind its setup.exe in the TEMP directory.
Cause:
The mdac.msm extracts mdac_typ.exe to the temp directory, and launches it with the command line parameters /q /c:"setup /qn1". Note that it's using "setup" not "setup.exe". A file called setup without .exe doesn't exist, and this seems to trigger a search algorithm in mdac_typ.exe, and it launches the first setup.exe it can find that resides in the same directory as mdac_typ.exe.
Workarounds:
Include and run mdac_typ.exe from a custom action with the proper command line parameters.
Status:
This problem is reproducible with the MDAC 2.5 SP1 and MDAC 2.6 merge modules in IPWI 2.03 and ISD 7.00.
Created: 2001-08-30

MDAC 2.5 and 2.6 Merge Modules Don't Merge Properly

Description:
The MDAC 2.5 and 2.6 merge modules sometimes don't merge properly. The custom actions and other properties don't get merged and when you validate the msi package it has about 48-60 ICE03-ICE27 and other errors. This probblem did not exist in ISWI 2.01.
Workarounds:
Include and run mdac_typ.exe from a custom action.
Status:
InstallShield confirmed that this is a problem in the MDAC merge module. It will not be fixed in IPWI 2.x.
Created: 2001-08-30

ICE03 Error "String overflow in registry table" when Validating Merge Modules that Contain COM-Components

Description:
If you create a merge module that contains a com-component (ActiveX control or local server) and then validate it you get "ICE03 Warning String overflow (greater than length permitted in column); Table: Registry, Column: Registry .....".
Cause:
When you switch the setting for "Registration" under "Advanced views/Components" from "Use advanced settings" which is the default to "Extract at build" the following happens: The ModuleID (GUID) which is placed in the registry table is appended with "_O" and the ModuleID once again. The result is a string that exceeds the column width specified in the column definition.
Workarounds:
None.
Status:
Installshield confirmed that this is a bug in IPWI2.03.
Created: 2001-08-30

Error 1911 "Could not Register Type Library"

Description:
Error 1911 "Could not register type library for file [2]. Contact your support personnel." during installation of one or more components on the target system. All dependencies are installed correctly, and the components that raise the 1911 error register properly when you use regsvr32 (dll/ocx) or the /regserver command-line switch (EXE). The components are set up correctly in Installshield.
The components that cause the error message are configured to use "extract at build" for their COM registration information. The problem only seems to occur after binary compatibility has been broken (as it often is, during development), and when you are using the same machine for compilation of the application object files and creation of the install set..
Cause:
The "extract at build" functionality appears to be using the registry information for the wrong (old) versions, and is using the wrong interface identifier information/registry information. This is what generates the 1911 error.
Note: Error 1911 can also be caused by missing dependencies, locale-specific components, corrupted object files, and several other causes. It is a bit of a catch-all message for COM registration problems.
Workarounds:
To avoid the problem unregister the components before you build the new version that is not binary compatible. If you already have outdated information in the registry of your development machine, run RegClean from Microsoft or a similar tool to remove the incorrect registry entries. Alternatively, create the install set from a machine with a fresh OS installation. RegClean can be downloaded from these locations: ftp://ftp.uakom.sk/pub/mirrors/sac/utilmisc/regcln41.exe or ftp://ftp.cs.tu-berlin.de/pub/msdos/mirrors/stuba/pc/utilmisc/regcln41.exe
Status:
This problem das been reported for ISWI 1.x, IPWI 2.x and ISD 7.00.
Created: 2001-08-30

Setup with InstallScript Custom Action Instantly Terminates with SetupCompleteError Dialog

Description:
A setup that includes custom actions written in InstallScript may fail and instantly show the SetupCompleteError dialog. This happens if the setup is an update and the previously installed version did not include InstallScript actions.
Cause:
In order to run InstallScript code, the InstallScript engine must be installed on the target computer. This is done with action EngineStartUp which is automatically added to your setup by IPWI if you are using InstallScript custom actions. However the EngineStartUp action has a condition of Not Installed and there doesn't run in an update install.
Workarounds:
Post-process your MSI file with Orca to remove the condition on the EngineStartupAction.
Status:
This problem is reproducible with IPWI2.03. Documented in InstallShield knowledge base article Q105420.
FIXED in ISD 7.00.
Created: 2001-08-30

Cannot Import Projects from IPSE 6.30

Description:
IPWI can import project files created with InstallShield Professional - Standard Edition 6.x. However this only work for projects created with IPSE versions before 6.30. Instead you get the following error messages: "Warning -62: Could not find section [Language] in file C:\My Installations\MyProject.ipr" and "Fatal error -112: Could not find section [Data] in file C:\My Installations\MyProject.ipr"
Cause:
In IPSE 6.30 the project file format has been changed.
Workarounds:
None.
Status:
InstallShield confirmed that this is a bug in IPWI 2.03.
Created: 2001-08-08

Component Wizard Doesn't Use Path Variables

Description:
If you use the Component Wizard to add a file, even if a path variable exists for that location, you get the full path assigned to it, not the path variable.
Workarounds:
Change the path entry manually.
Status:
InstallShield confirmed that this is a problem in ISWI 1.5. It is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
Created: 2000-06-05   Last update: 2001-08-08   InstallShield work order: 1-14NAY

Path Variables Not Used if Files are Added by Drag and Drop

Description:
If you use the Add dialog to insert a file into a component, ISWI will use existing path variables or suggest a new variable for the source path of the file (except if path variables are turned off). However if you add a file by dragging it from Explorer and dropping it on the IDE, ISWI always uses the full absolute path to the source file.
Workarounds:
Use the Add dialog, or use the Convert Paths wizard to replace absolute paths with path variables afterwards.
Status:
This problem has been reported for ISWI 1.50 and 1.52. It is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
Created: 2000-09-17   Last update: 2001-08-08

Ctrl+F7 Key Doesn't Start Compiler

Description:
Pressing Ctrl+F/ should start the InstallScript compiler, hower it does nothing.
Workarounds:
Click on the compile button on the toolbar or use the menu to invoke the compiler.
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
Created: 2001-05-05   Last update: 2001-08-08

Wrong Entries for AppPath Registry Key in Merge Modules

Description:
When building a merge module the value in the the Application Paths area (under Advanced Settings) for a component do not have the module GUID appended to it, i.e. [INSTALLDIR] is not replaced with [INSTALLDIR.728A5CA8-2EC6-11D5-A5E1-0004ACDD2460]. When the merge module is used the AppPaths registry entry points the install location of the main install not the location of the merge module, which may be different.
Workarounds:
Append the merge module GUID manually to INSTALLDIR either directly in the IDE or through Orca.
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
Created: 2001-04-26   Last update: 2001-08-08

InstallShield Logo Misplaced After Resizing Dialogs

Description:
Each dialog has a control about 4/5 way down which is a single line with the text "InstallShield" on the left hand side. This control cannot be moved or altered in any way. If you resize a dialog (as you need to do frequently with multi-languages), this control is moved in the dialog you resize to keep its position from the bottom of the dialog, but not in any of the others (which are also automatically resized). This means that as soon as you alter one dialog, the others have this control completely misplaced - it may be across the middle of the dialog, or out of sight (if you made the dialog smaller). Each dialog that you try to fix makes the others worse, with the extra catch that the "InstallShield" text gradually gets out of synch with itself and becomes illegible.
Workarounds:
None.
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
Created: 2001-06-27   Last update: 2001-08-08

Some Data Sources are Not Created

Description:
Some of the DSNs you specified in your project may not be created on the target machine. This happens if you create a DSN, then rename the DSN and the associated component, and finally create another DSN.
Cause:
Both DSNs get the same internal name, so only one of them makes it into the MSI file (the name is the primary key in the ODBCDataSource table).
Workarounds:
Create all your DSNs before you start renaming. This will make sure they get unique names with incremental numbers.
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
Created: 2001-04-26   Last update: 2001-08-08

Dialog Disappears in IDE

Description:
If you go to the dialogs view and select a dialog to edit the dialog layout, the dialog may be "gone". That is, it is still listed in the tree view, but if you click "English" to edit the dialog layout, the right hand pane is empty. This happens after you renamed entries in the string table.
Cause:
If you rename the string table Identifier that defined the path to the bitmap file for a bitmap control, the whole dialog disappers. To reproduce go to the string table and rename the Identifier IDS__IsLicenseDlg_9 to something else. Go to the dialog view and you won't see the LicenseAgreement dialog anymore (if this dialog is currently displayed, go to another dialog and return, to refresh the dialog editor).
Workarounds:
Rename the string table identifier back to its original name. This will bring the dialog back. (Again you may need to select another dialog and return, to refresh the editor.)
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03. It is also reproducible in IPWI 2.01.
FIXED in InstallShield Developer 7.0
Created: 2001-04-20   Last update: 2001-08-08

Runtime Error 35601 "Element not found" and Disabled IDE Toolbar Buttons and Menus When Editing InstallScript

Description:
You may receive a runtime error while editing InstallScript code for a custom action. Subsequently all toolbar buttons and menus in the IDE are disabled, so you are unable to save your changes. No prompt to save is shown when you exit the IDE.
Cause:
This happens if you change the case of a letter in a function name. Sample: Create a function MyFunction(hMSI), then select the 'y' character in MyFunction (using shift + right arrow) and replace it with an uppercase 'Y'. A message box with title "ISUISeqAct" and the following text is displayed:
Run=time error '35601':
Element not found
> ISUISeqAct.VuActionsL.OnCurrFunctionNameChanged
> ISUISeqAct.PropScriptEditor.ScriptEditor1_FunctionNameChanged
Workarounds:
None.
Status:
InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
Created: 2001-03-28   Last update: 2001-08-08

Error 2351 with Dynamic Links and Patch Optimization

Description:
During file transfer you receive an error message like this: "File key 'F1234_Somefile.exe' not found in cabinet 'Data.cab'. The installation cannot continue." This happens if you are using dynamic file links in components and have specified a Previous Windows Installer Package in the Patch Optimization screen, and you specified "Compress all files" for the release configuration.
Cause:
For dynamically linked files, IPWI assigns key names randomly by default, which prevents the Patch wizard from creating binary patches. With Patch optimization turned on, the release wizard applies the existing keys to files of the same name in the new release. Unfortunately it does not sync the file names it packages into the CAB file with the assigend file keys. Therefore the entries in the MSI file and the file names in the CAB file no longer match.
Workarounds:
You have several options:
- don't use patch optimization
- leave all files uncompressed
- don't use dynamic file links
Status:
This problem is reproducible in IPWI 2.01.
FIXED in InstallShield Developer 7.0
Created: 2001-02-22   Last update: 2001-08-08

InstallScript Debugger Not Working

Description:
When you try to debug custom actions written in InstallScript the debugger doesn't stop at the breakpoints.
Cause:
The InstallScript Debugger executable ISDbg.exe is not properly registered.
Workarounds:
Register the debugger by running the following command (while the IDE is closed):
<CommonFilesFolder>\InstallShield\IScript\ISDbg.exe /regserver
(replace <CommonFilesFolder> with the actual path on your machine). You will not get any messages that confirms the registration, but the debugger should now be working.
Status:
InstallShield has confirmed that this is an issue in IPWI 2.02.
FIXED in InstallShield Developer 7.0
Created: 2001-02-22   Last update: 2001-08-08   InstallShield work order: 1-49QVM

Patch Wizard Causes GPF

Description:
In some cases, the patch wizard in ISWI will abort with a General Protection Fault during the process where the two installs are examined for differences. This happens if you have a long text in the Comment property of the Summary Information Stream.
Cause:
Patch wizard addes about 80 characters to the Comment property in the summary information stream. This can cause the property to exceed the 255 character limit, which is causing an access violation.
Workarounds:
Shorten your text in the Comments property.
Status:
Microsoft has confirmed that this is a problem in Windows Installer 1.1 and should be addressed in 1.2. If it is not, InstallShield will attempt to provide a workaround. It is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
Created: 2000-06-08   Last update: 2001-08-08

InstallScript Compiler Errors Not Reported in Total Error Count

Description:
Building your setup: If the InstallScript compiler encounters an error or waring, it is displayed immediately in the output window, but scrolls out of sight quickly while the following build messages are issued. At the end of the build a total error and warning count is displayed, but the InstallScript errors are not added to the count. So you may end up with 0 errors 0 warnings even if there are syntax errors in your InstallScript.
Workarounds:
Scroll up in the output window to see the results from the InstallScript compiler.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5. It is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
Created: 2000-03-25   Last update: 2001-08-08

StreamFileFromBinary Doesn't Release Handles

Description:
The StreamFileFromBinary function is used to extract a file that is stored in the binary table to the support directory, so that it can be used in a custom action. Calling this function twice results in error 1500 "Another installation is in progress".
StreamFileFromBinary is an InstallScript custom action that can be found in <ISWI Program directory>\Samples\ScriptSamples\ScriptSamples\Setup.rul
Cause:
In the StreamFileFromBinary function, the binary record handle, database handle, and binary view handle don't get released.
Workarounds:
At the end of the StreamFileFromBinary script function are the following lines:
  //Close all handles
  CloseHandle(hFile);
  CloseHandle(hBinaryRecord);
  CloseHandle(hDatabase);
  MsiViewClose(hBinaryView);

Change them to:
  //Close all handles
  CloseHandle(hFile);
  MsiCloseHandle(hBinaryRecord);  // use MsiCloseHandle
  MsiCloseHandle(hDatabase);      // use MsiCloseHandle
  MsiViewClose(hBinaryView);      // releases only the result set for the view
  MsiCloseHandle(hBinaryView);    // releases the view itself
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5. It is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
Created: 2000-05-16   Last update: 2000-10-21

InstallShield for Windows Installer 1.5

Last version: 1.52
Released: August 1, 2000
Download: Registered owners of ISWI 1.50 can download the 1.52 maintenance release from http://support.installshield.com/download/iswi.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q104517

Known Problems in ISWI 1.5

VXDs Don't Get Updated if Media was Built on Windows NT

Description:
If you build your setup on Windows NT, the version information from .VXD and .386 device drivers will not be extracted. As a result, these files won't get updated on a Windows 9x target system, because "any version" in the existing file is considered to be newer than "no version" in the setup you are installing.
Cause:
The version WinAPI implementation on Windows NT cannot extract version info from .VXD and .386 files. There is a workaround as documented in Microsoft's knowledge base article Q201685, but obviously InstallShield isn't using it.
Workarounds:
Build on Windows 9x or populate the version fields in the file table with Orca after you have built your setup.
Status:
FIXED in IPWI 2.03
This problem also exists in the InstallShield Professional product line, with issue number 1-17XGX.
Created: 2000-10-04   Last update: 2001-03-08   InstallShield issue number: 1-47K0Q

Source Media Required for Uninstall

Description:
If you have an InstallScript custom action, you are prompted for the source media (CD etc.) at uninstall time. Apparently this occurs if the custom action occurs before InstallFinalize.
Workarounds:
Set your InstallScript custom action to "deferred execution" rather than "immediate execution" or place it after the InstallFinalize action.
Status:
InstallShield confirmed that this is a problem in ISWI 1.52.
FIXED in IPWI 2.01 (according to user report - it is not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue)
Created: 2000-10-13   Last update: 2000-10-24

ISWI Validation Wizard errors -98 and -146

Description:
If you change the size or position of any control in a dialog, you'll get a ISWI Validation Wizard error "-98 , Field Type of Control MenuText.: Null value for non-nullable field." for each control you've changed and one "-146 , Field Control First of Dialog CustomSetupTips.: The first control in the tab order of dialog CustomSetupTips points to nonexistent control Next as the next element" for each dialog where a control was changed.
Only ISWI validation reports these errors. Msieval2 doesn't and the setup seems to work fine.
Workarounds:
Make a copy of the dialog you want to change, make the changes you want and copy the desired controls and close the dialog without saving. Now go to the original dialog, delete the same controls you copied from the other one and paste them. Now you shouldn't get these validation errors. You should also go to the string table and delete the old entries, so as not to get duplicate entries, since ISWI created new entries for each control pasted.
Status:
InstallShield confirmed that this is a problem in ISWI 1.5 and 1.52.
FIXED in IPWI 2.0
Created: 2000-08-17   Last update: 2000-10-21

VXDs Don't Get Updated if Media was Built on Windows NT

Description:
If you build your setup on Windows NT, the version information from .VXD and .386 device drivers will not be extracted. As a result, these files won't get updated on a Windows 9x target system, because "any version" in the existing file is considered to be newer than "no version" in the setup you are installing.
Cause:
The version WinAPI implementation on Windows NT cannot extract version info from .VXD and .386 files. There is a workaround as documented in Microsoft's knowledge base article Q201685, but obviously InstallShield isn't using it.
Workarounds:
Populate the version fields in the file table with Orca after you have built your setup.
Status:
This problem also exists in the InstallShield Professional product line, with issue number 1-17XGX.
Created: 2000-10-04

StreamFileFromBinary Doesn't Release Handles

Description:
The StreamFileFromBinary function is used to extract a file that is stored in the binary table to the support directory, so that it can be used in a custom action. Calling this function twice results in error 1500 "Another installation is in progress".
StreamFileFromBinary is an InstallScript custom action that can be found in <ISWI Program directory>\Samples\ScriptSamples\ScriptSamples\Setup.rul
Cause:
In the StreamFileFromBinary function, the binary record handle, database handle, and binary view handle don't get released.
Workarounds:
At the end of the StreamFileFromBinary script function are the following lines:
  //Close all handles
  CloseHandle(hFile);
  CloseHandle(hBinaryRecord);
  CloseHandle(hDatabase);
  MsiViewClose(hBinaryView);

Change them to:
  //Close all handles
  CloseHandle(hFile);
  MsiCloseHandle(hBinaryRecord);  // use MsiCloseHandle
  MsiCloseHandle(hDatabase);      // use MsiCloseHandle
  MsiViewClose(hBinaryView);      // releases only the result set for the view
  MsiCloseHandle(hBinaryView);    // releases the view itself
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5
Created: 2000-05-16   Last update: 2000-10-04

Path Variables Not Used if Files are Added by Drag and Drop

Description:
If you use the Add dialog to insert a file into a component, ISWI will use existing path variables or suggest a new variable for the source path of the file (except if path variables are turned off). However if you add a file by dragging it from Explorer and dropping it on the IDE, ISWI always uses the full absolute path to the source file.
Workarounds:
Use the Add dialog, or use the Convert Paths wizard to replace absolute paths with path variables afterwards.
Status:
This problem has been reported for ISWI 1.50 and 1.52.
Created: 2000-09-17

Patch Wizard Causes GPF

Description:
In some cases, the patch wizard in ISWI will abort with a General Protection Fault during the process where the two installs are examined for differences. This happens if you have a long text in the Comment property of the Summary Information Stream.
Cause:
Patch wizard addes about 80 characters to the Comment property in the summary information stream. This can cause the property to exceed the 255 character limit, which is causing an access violation.
Workarounds:
Shorten your text in the Comments property.
Status:
Microsoft has confirmed that this is a problem in Windows Installer 1.1 and should be addressed in 1.2. If it is not, InstallShield will attempt to provide a workaround.
Created: 2000-06-08

Component Wizard Doesn't Use Path Variables

Description:
If you use the Component Wizard to add a file, even if a path variable exists for that location, you get the full path assigned to it, not the path variable.
Workarounds:
Change the path entry manually.
Status:
InstallShield confirmed that this is a problem in ISWI 1.5
Created: 2000-06-05   InstallShield work order: 1-14NAY

InstallScript Compiler Errors Not Reported in Total Error Count

Description:
Building your setup: If the InstallScript compiler encounters an error or waring, it is displayed immediately in the output window, but scrolls out of sight quickly while the following build messages are issued. At the end of the build a total error and warning count is displayed, but the InstallScript errors are not added to the count. So you may end up with 0 errors 0 warnings even if there are syntax errors in your InstallScript.
Workarounds:
Scroll up in the output window to see the results from the InstallScript compiler.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5
Created: 2000-03-25   Last update: 2000-05-26

InstallShield for Windows Installer 1.1

Last version: 1.1
Released: February 1, 2000
Order / Download: The update to InstallShield Professional 2000 Second Edition can be ordered or downloaded from http://support.installshield.com/download/ispro2000.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q103171

Known Problems in ISWI 1.1

Problems that apply to both ISWI versions, 1.1 and 1.5, are listed under ISWI 1.5 above.

Path Variables Evaluated Wrong

Description:
If you create a new path variable by appending an existing path variable to a constant path, the path is missing some parts. Example:
Create two path variable and define the values as follows:
Path1 :  TestDir
Path2 : C:\Test\<Path1>
Now Path2 should evaluate to C:\Test\TestDir (and it did in ISWI 1.03), but in ISWI 1.1 it is set to only TestDir.
Workarounds:
None.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
Created: 2000-03-30   Last update: 2000-05-26

Reboot Fails if Setups Includes InstallScript Custom Actions

Description:
After running a setup that uses a custom action written in InstallScript, Windows can no longer be rebooted. This problem does not only affect the setup itself (reboot dialog does not reboot) but the whole system (reboot via the Start menu also fails).
This problem has only been reported for Windows NT, not for Windows 9x.
Cause:
The iKernel.exe task is still active and prevents the reboot. iKernel.exe is the InstallScript runtime engine. Terminating this task in the task manager solves the problem and allows the system to reboot.
Workarounds:
Insert a VBScript custom action with deferred execution. In the script call Session.DoAction("CleanUp"). This will unload iKernel.exe.
You can also do this in a DLL: MsiDoAction (hInstall, "CleanUp");
If you need to start the InstallScript engine again, you can re-start it with Session.DoAction("StartUp") resp. MsiDoAction (hInstall, "StartUp");
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
Created: 2000-03-25   Last update: 2000-06-28

Shortcut to Command Script Doesn't Open DOS Window

Description:
After you installed a shortcut to a NT command script, you double click the icon but nothing seems to happen. In fact, the script is started, but no command prompt window is opened.
Cause:
For shortcuts with the Run property set to "Normal Windows" ISWI inserts the value 0 in the ShowCmd field of the MSI database. The correct value is 1.
Workarounds:
Change the ShowCmd field entries from 0 to 1 after you built the MSI file. You can use the following command line program for this purpose.
ZIP FixShowCmd.zip   From newsgroup installshield.iswi.general
File size: 9.355 bytes   Last update: 2000-04-06.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
Created: 2000-04-06   Last update: 2000-05-22

ICE03 Error Validating Merge Modules

Description:
If you create a merge module and then validate it, you'll receive "Missing specifications in _Validation Table" error messages.
Cause:
The specifications are missing because there were no merge module validation specs at the time ISWI 1.1 was released.
Workarounds:
None.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
Created: 2000-04-01   Last update: 2000-05-22

InstallScript Custom Actions Don't Work in Silent Mode

Description:
InstallScript custom actions work correctly if you do a normal install, but they are not executed if you do a silent installation. They start working after you any setup that uses InstallScript CAs in normal mode
Cause:
In silent mode the InstalShield script interpreter doesn't get installed.
Workarounds:
None.
Status:
InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
Created: 2000-04-01   Last update: 2000-05-22

Setup Design Tree View Not Working on French Windows

Description:
On systems with French locale settings, the feature tree in Setup Design view of the IDE doesn't show the feature nodes. This affects the summary and the feature views, however the component view is working properly.
Cause:
In Microsoft newsgroups there are reports about a bug in the tree view control: a key for the tree may be converted to a number if it is identical to the currency symbol. You can reproduce the problem by setting your currency symbol to F even on an English version of Windows.
Workarounds:
Follow these steps to change the currency symbol:
1. Close the ISWI IDE.
2. Open Control Panel and launch the Regional Settings icon.
3. Go to the Currency tab.
4. Change the currency symbol from F to FF or Fr for instance.
5. Launch ISW and open your project.
The setup design tree view should now be operational.
Status:
This problem has been reported in the newsgroups.
FIXED in 1.5
Created: 2000-05-19   Last update: 2000-05-22

InstallShield for Windows Installer 1.0

Last version: 1.03 (This version has been superceded by 1.1 which is available free of charge for registered users of ISWI 1.0x)
Released: November 15, 1999
Download: http://support.installshield.com/download/iswi.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q103171

 

 

 

English News Discussions Windows Installer Related Tools More Help InstallScript About InstallSite Shop Site Search
deutsch Neuigkeiten Diskussionsgruppen Windows Installer MSI FAQ Artikel     Shop Suche

Copyright © by InstallSite Stefan Krueger. All rights reserved. Legal information.
Impressum/Imprint Datenschutzerklärung/Privacy Policy
By using this site you agree to the license agreement. Webmaster contact