Files not removed at uninstall - strange problem.

[klilleng]

Hi!

I have a "strange" problem.

Situation:

I install my .msi package. All well.
I uninstall it. All well.

I then manually copy some old files to the installation directory, and install the .msi package. The old files are replaces by the newer ones. All well.

HOWEVER, when I uninstall the package, these (newer) files are not removed!

Why does it matter that there was some older files in the directory before install?

And how to resolve this issue?

[cbragg]

The file will only remove if it is included in the package. I did not think it did this but at a guess, although yours appears to be the same, it is infact different based on the file hash.

But whatever the reason is, I would suggest you just add a removefile entry for the files. Although a more prettier solution in the first place would be to create an upgrade for the new files.

[ChristopheOce]

Hi,

If you want a document who describe how to use the remove file table, here is it (PDF):

http://www.macrovision.com/webdocuments/product_data.pdf

Have a nice day
Christophe

[klilleng]

Thank you for the replies.

Unfortunately, this does not seem to work.



I first manually copy some files into the installdir.

Then, i use the .msi installer. All the existing files are overwritten with the files from the .msi package. I have set the REINSTALLMODE to amus for this test.

However, when I uninstall the .msi package, the files are not removed. They are still there. It seems that only the files belonging to the component key file (that existed before install) remains. Other files are removed correctly.

I have tried the RemoveFile table, with both *.* and specified file name. It does not seem to do anything.


If the installation directory is removed/empty before install, all files are removed correctly.


Is there a way to completely, forcibly remove the installation directory?

Or, a way to instruct a certain component to please remove all its files at uninstall, regardless of any strange things it might encounter during install..? :confused:

[KathyMorey]

Are the files versioned? Are the components marked as "shared" (which is the default) or "permanent"? Have you tried logging the uninstall to see why they are not being removed?

[ChristopheOce]

Hi,

One of your package (basic msi project) has the same thing !

I don't know why but sometimes and on some machine, when i remove my package some file still on the computer, exe, xml and so on !

For to resolve this problem, i have create a custom action in installscript who gets the path where the product is installed and delete all file and folders when i remove the product of course !

On installscript there is a function :

DeleteDir( path, paramInstallShield);

You must to fire the custom action when the product is remove, then the condition will be :

REMOVE= "ALL"

or perhpas try to reboot your pc at the end of installation ?
perhpas some file are locked by something !?

Have a nice day
Christophe

[peterbi]

Hi,

I am using RemoveTable to clean up the folder(s) at uninstallation. All works except two sub folders: each of them still has a file(s) remained undeleted after uninstallation, thus causing their parent and grand parent folders remained. I used "*" as FileName for the parent (and grand parent) folders, hoping it will clean up anything in the folder and it's sub folders, but I still need to add entries for the two subfolders that still have files after uninstallation. Obviously that RemoveFile works for lots of other files in the same subfolders since the specifed subfolders contain lots of files each. Is that because the remained files are special (if so, how can I check what's that) or that's a normal MSI behavior?

Once I added the entries for the two subfolders with the proper FileName patterns (eg. *.InstallLog), the folder are cleaned after uninstall. But I am worrying if there might be some other user (client) created files that will cause the same problems in the future.

Any help is greatly appreciated,
Peter

[#8]

Perhaps you should take a step back and instead try to determine the cause of the files not being removed. While wantonly blowing away files that you know are ok to blow away isn't always the worst thing to do, it does cause issues later on if you decide to perform various types of upgrades.

Have you tried logging the uninstallation to determine what's going on?

For more information on creating an MSI log file, please reference this article:
http://support.installshield.com/kb/view.asp?articleid=Q104807

You should look for instances of words PreviouslyPinned and Disallowing. Those will give you a better idea of what's going on.

[peterbi]

Thanks for the reply.

I created a uninstall log file, and found the following with 'Disallowing' key word search:

...
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {D93EBF7D-1D53-11D4-A53C-0090278A1BB8} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {FC3E0B6A-F62B-11D1-B144-00C04F990B2B} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {FC3E0B6A-F62B-11D1-B144-00C04F990B2B} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {997FA962-E067-11D1-9396-00A0C90F27F9} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {997FA962-E067-11D1-9396-00A0C90F27F9} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {474F61F1-7342-11D2-A199-00A0C90AB50F} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {474F61F1-7342-11D2-A199-00A0C90AB50F} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {10048713-2C96-11D2-9A97-006097C4E452} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {10048713-2C96-11D2-9A97-006097C4E452} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {BF4D7A70-D89D-11D1-A17D-00A0C90AB50F} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {BF4D7A70-D89D-11D1-A17D-00A0C90AB50F} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {1D2B754A-CD9A-11D1-8279-00C04FC21633} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {1D2B754A-CD9A-11D1-8279-00C04FC21633} since another client exists

MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {A8A1495F-36E5-11D2-B15A-00C04F990B2B} since another client exists
MSI (s) (B4:C4) [10:06:42:437]: Disallowing uninstallation of component: {A8A1495F-36E5-11D2-B15A-00C04F990B2B} since another client exists

MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {22056900-C842-11D1-A0DD-00A0C9054277} since another client exists
MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {22056900-C842-11D1-A0DD-00A0C9054277} since another client exists

MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {3207D1B8-80E5-11D2-B95D-006097C4DE24} since another client exists
MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {3207D1B8-80E5-11D2-B95D-006097C4DE24} since another client exists

MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {FC3E0B6E-F62B-11D1-B144-00C04F990B2B} since another client exists
MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {FC3E0B6E-F62B-11D1-B144-00C04F990B2B} since another client exists

MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {3207D1B1-80E5-11D2-B95D-006097C4DE24} since another client exists
MSI (s) (B4:C4) [10:06:42:453]: Disallowing uninstallation of component: {3207D1B1-80E5-11D2-B95D-006097C4DE24} since another client exists


MSI (s) (B4:C4) [10:06:42:843]: Skipping action: SetARPINSTALLLOCATION (condition is false)
MSI (s) (B4:C4) [10:06:42:843]: Doing action: SetODBCFolders
Action ended 10:06:42: CostFinalize. Return value 1.
MSI (s) (B4:C4) [10:06:42:843]: Note: 1: 2205 2: 3: ODBCDriver
...

But when I tried to find the components from Component table with the GUIDs in the list, I couldn't find the GUIDs! So I used the GUIDs to search the log file, and then got the list with 'PreviouslyPinned' key word:


MSI (s) (64:50) [10:28:59:156]: Executing op: ComponentUnregister(ComponentId={3207D1B1-80E5-11D2-B95D-006097C4DE24},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={FC3E0B6E-F62B-11D1-B144-00C04F990B2B},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={3207D1B8-80E5-11D2-B95D-006097C4DE24},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={22056900-C842-11D1-A0DD-00A0C9054277},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={A8A1495F-36E5-11D2-B15A-00C04F990B2B},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={1D2B754A-CD9A-11D1-8279-00C04FC21633},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={BF4D7A70-D89D-11D1-A17D-00A0C90AB50F},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={10048713-2C96-11D2-9A97-006097C4E452},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={474F61F1-7342-11D2-A199-00A0C90AB50F},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={997FA962-E067-11D1-9396-00A0C90F27F9},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={FC3E0B6A-F62B-11D1-B144-00C04F990B2B},,BinaryType=0,PreviouslyPinned=1)
MSI (s) (64:50) [10:28:59:171]: Executing op: ComponentUnregister(ComponentId={D93EBF7D-1D53-11D4-A53C-0090278A1BB8},,BinaryType=0,PreviouslyPinned=1)

And finally the following:


MSI (s) (64:50) [10:29:01:796]: Executing op: RegClassInfoUnregister(Feature=BSM,Component={997FA962-E067-11D1-9396-00A0C90F27F9},,ClsId={00020424-0000-0000-C000-000000000046},,,Description=PSOAInterface,Context=InprocServer32,,,,,,,,,)
MSI (s) (64:50) [10:29:01:796]: Executing op: RegClassInfoUnregister(Feature=BSM,Component={997FA962-E067-11D1-9396-00A0C90F27F9},,ClsId={00020420-0000-0000-C000-000000000046},,,Description=PSDispatch,Context=InprocServer32,,,,,,,,,)
MSI (s) (64:50) [10:29:01:796]: Executing op: RegClassInfoUnregister(Feature=BSM,Component={FC3E0B6E-F62B-11D1-B144-00C04F990B2B},,ClsId={F9043C85-F6F2-101A-A3C9-08002B2F49FB},ProgId=MSComDlg.CommonDialog.1,VIProgId=MSComDlg.CommonDialog,Description=Microsoft Common Dialog Control, version 6.0,Context=InprocServer32,,,,,,,,,)
MSI (s) (64:50) [10:29:01:796]: Executing op: RegClassInfoUnregister(Feature=BSM,Component={FC3E0B6E-F62B-11D1-B144-00C04F990B2B},,ClsId={7629CFA2-3FE5-101B-A3C9-08002B2F49FB},,,Description=Common Dialog Open Property Page Object,Context=InprocServer32,,,,,,,,,)
MSI (s) (64:50) [10:29:01:812]: Executing op: RegClassInfoUnregister(Feature=BSM,Component={FC3E0B6E-F62B-11D1-B144-00C04F990B2B},,ClsId={7629CFA4-3FE5-101B-A3C9-08002B2F49FB},,,Description=Common Dialog Color Property Page Object,Context=InprocServer32,,,,,,,,,)

I guess we (or IS?) have some components registered in the registry, but the last two lists seem to unregister them ok (if I understand correctly). Otherwise, I need to know what's the reason it says "another client exists", does it mean that the files (components) are being used?


Weired enough, I used the names of the left over files (only couple of them are left after uninstallation), and couldn't find them in the log file, which mean I have no hint why they are left there after uninstallation.

Any idea?

Thanks,
Peter

[#10]

Client in that log file line indeed refers to another Component on the system.

The PreviouslyPinned=1 indicates that you likely have a share count in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs for the keyfile of those components.

You might just want to clean out this machine and test from scratch if this is a machine that's been tested or used extensively in the past.

[Korben_Dallas]

I'm getting the exact same issue on my installer. I'm using IS2008.

Certain files in the Windows/System32 folder are left uninstalled.
In the log file I also see the "since another client exists" and the "PreviouslyPinned=1" entries.

How can I solve this?
The components of these files have destination set to [SystemFolder] property. I tried setting them as Shared=Yes and No and didn't make a difference. None are set as "Permanent".

These files are never removed. How did you solve this?

[Korben_Dallas]

Any ideas?

Thanks

[Korben_Dallas]

Please Help :confused:

[#14]

The component table documents why you're seeing this issue:
http://msdn.microsoft.com/en-us/library/aa368007.aspx

[Korben_Dallas]

What should I be looking for in the components table?

The GUID is in uppercase as it's suppose to be.

In the Directory table however, most of the folders have the ParentDir set as TARGETDIR.

Should the [SystemFolder] parent dir be TARGETDIR???


PS: This problem also occurs on a new Installer I've created recently, so it seems to affect EVERY project I create.

[Korben_Dallas]

Any ideas? 😞

I think I just might use a vbs to remove the files using a condition REMOVE=ALL cause I can't find any other way!