I have created an installation as a Basic MSI project, which worked reliably until recently, when I discovered a new problem: when Remove is initiated, the RemoveProgress dialog simply hangs up indefinitely, without any progress on the progress bar. Further investigation showed:
1. this is due to an instance of IDriver.exe running. As soon as that is switched off in the Task Manager, the uninstall proceeds as normal, but then hangs on the final "Uninstall complete" dialog, which will not go away when "Finish" is clicked and also has to be dismissed with TM.
2. this problem does not happen consistently on all machines. On my own developmant machine uninstall occurs OK, but the same installation still has the problem on other machines.
IDriver seems to be started early in the uninstall sequence, so a solution I thought of was to have a custom action that located IDriver with FindWindow, and then shut it down with SendMessage. However, I do not know the class name to Find.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
IDriver causes uninstall to hang
Started by
jonathan2002
, Sep 24 2002 10:11
3 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 24 September 2002 - 20:43
Did you install the latest HotFix ?
Stefan Krüger
InstallSite.org twitter facebook
jonathan2002
-
- Members
- 44 posts
Posted 25 September 2002 - 15:36
I've now solved the problem - it's because one of my custom actions, that executes right at the start of the uninstall, was getting stuck looking for a file that I'd removed from the installation.
It ran OK on my development PC because an old copy of that file happened to be still on there.
Switching off IDriver of course solved this by effectivly switching off the custom action. Which is why it would never have been possible to do by means of FindWindow/SendMessage, because that would have been executed by a custom action itself.
The morals of this: don't remove files from the installation without checking all the install script to see if there are any bits dependent on them; and write all file-handling code so it doesn't get stuck if the file is absent. And if uninstall gets stuck, check through the custom action code first.
It ran OK on my development PC because an old copy of that file happened to be still on there.
Switching off IDriver of course solved this by effectivly switching off the custom action. Which is why it would never have been possible to do by means of FindWindow/SendMessage, because that would have been executed by a custom action itself.
The morals of this: don't remove files from the installation without checking all the install script to see if there are any bits dependent on them; and write all file-handling code so it doesn't get stuck if the file is absent. And if uninstall gets stuck, check through the custom action code first.
philip2000
-
- Members
- 1 posts
Posted 18 January 2006 - 05:36
which processes were are you talking about
I have a toshiba running tablet pc and i discovered that disabling the idriver.exe during an install hang took care of the problem.
i would sure like to know what started the problem in the first place
how can i find out what custom action caused the problem?
(install shield 3.1 being run)
I have a toshiba running tablet pc and i discovered that disabling the idriver.exe during an install hang took care of the problem.
i would sure like to know what started the problem in the first place
how can i find out what custom action caused the problem?
(install shield 3.1 being run)