Roughly a month ago, VMware released a new major version of its Workstation (and Fusion) software (i.e. 7.0 (and 3.0, respectively)). So, it seemed like a good time to upgrade from version 6.5.3. Past protocol suggested the following approach: uninstall old, reboot, and install new. Unfortunately, and unexpectedly, this approach failed to result in an up-to-date Workstation installation.
Shortly after launching VMware-workstation-full-7.0.0-203739.exe, the installer presented:
Clicking the Uninstall button resulted in a second cryptic dialog being presented:
“The MSI ” failed.” seems to be a fairly unique phrase, especially when combined with VMware, etc.; so, I Googled to see what others had encountered. Suffice it to say that I found nothing that ultimately solved my installation issue–although I was able to reclaim over 9 GB of free space by running CCleaner, thanks to one post.
So, I confirmed that my host operating system is supported by VMware Workstation 7.0. I further confirmed that my Windows file system and registry were both clean of VMware-related content–rebooting after this confirmation. Nada.
Sometimes I’ve seen installers insist on being the party to uninstall older software. Since I’d uninstalled VMware Workstation 6.5.3 myself, I tried to reinstall the older software, reboot my host OS, and retry installing VMware Workstation 7.0:
In hindsight, I could have seen that this wouldn’t resolve anything, but I clicked Uninstall as before…only to end up with the failed mystery MSI dialog once more.
So, I tracked down where VMware Workstation 7 wrote its installation logs: %TEMP%\vmware_*.log. I re-ran the installer to arrive back at the top state above, allowing me to recognize the associated log file and examine its state at the point of presenting the uninstall panel:
20091128194313:INFO CGetMSIStateOperation::Execute: Examining the system for VMware Workstation.msi
20091128194313:INFO CGetMSIStateOperation::Execute: MSI Data ProductCode: {A3FF5CB2-FB35-4658-8751-9EDE1D65B3AA}, PackageCode: {CDA82EA5-329A-428D-8ED3-9857244767DE}, UpgradeCode: {14F539F3-C4A4-4597-A29D-8C1D753ACC93} , Version: 7.0.0.9911
20091128194313:ERROR** CGetMSIStateOperation::GetSysVersionString: ::MsiGetProductInfo failed to retrieve the version string for {{98D1A713-438C-4A23-8AB6-41B37C4A2D47}} due to error: 1605
20091128194313:INFO CGetMSIStateOperation::Execute: Installed MSI Data ProductCode: {98D1A713-438C-4A23-8AB6-41B37C4A2D47}, Version:
20091128194313:INFO CGetMSIStateOperation::Execute: Default MSI Action: upgrade, Details: cross product
20091128194313:INFO CBootstrapCmd::RunOperation: Operation 'GetMSIState' completed successfully with return code 65539
20091128194313:INFO upgrade
20091128194313:INFO cross product
20091128194313:INFO CGetMSIStateOperation::Execute: Examining the system for
20091128194313:INFO CGetMSIStateOperation::Execute: MSI Data ProductCode: {233A935E-6132-48B2-840F-37C9D32555D5}, PackageCode: {46F73961-902A-4A20-BB36-5060DC6ACB2C}, UpgradeCode: {2A0F937B-3E75-47D8-9306-14D45CC0F756} , Version: 4.0.0.0
20091128194313:INFO CGetMSIStateOperation::Execute: Default MSI Action: install, Details:
20091128194313:INFO CBootstrapCmd::RunOperation: Operation 'GetMSIState' completed successfully with return code 65539
20091128194313:INFO install
20091128194313:INFO SaveSetting: Wrote setting 'action', value 'upgrade'
20091128194313:INFO
20091128194313:INFO
20091128194313:INFO {98D1A713-438C-4A23-8AB6-41B37C4A2D47}
20091128194313:INFO SaveSetting: Wrote setting '{98D1A713-438C-4A23-8AB6-41B37C4A2D47}', value ';'
20091128194313:INFO {98D1A713-438C-4A23-8AB6-41B37C4A2D47}
Right away, I could see that the installer was recognizing an unexpected upgrade state rather than the expected “fresh” install state. Fortunately, the log also captured more details behind this divergent recognition: “failed to retrieve the version string for {{98D1A713-438C-4A23-8AB6-41B37C4A2D47}} due to error: 1605.” First of all, this log statement is a bit of an oxymoron, since Windows error code 1605 (ERROR_UNKNOWN_PRODUCT) means “This action is only valid for products that are currently installed.” That is, if the product isn’t installed, then shouldn’t the current installer be “happy?” Second, this error led to the sparse dialogs (i.e. ” (Version: )” and “The MSI ”failed.”).
Again in hindsight, I could have Googled the suspect GUID to determine its relationship with VMware Workstation 5.5. However, I went back to my Windows Registry to perform additional forensics first. The first RegDB reference I found is associated with Windows’ ARP Cache, which has to do with Windows’ TCP/IP stack (i.e. needs to be left intact). I did find another RegDB key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders, with a value named C:\WINDOWS\Installer\{98D1A713-438C-4A23-8AB6-41B37C4A2D47}\, which I removed. Nevertheless, after rebooting, I was still unable to install VMware Workstation 7.0
So, I thought that if my 6.5.3-based hack appeared to have some merit, perhaps a similar, 5.5-based hack could, too. First I had to download the 5.5.9 installer and unearth my version 5.5 license key. With these in hand, I installed VMware Workstation 5.5.9 and then rebooted my host OS as directed.
Following reboot, I re-ran the VMware Workstation 7.0 installer, yet again:
This time, after clicking Uninstall, I was eventually presented with the ability to proceed with installing the new software. After choosing to reboot at the end of the installation process and rebooting, I’m able to run VMware Workstation 7 as I originally expected.
Hopefully this knowledge sharing will help you to avoid the wasted time and energy I experienced. At least that’s my purpose in posting. Cheers…
Craighttp://craigrandall.net/
Twitter: @craigsmusings
Hi Craig !
I’m facing the same problem, and I’m trying to solve it using your method, so while I’m writing this, I’m also installing VMWare 6.0 so that VMware 7.0 can installer remove it..
I’ll keep you informed if this works for me …
Many thanks !
Cristian
Santiago, Chile.
Hi Cristian. Thanks for sharing. I hope that the above does indeed help you, and I’ll look for your update. Cheers…
Hi again!!!
Ok, I’ve tried all above, but no help. The error remains.
So I’ve made some research, folowwing your tip on the log file. Then I’ve found that VMWare couldn’t retrieve product information correctly for product code {xxx}. Then I remembered that some time ago I had the same problem with another software, and another product code, and I used a software (from MS) called MSIZAP. So I downloaded it again. and ran it with the failed product code referenced in log file.
C:\>msizap.exe TP! {98D1A713-438C-4A23-8AB6-41B37C4A2D47}
Then all orphaned installation information left for this product code went away and now I can install without problems.
I hope this helps somebody, or maybe helps you when having similar problems.
Cheers!
Cristian Meneses A.
Santiago – Chile
Thanks for sharing. It makes sense that the Windows Registry (RegDB) is involved, since the file system showed “all clean” in my case. Windows Installer (MSIEXEC.EXE) leverages RegDB for persistence. While I have yet to use MSIZAP, I have used other, similar tools.
I just heard about the significant earthquake about 200 miles SW of Santiago, Chile. Hope that you’re OK.
Thank you Craig, your solution saved me from continued frustration
As per VMware KB, I had tried cleans, manual removal of drivers, files etc, all without success.
For myself the installer was getting hung up on the uninstallation of the similarly useful “(Version:)” – which I determined to be an early version of VMplayer 1. Fortunately I retained a copy of the MSI from 2006 and was able to install then uninstall to clear out the mess.
I would not have not considered such a plan without your success story. Many thanks.
@Bod- I’m glad that you were helped by this post. Thanks for sharing.
Hi Craig – I m glad to c your post,,,,,,,,,,,,
m also having same problem, I wannt to install workstatn 7 so i tried to uninstall the previour version, but i cud’nt do it, so i googled the problm, while searching in my registry I deleted some entries, so when I again tried to uninstall workstatn then it started showing me “MSI failed”,,,,,
when i manualy tried to uninstall it using control panel ,it strtd askn me abt the location of MSI and giving me the error message”THE INSTALLATION SOURCE FOR THIS PRODUCT IS NOT AVAILABLE. VERIFY THE SOURCE EXITS ANND THEN YOU CAN ACCESS IT.
I tried the method which was used by bod i.e. run MSIZAP with the fault entr of registry ,I think MSIZAP file was corrupted, but i cudnt find it anywhere else,,,,,,,,,,
plz help me out i wnt to install wrkstatn 7, my whole work is pndng,,,,,,,,,,,,
thnx
Dinesh
Just finished 2 hours of uninstalling an – unsopported – version of VMWare 5.5 from Windows7. I first followed the instructions here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1308
but then got stuck with the – The MSI “” failed – problem. Thankfully I found your post and MSIZAP did the trick for me!
@Dinesh- If you no longer have the original MSI package to relate, you should be able to visit the VMware product archives to locate the older, missing version and realize the MSI from within the source EXE.