9 replies to this topic

[jwc]

This is an unusual case I've run into. I've checked back in the archives for about a year and haven't run into anything like this, so I apologize if I am bringing up an old topic.

When I run the uninstallation from (Vista) Program and Files, selecting the product and clicking the "Uninstall" button, everything is uninstalled except for the shortcuts in the Start->Programs menu. (Incomplete uninstall)

When I run the uninstallation from Program and Files, selecting the product and clicking "Change" and then selecting the "Remove" radio button, everything is removed including the shortcuts in the Start->Programs menu. (Complete uninstall)

This also occurs on XP. Also, I've noticed that the UI from those two cases is different.

In playing with this further, I've used the command line options on msiexec. When I use the /qf or /qr options, I get a complete uninstall. When I use the /qb or /qn options, I get the incomplete uninstall.

In all of these cases, the MSI hasn't changed. The best I can come up with is that there is some flag I am missing, or a condition that I need to set. The Delete Shortcuts action is the standard action with no conditions on it. Is there something I'm missing? It doesn't seem to be UAC related. I get the UAC window on all except the /qn runs. I'm using InstallShield 12 Professional, building on an XP box, running the MSI on both an XP and a Vista box.

Thank you!
jwc

[jwc]

Also, more info...

When I run the Program & Files Uninstall, it seems like Windows is using the /qb option when calling msiexec.

When I run teh Program & Files Change, it seems like Windows is using the /qf option when calling msiexec.

That seems to be why I see an incomplete uninstall when clicking "Uninstall", while I see a complete uninstall when clicking "Change" and selecting the "Remove" radio button.

Thanks again,
jwc

[Stefan Krueger]

Clicking the Uninstall button in control panel will run the uninstall in basic UI mode (/qb). In this case, Windows Installer uses its built in UI and completely skips your IstallUI sequence. So anything you do in the UI seqiuence won't happen.
Such problems typically are caused by custom actions that only exist in the UI sequence that are required for successful uninstall, like setting some directory, property, etc. Yre you chaning the shortcut names dynamically maybe?

[jwc]

Stefan, thanks for the reply.

No, I do not believe I am dynamically changing the shortcut names. However, I do have four custom actions:

- Make sure task scheduler is running (called after InstallFiles (&[feature]=3))
- Remove my old (leftover) scheduled task, if it exists (called after the task scheduler check, called on install (&[feature]=3))
- Add a scheduled task (called after remove of old scheduled tasks(&[feature]=3)
- Remove scheduled task (called after RemoveDuplicateFiles, called on uninstall (&[feature]=2)

None of these deal with the shortcuts, but these all are called. The scheduled tasks are removed when called from msiexec with /qb.

Now, about dynamically changing the shortcut names: I have them all set up under one component, under one feature. I am not referring to them anywhere else in the ISM. I've looked at the Install/UI sequence and the Install/Execute sequence. I don't see anything custom in the Install/UI sequences. I have those four custom actions in the Install/Exec sequence. Is there something I should look for?

Thanks!
jwc

[Stefan Krueger]

In this case I recommend a verbose log of the uninstall. Pay attantion to the paths listed in the log.

[jwc]

I've looked at the logs from both the /qb and /qf uninstalls. Like you said, it is because of the paths. With the /qb option, ALLUSERSPROFILE is set to D:\, which doesn't have a D:\Start Menu\Programs\..., while in /qf, ALLUSERSPROFILE is set to C:\ProgramData, which does have a D:\Program Data\Start Menu\Programs\...

I'm running this on Vista, and everything is the same. I'm running msiexec from the same Administrator enabled command window. The only change is the msiexec command line parameters.

Any thoughts on what I should look at? I've looked in the String Tables and the Property Manager, but I am not seeing anything ALLUSERSPROFILE related.

I'm attaching a modified version of the two log files. I've cut off the first 20 or so characters that contained the timestamp so the files would be easier to compare. The lines of interest appear to be around line 250, where the ALLUSERSPROFILE gets set and on lines 430 (logb1.txt) / 700 (logf1.txt) where the folders in the start menu are 'removed'.

Thanks!
jwc

Attached Files

•  logs.zip   29.49KB   89 downloads

[Stefan Krueger]

The ALLUSERSPROFILE property is set by InstallShield's setAllUsersProfile2K custom action. This custom action only exists in the UI sequence, which explains the behaviour you are seeing. I have no idea why InstallShield didn't put this action in the Execute sequence, too.
If you add it to the execute sequence (and set it to run only once) I think this should fix your problem. I don't think this would cause any harm, but there might be reasons why INstallShield didn't do this automatically.

[jwc]

I don't know how to make it run once, but I did add it in, before CostInitialize. I can't tell if it worked or not because I ran into a different issue. The VBScript I am running makes a call to WScript.Sleep. InstallShield pops up an error that WScript (with line and column number) is an undefined variable. The script runs fine in stand-alone mode. Is there an alternate to WScript.Sleep I should use? I'm calling WshShell.Exec to execute a command line, and the documentation says to wait/sleep until Exec.Status goes from 0 to 1, and then you can read Exec.ExitCode.

Odd thing is that it never complained about that line the hundred other times I ran the script. Maybe this was the one time that the command line didn't return before it went into that loop?

Thanks!
jwc

[jwc]

Stefan, thank you. It works now.

I added the setAllUsersProfile2K CA into the install exec sequence. (What is the condition(s) so that it only runs once?)

Then I had to do some rewriting of my scripts. Some of the WScript calls I had in them weren't working. Looks like other people have run into this, too. Also, I modified my scripts so that InstallShield was calling a function (using Script Function) rather than just loading and running the whole file. That change allowed me to get rid of WScript.Quit at the end of the file, but it cost me the ability to run the script standalone. There are ways around that, though, if I really want to do that (for testing purposes)

Now, does anything I've said sound suspicious? I haven't been playing with InstallShield that long, and I don't understand it as well as I would like. If I've headed off into the weeds, please tell me.

Thanks!
jwc

[Stefan Krueger]