InstallShield hang on Windows 2000 server(sp4)

[sutton]

I have a customer, he installed a package(InstallShield 2008) to Windows 2000 server(sp4), Installation hang ten minutes, and then installation fail, this occur only his machine, any other win2000,winxp,win2003 can not reproduced. I used command /verbose to get a log as following:

Action ended 11:18:13: CostFinalize. Return value 1.
MSI (c) (E8:BC) [11:18:13:508]: Doing action: MigrateFeatureStates
Action 11:18:13: MigrateFeatureStates. Migrating feature states from related applications
Action start 11:18:13: MigrateFeatureStates.
Action ended 11:18:13: MigrateFeatureStates. Return value 0.
MSI (c) (E8:BC) [11:18:13:508]: Doing action: ISSetupFilesCleanup
Action 11:18:13: ISSetupFilesCleanup.
Action start 11:18:13: ISSetupFilesCleanup.
MSI (c) (E8:80) [11:18:13:586]: Invoking remote custom action. DLL: C:\DOCUME~1\kevin\LOCALS~1\Temp\1\MSI8.tmp, Entrypoint: SFCleanupEx
Action ended 11:18:13: ISSetupFilesCleanup. Return value 1.
MSI (c) (E8:BC) [11:18:13:602]: PROPERTY CHANGE: Adding ISSETUP_UISEQUENCE_PROCESSED property. Its value is '1'.
InstallShield 11:18:13: Not using skins for this installation. Could not find skin file .
InstallShield 11:18:13: Ready to initialize IDriver.
InstallShield 11:18:13: Inside Initialize, ref count is 1
InstallShield 11:18:13: Inside Open Script
InstallShield 11:18:13: Script engine created.
InstallShield 11:18:13: Opening script: C:\DOCUME~1\kevin\LOCALS~1\Temp\1\{6FD18C3C-EC76-4721-9EC0-8B2BC06A74CE}\setup.inx
InstallShield 11:18:13: InstallShield script opened successfully.
InstallShield 11:18:13: Ready to initialize full UI support.
MSI (c) (E8:BC) [11:18:13:758]: Leaked MSIHANDLE (3) of type 790541 for thread 3516
MSI (c) (E8:BC) [11:18:13:758]: Leaked MSIHANDLE (2) of type 790537 for thread 3516
MSI (c) (E8:08) [11:27:28:024]: Destroying RemoteAPI object.
MSI (c) (E8:78) [11:27:28:024]: Custom Action Manager thread ending.
=== Verbose logging stopped: 9/1/2008 11:27:28 ==

Do you have the same problem? who could tell me root cause?

[joshstechnij]

Can you try disabling any non-essential services on this machine such as antivirus utilities, anti-malware/spyware utilities, etc. and then try running the installation again? Since this behavior is isolated to one machine, there is likely something related to the environment on this machine that is causing the behavior.

[sutton]

thanks joshstechnij, in customer's machine, Microsoft® Internet Security and Acceleration (ISA) Server is running all the time. Does it conflict with InstallShield setup package?

[sutton]

customer use a domain account log on, is it a trouble?

[joshstechnij]

I'm not aware of any specific issues with Microsoft Internet Security and Acceleration Server or running the installation from a domain account. You could elimate these items as possible causes by disabling ISAS and by running the installation from a local admin account.

Disabling any non-essential services on the machine is suggested in these scenarios because of issues that we have seen in the past. There was a recent issue caused by an antivirus utility that was blocking some of the InstallScript engine DLLs from being loaded because they were flagged as a "threat". Anything running on the machine that hooks into the user mode module (DLL) loader or that can interfere with COM could potentially cause the engine to fail. In most cases there aren't any issues.

Based on the log info, the engine is failing to launch at a point where it is attempting to create internal UI objects that manage the user interface (specifically, the main window). This part of the engine initialization relies upon COM and stock Windows APIs (such as CreateWindow). Because this is a relatively simple process that is working fine on other machines, the behavior seems to indicate that something on the machine is interfering with the normal operation of the engine. It is possible that other InstallScript MSI (and potentially pure InstallScript) projects built with InstallShield 12 or newer would also encounter unpredictable behavior on this machine.

[sutton]

Thanks joshstechnij. My customer try the suggestion you advised, and it still fail with the same error. Are there any other factors affect installation? Thank you in advance!

[joshstechnij]

Unfortunately, without being able to debug the engine in an environment that reproduces this behavior, it is difficult to tell why this behavior is occurring. There are a few possible causes:
- COM is broken on the machine.
- COM security settings have been changed on the machine, causing access to be denied to certain resources.
- Something is still running on the machine that is hooking into the installation process and the Windows APIs we depend on.

Since the engine uses COM before the point that it is failing, it seems unlikely that the first two items above could be the cause.

You may try using the Process Monitor utility from SysInternals to see what is being loaded into the setup.exe process between the time ISSetup.dll is loaded and the time the issue occurs. If anything is loaded that does not ship with Windows, turn off/disable whatever installed that item.

[sutton]

joshstechnij, Could you tell me which COM object installation engine used? Does it ship with Windows? Thanks!

[joshstechnij]

The COM interfaces the engine uses are its own interfaces. The only external COM interfaces that might be used during an installation (not during initialization) are the IShellLink interface and possibly some other miscellaneous ones.

Typically, in order for COM to work at all on a machine, ole32.dll, oleaut32.dll, stdole2.tlb, stdole32.tlb (and possibly stdole.tlb), and likely a number of other files need to be present and registered (the above files are ones that have been known to cause issues for the InstallScript engine in the past).

Based on the log information, the engine is able to register its interfaces (these are registered in memory each time the engine is initialized; this avoids a dependency on the registry) and is able to make a number of COM interface calls before it encounters an issue. This would seem to rule out the possibility that COM is broken on the machine.