Msiexec bug in windows 7 7600

ErnieN

Distinguished
Jun 16, 2009
15
0
18,510
Here's a problem that I found. I root caused it. Please note that this post is intended for someone who actually has the ability to fix it, although some tips for working around the problem is included.

When miscrosoft installer in windows 7 64 bit build 7600 (although I think this affects all previous windows 7 64 bit builds as well), utilizes msiexec to uninstall a 32 bit program, it leaves temporary .mst files behind after uninstalling.

Normally this isn't an issue except with smart patch installers that will automatically uninstall a program and then install a patched version of the same program with the same file IDs in the same temporary folders. For example, PowerDVD 7 Ultra patches work this way.

What happens is because the .mst file is locked by msiexec during uninstall, but not removed like it should be, the installer bombs when it tries to rebuild the file because it can't overwrite the existing one.

This is especially serious because the effect is by trying to patch your application, you end up uninstalling it and then you have to reinstall. And there is a small chance the reinstall will fail and the only way to fix it is to hack the registry entries at HKLM>SOFTWARE>WOW6432Node>Microsoft>Windows>CurrentVersion>Uninstall.

A workaround where removing the temporary folder before running the patch sometimes works. But when it doesn't (like when the folder is needed to properly uninstall the program), it prevents the program from being uninstalled, and you then have to hack the registry again just to get rid of it.

This problem is not evident in Windows XP or Vista (both 32 and 64 bit) versions of msiexec. I have not checked whether or not this affects Windows 7 32 bit builds.
 
Solution
I'm a little confused why you would post that here. Bug Reports need to go to Microsoft - and you can make them via your Connect/MSDN/Technet account. They'll want the memory dump, troubleshooting steps, how to reproduce the issue, and any logs you may have made, etc etc etc.

https://connect.microsoft.com/default.aspx

Tom's Hardware has no direct association nor any input on these kinds of issues.
I'm a little confused why you would post that here. Bug Reports need to go to Microsoft - and you can make them via your Connect/MSDN/Technet account. They'll want the memory dump, troubleshooting steps, how to reproduce the issue, and any logs you may have made, etc etc etc.

https://connect.microsoft.com/default.aspx

Tom's Hardware has no direct association nor any input on these kinds of issues.
 
Solution