11 replies to this topic

[baagan]

My customer is trying to install our product on his XP Home SP2 laptop. Initially he was getting a 1628 error. I had him clean out the C:\Program Files\InstallShield and C:\Program Files\Common Files\InstallShield folders. I then had him go into Safe Mode and try to run the installation. When he started to run the install, he got a 1607 error. I then had him go back into Normal Mode and re-run the setup. Now he no longer gets the 1607 error.

Now the install begins correctly. It will ask him which install he wants to use (Typical, Custom…etc) and he’ll choose it and it will move along as normal. The install then appears as if it’s copying files because the progress bar will start to move. The progress bar gets to 100%, the window that says Registering Product comes up, and then the install dies. The Install Window disappears and returns the customer to his desktop. I’ve had him check the running processes and nothing related to the install is running in the background. InstallShield just up and quits.

I’ve had the customer clean out his Temp folder. I’ve had the customer register both the MISEXEC.EXE and the IDRIVER.EXE files and then re-run the setup. Same problem. I’ve had the customer log in using both his and the Admin account. Same problem. I’ve had him run the ISSCRIPT.MSI, and then try to install. Same problem. I had him download the Windows Installer Cleanup app and check for our product. It is not found.

The install is crashing before any of our product's files or registry settings are being written to the machine. I had him do a manual search of the registry for references to our product. No entries. I had his hard drive for files related to our product. None found.

Install created with Developer 7 SP4.

Suggestions?

[Stefan Krueger]

Can you have him generate a log file (make sure to inlude the ! switch) to find out which command is causing the crash. I suspect it's either a custom action of some InstallScript code. (You can also insert MessageBoxes in your InstallScript function to find out where the crash happens)

[baagan]

Thanks for the suggestion Stefan. Could you be a little more specific on how I would have him generate a log file?

[baagan]

All right, I got the installation logged. Below is what I figured would be relevant.

The first thing that seems odd, when comparing the log from this user to a log of a successful setup, is something about a Leaked MSIHANDLE. There are entries like the section below from (166) down to (28). After the Leaked MSIHANDLE references are done, it appears to continue on with a long list of the install's Properties. After the list of Properties, the install fails, returning 1708 then 1602. Please see the portions of the log file below.

MSI © (48:2C) [10:24:05:687]: MsiProvideComponentFromDescriptor is returning: 0
1: MsiServerStartup ends
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (166) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (165) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (164) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (163) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (162) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:697]: Leaked MSIHANDLE (161) of type 790531 for thread 428

~<INSERT the rest of the Leaded MSIHANDLE lines here>~

MSI (s) (A8!AC) [10:24:05:707]: Leaked MSIHANDLE (29) of type 790531 for thread 428
MSI (s) (A8!AC) [10:24:05:707]: Leaked MSIHANDLE (28) of type 790531 for thread 428
1: RPC server shut down.
Action ended 10:24:05: ISCleanUpUserTerminate. Return value 1.
Action ended 10:24:05: INSTALL. Return value 2.
Action ended 10:24:05: ISMsiServerStartup. Return value 0.
Property(S): DCOMISPRESENT = 1
Property(S): CURRENTDATE = 11-15-2004 10:22:57

~<INSERT the rest of the Property(S) lines here>~

Property(S): IEVERSION = 6.0.2900.2518
Property(S): ProductToBeRegistered = 1
MSI (s) (A8:18) [10:24:06:068]: Note: 1: 1708
MSI (s) (A8:18) [10:24:06:068]: Product: <My Product's Name Goes Here> -- Installation operation failed.

MSI (s) (A8:18) [10:24:06:078]: Cleaning up uninstalled install packages, if any exist
MSI (s) (A8:18) [10:24:06:078]: MainEngineThread is returning 1602
MSI (s) (A8:60) [10:24:06:078]: Destroying RemoteAPI object.
MSI (s) (A8:88) [10:24:06:078]: Custom Action Manager thread ending.
=== Logging stopped: 11/15/2004 10:24:06 ===
MSI © (48:44) [10:24:06:098]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI © (48:44) [10:24:06:098]: MainEngineThread is returning 1602
=== Verbose logging stopped: 11/15/2004 10:24:06 ===


Any ideas?

[Stefan Krueger]

The leaked handles are usually only debug messages but shouldn't cause the setup to fail.
1708 means "Installation operation failed." but doesn't give any information about the reason.
I think there must be some action with a return value other than 0 or 1 earlier in the log.

[baagan]

Thanks again for the suggestion Stefan. I did find one other Return Value that was non-0/1. It's in the section of the log I copied below:

MSI © (48:2C) [10:24:00:510]: MsiProvideComponentFromDescriptor is returning: 0
MSI (s) (A8:18) [10:24:00:510]: Executing op: CustomActionSchedule(Action=OnMoved,ActionType=3073,Source=BinaryData,Target=Moved,)
MSI (s) (A8:38) [10:24:00:520]: Invoking remote custom action. DLL: C:\WINNT\Installer\MSI34.tmp, Entrypoint: Moved
MSI © (48:5C) [10:24:00:971]: Entering MsiProvideComponentFromDescriptor. Descriptor: o9npMj8*2=sT_Bx}J{FvScannedProject>M5KDYSUnf(HA*L[xeX)y, PathBuf: 413F4BC, pcchPathBuf: 413F4B8, pcchArgsOffset: 413F418
MSI © (48:5C) [10:24:00:971]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI © (48:5C) [10:24:00:971]: MsiProvideComponentFromDescriptor is returning: 0
MSI © (48:5C) [10:24:00:971]: Entering MsiProvideComponentFromDescriptor. Descriptor: o9npMj8*2=sT_Bx}J{FvScannedProject>M5KDYSUnf(HA*L[xeX)y, PathBuf: 413EE28, pcchPathBuf: 413EE24, pcchArgsOffset: 413ED84
MSI © (48:5C) [10:24:00:971]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI © (48:5C) [10:24:00:971]: MsiProvideComponentFromDescriptor is returning: 0
MSI (s) (A8:18) [10:24:00:981]: User policy value 'DisableRollback' is 0
MSI (s) (A8:18) [10:24:00:981]: Machine policy value 'DisableRollback' is 0
Action ended 10:24:00: InstallFinalize. Return value 2.
MSI (s) (A8:18) [10:24:00:991]: Executing op: Header(Signature=1397708873,Version=300,Timestamp=829379307,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (A8:18) [10:24:00:991]: Executing op: DialogInfo(Type=0,Argument=1033)
MSI (s) (A8:18) [10:24:00:991]: Executing op: DialogInfo(Type=1,Argument=<<My Product Name Here>> Professional Edition 6.2)

[Stefan Krueger]

That doesn't help much either, I'm afraid. It's really hard to find out why an InstallScript MSI project fails. That's one of the reasons why I prefer Basic MSI.

[baagan]

Well, I just found a post on InstallShield's forums that has some people experiencing what looks to be the same issue:

http://community.ins...ad.php?t=139045

The common thread among the problems seems to be XP SP2. I guess I'm going to have our tech support people have the customer try uninstalling SP2 (using XP Home SP2) and see if that magically fixes anything.

At any rate, my complete log file was attached to my last post there if you're interested in checking it out.

[baagan]

Uninstalling XP SP2 worked. Once it was removed the customer installed without problem. Still trying to figure out why.

[Stefan Krueger]

Thanks for this information. If there is a common problem with InstallScript SMI on XP Sp2 I guess this will be causing serious headaches for some people.
BTW your log didn't attach, maybe it was too big (limit is 100 K, please try and ZIP it next time)

[baagan]

The log was attached to the post on the InstallShield forum. It was 1.7 MB and zipped it was still a tad too big to attach here (108 KB).

[bkeadle]

I'm seeing this same problem. I'm looking for a resolution that doesn't require an uninstall of SP2.

On two completely seperate software installs that use a SETUP.EXE InstallShield "package" will go through the install, even report in the EventLog that the installation was successful...even copies the files (I see them in the target directory for a brief moment), then after "Registering product ==} Publishing product..." it'll say that the InstallShield was interrupted, and all the files are removed, and an event is logged saying that the installation failed. It appears that Quicken 2005 is probably a third install that is exhibiting this behavior.

I've been combing the Internet looking for some explanation and workaround (other than uninstalling SP2) and haven't found any yet.