This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: process kill during uninstallation
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 01, 2010
02:53 AM
process kill during uninstallation
Hi all,
Suppose after installation we start a process(by running some .exe on clicking 'finish'). Some registry entry is done so to ensure running the process on restarting the system. Now on uninstallation the process continues to run even if the corresponding file is deleted from its location on target machine.
Do we have to explicitly kill the process during uninstallation?
Regards
Suppose after installation we start a process(by running some .exe on clicking 'finish'). Some registry entry is done so to ensure running the process on restarting the system. Now on uninstallation the process continues to run even if the corresponding file is deleted from its location on target machine.
Do we have to explicitly kill the process during uninstallation?
Regards
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 02, 2010
01:55 PM
correct. there is some logic in the InstallValidate standatd action that is supposed to be able to detect if any files that are scheduled to be removed are in use. it pops up a dialog prompting the user with some options regarding how to handle currently running processes.
i haven't figured out why it detects some but not others. i think it's probably best to script your own actions to make sure your design rules are followed.
i haven't figured out why it detects some but not others. i think it's probably best to script your own actions to make sure your design rules are followed.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 03, 2010
08:08 AM
thanks kelter,
only reason i can think is since the process is background with no title, it won't be included for FilesInUse.
One more thing, i wanted to put this in another thread but found this to be appropriate. so here goes my second issue...
when i set a component for permanent, i get desired result. However, when i revert this back to 'not permanent' the files remains on uninstallation in subsequent builds. i tried with old build(build after which i set the component to permanent) but those components still seem to carry this behavior of permanence.
I think windows installler store somewhere these states but don't know where and these states are not getting updated.
Regards
only reason i can think is since the process is background with no title, it won't be included for FilesInUse.
One more thing, i wanted to put this in another thread but found this to be appropriate. so here goes my second issue...
when i set a component for permanent, i get desired result. However, when i revert this back to 'not permanent' the files remains on uninstallation in subsequent builds. i tried with old build(build after which i set the component to permanent) but those components still seem to carry this behavior of permanence.
I think windows installler store somewhere these states but don't know where and these states are not getting updated.
Regards
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 03, 2010
08:54 AM
i'm gonna bet that you aren't testing on a clean machine. 🙂
you'll find those files listed here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
and the value associated with them will probably be 0x00001000 (4096).
A little background here: when you mark a file as "shared", it gets reference counted here. every time the file is installed by an application, the reference count gets incremented. every time an uninstall process thinks about removing a file, it check this key...if the file is found, it decrements the ref count. if the ref count becomes 0, the value, and the file are deleted.
when you mark a file as permanent, it sets the ref count to 4096. this is most likely what's stopping the uninstall process from removing the file. delete the values related to your files, and you should be good to go.
you'll find those files listed here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
and the value associated with them will probably be 0x00001000 (4096).
A little background here: when you mark a file as "shared", it gets reference counted here. every time the file is installed by an application, the reference count gets incremented. every time an uninstall process thinks about removing a file, it check this key...if the file is found, it decrements the ref count. if the ref count becomes 0, the value, and the file are deleted.
when you mark a file as permanent, it sets the ref count to 4096. this is most likely what's stopping the uninstall process from removing the file. delete the values related to your files, and you should be good to go.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2010
12:41 AM
that was good piece of knowledge...
sadly this still isnt helping. the enteries are deleted from the registry but the dlls and other database files still persists on target machine. the sharedDll key contains only reference count for dlls. what is the corresponding location for other files like database files?
Can you tell a good source to refer for all windows installer related technicalities?
Thanks
sadly this still isnt helping. the enteries are deleted from the registry but the dlls and other database files still persists on target machine. the sharedDll key contains only reference count for dlls. what is the corresponding location for other files like database files?
Can you tell a good source to refer for all windows installer related technicalities?
Thanks