Craig’s Musings

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…

Craig
http://craigrandall.net/
Twitter: @craigsmusings