VMware Communities
msschmitt
Enthusiast
Enthusiast
Jump to solution

Problem downloading VMware Tools

I'm running VMware Workstation 12 Pro (12.1.1 build-3770994) on Windows 7. Each time I start VMware Workstation and then start up a VM, a Software Updates window opens:

"The following software is available for download: VMware Tools for WIndows 2000 or later - version 10.0.6".

If I click the Download and Install button, it goes through the downloading and verifying phases, but fails on the Updating phase, which a generic error:

"There was a problem updating a software component. Try again later and if the problem persists, contact VMware Support or your system administrator."

The only error details I can find is in the ui log:

2016-05-09T16:24:20.689-05:00| vmui| I125: VMUICOM error: hr = 0x80004005, (null)

2016-05-09T16:24:20.689-05:00| vmui| W115: wui::ExecuteToolsISOInstall: Failed to install VMware-

tools-windows-10.0.6-3595377.iso: COM routine failed

2016-05-09T16:24:20.689-05:00| vmui| I125: CDS: CdsInstallProgress: Installing bulletin a3196322-

fce0-49ee-abbf-18d43e91e39d

2016-05-09T16:24:20.689-05:00| vmui| I125: CDS: CdsInstallProgress: Install for bulletin a3196322-

fce0-49ee-abbf-18d43e91e39d returned installerStatus 3, exitCode 0

2016-05-09T16:24:20.747-05:00| vmui| I125: DlgUI: There was a problem updating a software component.

Try again later and if the problem persists, contact VMware Support or your system administrator.

I can't find any explanation of VMUICOM error 0x80004005.

Note that this error was occurring before before the 12.1.1 update, and is still occurring.

I think the tools build it currently has is 10.0.1.357.

Any idea how to fix this?

Reply
0 Kudos
1 Solution

Accepted Solutions
msschmitt
Enthusiast
Enthusiast
Jump to solution

It turns out that the problem was caused by McAfee Host Intrusion Prevention 8 running on the host. This is the firewall component, not the anti-virus component.

Part of the intrusion detection is "VMware Workstation Shielding - File Modification". Presumably it has some bad signatures, because it is considering any attempt to alter the VMware Tools .iso files as an attack.  This includes:

  • VMware installation launcher, such as when VMware is upgrading itself
  • Windows installer run by the system, such as when VMware is attempting to download and install new tools
  • User attempting to delete or rename the files

So the tools .iso files are frozen in time: they can't be changed even by a complete uninstall and reinstall of VMware Workstation, let alone a version upgrade.

The surprising thing here is that a file modification is being blocked by HIP, which is far beyond what you'd normally expect from a firewall.  That's why it took me so long to realize it was the root cause.

The work around is to unlock the HIP interface and then temporarily turn off Host IPS in the IPS Policy. While IPS is off you can proceed with the VMware Workstation or tools upgrade, then turn IPS back on.

The permanent fix would be to get McAfee to fix the HIP signature. There are release notes that say that this isn't the first time the VMware Workstation Shielding feature has had false positives.

View solution in original post

Reply
0 Kudos
11 Replies
wila
Immortal
Immortal
Jump to solution

Hello,


The error 0x80004005 is typically one of those cryptic Microsoft errors.

In this case 0x80004005 stands for:

- "unspecified error" (from COM Error Codes (Generic) (COM)  or also https://msdn.microsoft.com/en-us/library/cc704587.aspx )

Which is a classic case of "very helpful", but not really.

You could try to download and install the update by hand, the tools can be downloaded here:

https://softwareupdate.vmware.com/cds/vmw-desktop/ws/12.1.1/3770994/windows/packages/

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
msschmitt
Enthusiast
Enthusiast
Jump to solution

The download is just the .iso file and a descriptor file. I don't see anywhere in VMware Workstation to import it into the installation. The other tools .iso files are in a set of download folders; it looks like VMware is registering them internally somewhere.

Do you mean to manually use the .iso to install the tools into each VM? Won't VMware still want to download the tools since the last downloaded .iso is older than what the server says is current?

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

You can probably just can get the .iso file and put it in the VMware Workstation main folder, but I saw now that you are looking for a "windows 2000 and later" version.

When I saw windows 2000, I thought it was only the VMware Tools installer for an older Windows version that you were after.

My apologies for not reading well.

The .iso file is there as well, but there's also an alternative download in that case:

CDS Repository - /var/www/public/stage/session-98/cds/vmw-desktop/ws/12.1.1/3770994/windows/core

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
msschmitt
Enthusiast
Enthusiast
Jump to solution

The last link appears to be to the actual VMware Workstation installer, for the build that I already have.

I see that "C:\Program Files (x86)\VMware\VMware Workstation" contains a windows.iso. So it looks like "You can probably just can get the .iso file and put it in the VMware Workstation main folder" means that I could replace this windows.iso with the downloaded file, named the same.

But there's a problem: when I try to rename windows.iso in this folder (prior to replacing it), Windows is throwing an error:

File Access Denied

You need permission to perform this action

You require permission from SYSTEM to make changes to this file

This error is thrown for changes to anything in this folder. Which is weird, because UAC is off, I'm an administrator, and the security rules give full control to anyone in the Adminstrators group. Displaying effective permissions for me shows I have full control. So I'm at a loss for why I'm blocked here.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

Looks like it indeed is the windows installer. It has been a while since I ran anything from those URLs, in the past they did put some of their .iso's in a self executable extractor and with the exe being the size of the windows.iso file.. I ended up with an erroneous conclusion.

Guess no self extracting iso files anymore, good.

As for renaming, I just tried renaming the windows.iso file on my local Workstation 12.1 install here and it did let me after a warning to need administrator rights and UAC prompt.

It is fine that the SYSTEM account has set credentials on the iso file, but it should not have ownership on it, have you tried taking ownership of the iso file?

This might also be the reason your installer can't put the new file there.

PS: I renamed the file with VMware Workstation shut down.

PS2: As this is windows and windows has a thing with needing reboots for "files in use" .. have you tried to reboot the host already?

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
msschmitt
Enthusiast
Enthusiast
Jump to solution

I tried the following:

  1. Completely uninstalled VMware Workstation. The result was that only the WMware Workstation folder and the .isos remained.
  2. Change ownership of that folder and all sub-objects to me.
  3. Deleted it.
  4. Reinstall VMware Workstation.
  5. Update to 12.1.1.
  6. Open a VM.

The result was the same problem: it can't update the .iso's in its own folder.

This has to be a bug in VMware Workstation 12; I never had any problems before this.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

I'm afraid it is local to your install, if not a lot more people would complain about this issue.

Your attempt to manually remove the current install, while it did remove most, did not remove some of the config.. and that is where your problem most likely originates.

See for manually removing an install this KB article:

Cleaning up after an incomplete uninstallation on a Windows host (1308) | VMware KB

Besides clearing out the registry settings you also missed clearing out:

The application data folders.

The default locations are:

  • Windows XP:

    • C:\Documents and Settings\All Users\Application Data\VMware\
    • C:\Documents and Settings\username\Application Data\VMware\

  • Windows Vista/7/8/Server 2008:

    • C:\Users\username\AppData\Local\VMware\
    • C:\Users\username\AppData\Roaming\VMware\

Beware that if you follow ALL those steps that you will have to put in your registration code again, so make sure you have that handy.

Your VMs will be fine, but you also will have to register/open them again.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
msschmitt
Enthusiast
Enthusiast
Jump to solution

It's not just me; I checked and another user has the same problem.

Given that before I reinstalled, the entire VMware Workstation folder was gone, it indicates that whatever security permissions are applied are due to the VMware install (or upgrade to 12.1.1).

I was thinking it could be a conflict with McAfee VirusScan, but a) we're not using the settings that would affect it, and b) I tried turning off the access protection; no help.

I think the key here isn't what I can do. It is what the VMware Tools installer can do, since an installer can run with elevated access. Consider that the VMware installer can install file owned by SYSTEM, for example.  The question is why can't the Tools installer update files in the VMware folder.

One difference may be that we do not run with UAC turned on; we have it set to allow anything without a prompt.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

Given that before I reinstalled, the entire VMware Workstation folder was gone, it indicates that whatever security permissions are applied are due to the VMware install (or upgrade to 12.1.1).

As I said, VMware Workstation stores it's configuration settings in another folder as the main VMware Workstation folder that you looked at.

An uninstall does not normally clean out all the configuration.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
msschmitt
Enthusiast
Enthusiast
Jump to solution

It turns out that the problem was caused by McAfee Host Intrusion Prevention 8 running on the host. This is the firewall component, not the anti-virus component.

Part of the intrusion detection is "VMware Workstation Shielding - File Modification". Presumably it has some bad signatures, because it is considering any attempt to alter the VMware Tools .iso files as an attack.  This includes:

  • VMware installation launcher, such as when VMware is upgrading itself
  • Windows installer run by the system, such as when VMware is attempting to download and install new tools
  • User attempting to delete or rename the files

So the tools .iso files are frozen in time: they can't be changed even by a complete uninstall and reinstall of VMware Workstation, let alone a version upgrade.

The surprising thing here is that a file modification is being blocked by HIP, which is far beyond what you'd normally expect from a firewall.  That's why it took me so long to realize it was the root cause.

The work around is to unlock the HIP interface and then temporarily turn off Host IPS in the IPS Policy. While IPS is off you can proceed with the VMware Workstation or tools upgrade, then turn IPS back on.

The permanent fix would be to get McAfee to fix the HIP signature. There are release notes that say that this isn't the first time the VMware Workstation Shielding feature has had false positives.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

Thanks for letting us know.

It has been a long time since I've been exposed to McAfee software so never considered it to be a problem.

You are right that it is a weird check for host intrusion prevention software.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos