Thanks for the PatchCleaner tool, I’ve used it a few times on Windows 7 64-bit PCs and been able to clean up several GBs. But I have noticed that after running PatchCleaner, at the next reboot, the PC spends 5-10 minutes with “applying windows updates..” or similar even though no updates have been installed recently. It seems Windows has detected some changes and needs to sort itself out.
I had a look at some of the files that PatchCleaner detected as orphans and found an msp file that was a patch for Microsoft Silverlight 5.1.50906.0. This is the version that is installed on the PC. The msp file was listed in the registry so I assume it should not be an orphan.
The msp file was listed in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\EBAC0CA45B5C319458F05B7C381184B8
"LocalPackage"="C:\Windows\Installer\f9a6409.msp"
Is this registry key (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches) being checked for MSP files? Or is there something different about Silverlight patches?
Update: I did a little more research, I found another patch listed in the registry that PatchCleaner detected as an orphan and moved.
This was listed in: [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\5DD666CF85A8B104B9E1C2BB5491238E]
"LocalPackage"="C:\Windows\Installer\722e0a.msp"
There may be more msp files listed in the registry that PatchCleaner dtected as "orphans", I haven't done an exhaustive search.
It was an Office 2010 patch (KB2956128), I used InstEd to open the msp file and see the properties. The PC had been upgraded to Office 2016, but there are still some Office 2010 components left behind, Office 2010 is still listed in "Programs and Features".
Regards,
Ian
Last edit: Ian Broadbent 2017-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did more testing, I found a batch script here https://ourrick.wordpress.com/2015/04/04/find-orphaned-installer-files-in-cwindowsinstaller-folder/ which also does a detection for orphaned msi files by checking the ."HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches" key.
On a Windows 7 x64 PC with 492 msi and msp files in the C:\Windows\Installer directory, I ran the script and it found 492 files, but all of them had entries in the registry.
On the same PC, PatchCleaner reported 285 files still used and 271 files "orphaned" (a total of 556 !) , but every "orphaned" file reported by PatchCleaner I searched for WAS present in the registry. So I'm not sure how PatchCleaner is detecting orphans.
Last edit: Ian Broadbent 2017-10-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I realise this is 2 years after you posted that, but you should know that batch script you linked has some MAJOR issues. I sent a comment to the creator of that script with the fixes. Luckily his script doesn't delete anything by default, and also seems to be bugged to the point of thinking all files in the installer folder are not orphaned.
Attached to this message is my reply to him in case he never applies the fixes.
Also attached is a script i made after trying to fix the original script.
Yes, PatchCleaner is not fool proof. I created it originally for my own use and personally have only had issues with Adobe Reader. As you can see on this discussion board, someone has identified potential issues with Office 2010 updates, and one particular update for Silverlight seemed to have issues, although I have not experienced these myself.
The product is clear that it is not 100% perfect and to use at your own risk, hence the provision of the move feature, which I recommend as the preferred approach. Obviously I would like this to work 100% so, I am not discounting the issues you have, and am thinking of ways to improve and build work arounds to the issues encountered.
I have not used the registry at this point, but believe this vbs file will be essentially reading the same or similar values to the registry.
Since reading your post I have looked at the registry and done some basic spot checking (not complete but a random sample) have found that PatchCleaner is reporting what is recorded in the registry.. read point 2 below
Here are some possible reasons for the differences in the counts:
Patch cleanear shows both msi and msp files, so the original installers or "Products" are included in the counts, not just the patches, hence why PatchCleaners numbers may be higher.
Yes the patch files are in the registry. But you need to look in the "Products" registry key and then for a particular product expand the patches sub-key. In here you will see all the patches for a product and you will notice a sub-key of "State". Now I have never looked at this until today but on cross checking against the results of patch cleaner I can sumise:
state 1 = Active
state: 2 = InActive
An inactive patch means that it is no longer being used and is therefore orphaned.
Could you confirm that status of the patch you think is not orphaned as I suspect the registry will be recording that it is no longer active and therefore not required.
Looking at this registry data it would be possible to enhance PatchCleaner with more information about the patch itself from the registry and when I get some time I will write some code to cross check the registry vs the vbs file approach and see if there are any differences. Ultimately I may be able to re-code to use the registry as opposed to the VBS file approach to allow you to exclude by product, so I could exclude Adobe Acrobat and Silverlight and that way never detect any of their patches as orphaned.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the explanation about how the cleanup works (i.e. the Product key, I'm understanding more of it now.
I ran the VBS script you mentioned; on one PC that has 475 msi and msp files, the script listed 88 files to keep, but only 54 were unique after I noticed some filenames were duplicated. PatchCleaner reported 173 files in use and 336 files orphaned. So looks like there is some difference between the VB Script method and PatchCleaner's. (I feel more confident in PatchCleaner given that it proposed more files to keep)
As for the Silverlight patch I mentioned in my earlier patch, I couldn't find the "EBAC0CA45B5C319458F05B7C381184B8" string in the "Products" section, so I assume that is an orphan.
Will test on more PCs.
regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the PatchCleaner tool, I’ve used it a few times on Windows 7 64-bit PCs and been able to clean up several GBs. But I have noticed that after running PatchCleaner, at the next reboot, the PC spends 5-10 minutes with “applying windows updates..” or similar even though no updates have been installed recently. It seems Windows has detected some changes and needs to sort itself out.
I had a look at some of the files that PatchCleaner detected as orphans and found an msp file that was a patch for Microsoft Silverlight 5.1.50906.0. This is the version that is installed on the PC. The msp file was listed in the registry so I assume it should not be an orphan.
The msp file was listed in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\EBAC0CA45B5C319458F05B7C381184B8
"LocalPackage"="C:\Windows\Installer\f9a6409.msp"
Is this registry key (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches) being checked for MSP files? Or is there something different about Silverlight patches?
Update: I did a little more research, I found another patch listed in the registry that PatchCleaner detected as an orphan and moved.
This was listed in:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\5DD666CF85A8B104B9E1C2BB5491238E]
"LocalPackage"="C:\Windows\Installer\722e0a.msp"
There may be more msp files listed in the registry that PatchCleaner dtected as "orphans", I haven't done an exhaustive search.
It was an Office 2010 patch (KB2956128), I used InstEd to open the msp file and see the properties. The PC had been upgraded to Office 2016, but there are still some Office 2010 components left behind, Office 2010 is still listed in "Programs and Features".
Regards,
Ian
Last edit: Ian Broadbent 2017-10-02
I did more testing, I found a batch script here https://ourrick.wordpress.com/2015/04/04/find-orphaned-installer-files-in-cwindowsinstaller-folder/ which also does a detection for orphaned msi files by checking the ."HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches" key.
On a Windows 7 x64 PC with 492 msi and msp files in the C:\Windows\Installer directory, I ran the script and it found 492 files, but all of them had entries in the registry.
On the same PC, PatchCleaner reported 285 files still used and 271 files "orphaned" (a total of 556 !) , but every "orphaned" file reported by PatchCleaner I searched for WAS present in the registry. So I'm not sure how PatchCleaner is detecting orphans.
Last edit: Ian Broadbent 2017-10-03
I realise this is 2 years after you posted that, but you should know that batch script you linked has some MAJOR issues. I sent a comment to the creator of that script with the fixes. Luckily his script doesn't delete anything by default, and also seems to be bugged to the point of thinking all files in the installer folder are not orphaned.
Attached to this message is my reply to him in case he never applies the fixes.
Also attached is a script i made after trying to fix the original script.
Last edit: FocusedWolf 2019-12-15
Hi Ian,
Yes, PatchCleaner is not fool proof. I created it originally for my own use and personally have only had issues with Adobe Reader. As you can see on this discussion board, someone has identified potential issues with Office 2010 updates, and one particular update for Silverlight seemed to have issues, although I have not experienced these myself.
The product is clear that it is not 100% perfect and to use at your own risk, hence the provision of the move feature, which I recommend as the preferred approach. Obviously I would like this to work 100% so, I am not discounting the issues you have, and am thinking of ways to improve and build work arounds to the issues encountered.
PatchCleaner uses a vbs approach similar to that provided on this article to detect orphaned files.
https://www.raymond.cc/blog/safely-delete-unused-msi-and-mst-files-from-windows-installer-folder/
It uses this vbScript to create a list of products and patches, and then uses this to cross check the installer folder to determine orphans.
I have not used the registry at this point, but believe this vbs file will be essentially reading the same or similar values to the registry.
Since reading your post I have looked at the registry and done some basic spot checking (not complete but a random sample) have found that PatchCleaner is reporting what is recorded in the registry.. read point 2 below
Here are some possible reasons for the differences in the counts:
Patch cleanear shows both msi and msp files, so the original installers or "Products" are included in the counts, not just the patches, hence why PatchCleaners numbers may be higher.
Yes the patch files are in the registry. But you need to look in the "Products" registry key and then for a particular product expand the patches sub-key. In here you will see all the patches for a product and you will notice a sub-key of "State". Now I have never looked at this until today but on cross checking against the results of patch cleaner I can sumise:
An inactive patch means that it is no longer being used and is therefore orphaned.
Could you confirm that status of the patch you think is not orphaned as I suspect the registry will be recording that it is no longer active and therefore not required.
Looking at this registry data it would be possible to enhance PatchCleaner with more information about the patch itself from the registry and when I get some time I will write some code to cross check the registry vs the vbs file approach and see if there are any differences. Ultimately I may be able to re-code to use the registry as opposed to the VBS file approach to allow you to exclude by product, so I could exclude Adobe Acrobat and Silverlight and that way never detect any of their patches as orphaned.
Cheers
Thanks for the explanation about how the cleanup works (i.e. the Product key, I'm understanding more of it now.
I ran the VBS script you mentioned; on one PC that has 475 msi and msp files, the script listed 88 files to keep, but only 54 were unique after I noticed some filenames were duplicated. PatchCleaner reported 173 files in use and 336 files orphaned. So looks like there is some difference between the VB Script method and PatchCleaner's. (I feel more confident in PatchCleaner given that it proposed more files to keep)
As for the Silverlight patch I mentioned in my earlier patch, I couldn't find the "EBAC0CA45B5C319458F05B7C381184B8" string in the "Products" section, so I assume that is an orphan.
Will test on more PCs.
regards,