3 replies to this topic

[spsexton]

I'm having problems with an IS 10.5 Basic MSI install on NT4SP6. I'm installing Win Inst 2.0.

The basic problem is that I get two internal errors as the installation starts: 18 & 1601, and the installation does not continue. Windows Installer 2.0 is not present as a service after the install crashes in this way.

I managed to recreate this problem with a very simple wizard-generated 10.5 Basic MSI installation that installs a single file. Out of the box, the wizard-generated install has exactly the same problem on a completely clean NT4 SP6 machine--I get the two internal errors.

However, if I change the "Delay MSI Engine Reboot" option to No, in this simple project, the installation then works--I get a Reboot message during installation of WI2.0 and, after reboot, the installation completes normally.

I can also avoid the problem (in the simple project) if I first manually install instmsiw.exe.

If I go back to my main product install and try turning off the delayed reboot, I still see the same internal errors.

If I try first manually installing instmsiw.exe and then running my main product install, I get the same internal errors.

If I turn on logging (l*v), passing param to setup.exe to get it to log, I don't get quite the same internal errors, but now get an error from IDriverT.exe, complaining that it can't find ATL.dll. Log file shows nothing unusual, or related to either the ATL.dll problem, or the internal errors. Nothing in my project requires ATL. The error message that indicate that path searched for ATL.dll mentions InstallShield\Driver\1050 path, which makes me think that it's the InstallScript engine that wants ATL.dll. I tried including ATL msm, but no difference in symptoms.

Other info:
- My clean machine testing is done on a VMWare machine
- I'm running InstallShield 10.5 SP1
- Version of WI2.0 is the one incl w/IS10.5 (3/11/02)

Any thoughts on this? Questions that I have include:
- Why am I getting error 18 & 1601, out of the box on NT4, with wizard-generated install?
- Why does forcing reboot after instmsiw.exe install work for wizard-generated project, but not for my main project?
- Why does manual install of instmsiw.exe fix probl for wizard-generated project, but not for my main project?
- Why is InstallShield struggling with launching a WI2.0 install on clean NT4SP6 machine?
- Why does IS1050 seem to be looking for ATL.dll ?

Thoughts or suggestions on what to try next?

Thx much,
Sean

[Stefan Krueger]

Do you have any InstallScript in your project?
Have you tried this on a real machine. It might be a VMware issue.

[spsexton]

Yes, the problem occurs on real (clean) machines as well. At any rate, VMWare is a good enough emulation of real hardware that you can pretty much guarantee it accurately models a real machine--at least one real machine, that is, with hardware matching what VMWare is modeling. I've used VMWare for development for years and we've never found behavior on a VM that we didn't see on real machines.

Yes, I do have InstallScript in my project, which is what triggers the installation is ISScript1050.msi by the setup.exe launcher.

The basic problem here is that the InstallScript engine requires ATL 3.0, but does not install it--either as a merge module, or a prerequisite. Adding an ATL merge module to my project does no good because the InstallScript engine gets installed and started before my project even gets started up. (Though one could try sneaking in a CA just prior to start of ISScript engine in UI sequence).

I'm currently of the mind that this is an InstallShield bug--ISScript1050.msi, given that it needs ATL 3.0, should install it. If you just install ISScript1050.msi, independently of any project, it will not run on NT4SP6 machine, due to the missing ATL.dll file.

I did find a workaround that is reasonable, however. I created a new install package to install ATL 3.0 (project includes just single merge module) and compressed everything into a single setup.exe. I then add a setup prereq to my main project, where the prereq is the new ATL 3.0 installation. Then, when my main setup.exe launcher starts, it takes care of the prereqs BEFORE installing/starting ISScript--eliminating the problem. Not quite as clean as if ISScript itself had installed ATL, but it works fine.

One trick is to make sure that the new ATL project does not add an entry in Add/Remove. For this I set ARPSYSTEMCOMPONENT property to 1.

The other bug that I had been seeing was the internal errors 18 & 1601 as part of the MSI 2.0 install on NT4SP6. If you install instmsiw.exe manually, the install works, but msiexec.exe doesn't get registered (see KB http://support.insta....icleid=Q110564) and you get the same internal errors when you try to run your own install. Even with a minimal Basic MSI project, no InstallScript, you get the same MSI internal errors.

The solution for these MSI internal errors is either to hand register msiexec.exe after manually installing instmsiw.exe (not a great solution for your end users). Or something that I stumbled on--if I turn off Delayed Reboot for MSI engine, it does a reboot after MSI install and then, somehow, msiexec is registered properly and your application install continues just fine.

[Stefan Krueger]

I know VMware, and I have seen reports of (rare) issues related to it. That's why I asked.
Indeed it sounds like a bug in isscript.msi. Another workaround would be to avoid InstallScript in your MSI project.