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/
@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.
I had similar troubles with VMWare Player except I couldn’t track down what it was trying to uninstall. What I did was run some uninstaller software (revo uninstaller) which will read the uninstaller and delete what it didn’t. Basically this cleared out the directories and most of the registry bindings. After that I ran a VMWare cleanup script. There was still no success after that. However I think the two did progress everything somewhat.
Lastly I visited the log file Craig outlined and found the GUID of the program it was trying to remove. Simply searched and removed about 3 or 4 entries in the registry. I started up the program had still told me it wanted to uninstall ”. Hm. But this time it had went through. Guess that did the trick.
@Mike- It’s true that ‘with a GUID, much can be accomplished in RegDB.’
Unfortunately, the Windows Registry is a fickle entity; so, one small edit done incorrectly can cause one a ton of pain.
Hi Craig,
I know that this is an old post but I just wanted to say that through a bizarre series of events I experienced the same issue earlier today and wanted to thank you for this post which I found to be probably the most helpful one on the internet when trying to deal with the issue.
The bizarre series of events included a BSOD during the uninstall process of the VMWare 7.1 software which on reboot resulted in the error message you show at the start of your post.
I was however able to find an alternate way of resolving the problem and that was simply the deletion of the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.
The deletion of this key and it’s sub-keys removes all of the installation parameters the install checks for on start up thus stopping the not very helpful MSI ” failed error message.
Once deleted I was able to run the VMWare 7.1 installer and re-install the software, during the re-install the package noted a number of issues and self-resolved them, once the software was re-installed I was asked to reboot at which point I could uninstall and revert back to the 6.5 software.
This was using the VMware-workstation-full-7.1.2-301548 software package so for earlier versions I can not say whether or not it will work but it is certainly worth attempting as it makes the process very simple.
Again thank you for all of your initial trouble-shooting into the problem.
@ TheB1GDude- Happy to be of some assistance, and thank you for sharing your insights, too. In general, I advise folks to avoid hand-editing the Windows Registry, but if you know what you’re doing (as you do), it can indeed be a shorter route to certain solutions. Cheers…
Thanks, Craig.
Thanks for your post, I got a clue. I was able to install it successfully.
1. Backup Registry
2. Delete HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.
3. Search “tools-*” in HKEY_CLASSES_ROOT\Installer\Products\
4. Delete each CLSD that belongs to “tools-**.exe”
5. Install Vmware 7.1.x
That’s all.
@jack2011- Glad that you’re up and running now. Thanks for sharing your success.
Confirmed. (In my case…) Use the 7.1.2 installer.
Apparently the 7.1.4 installer is not as good, no matter what I tried I’d still get the same errors with the 7.1.4 installer, even after using MSIZAP
Hi, guys!
TheB1GDude and Craig Randall first of all thank you!!!
I had the same problem with MSI installer after uninstall.
I tried all mentioned ways including msizap but no luck, finally I tried to remove HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc. – and then I installed 5.99 older version and then after reboot I used 8 workstation installer to uninstall 5.9.9. and this worked perfectly well no I go the recent 8.01 version of vmware thanks to you guys.
Cheers and happy holidays!
@Proxx- Glad that your problem is resolved. As I mentioned above, editing the Windows Registry is generally not recommended, and deleting this particular registry key can affect other VMware products that may be installed (i.e. other than Workstation). Happy New Year!