Also you might want to try uninstalling the old tools before upgrading to new ones.

And... update your virtual machine hardware first before doing that.  This has been successful for me.

Based on the response I received on our support request, it is a known issue.

The problem occurs when the tools are being updated from 3.5 U4 to 4.0.  Before upgrading to 4, you're supposed to update 3.5 to Update 5.  Then, you have to go in and update the tools to U5 version.  Then, you can update them to 4.

This seems to answer the problem.  The official workaround is to find the DLL off of another machine (same version... duh) and replace the file, or if you have backups of it, restoring it.

It only affects 1 DLL file, and that is the msvcp71.dll.

Hope this is a help to all of you out there.

You really don't need to do that.  It's a windows system file.  If you're backing it up, restore it.  If you've got another machine with the same version of OS, use that.  It works.  Tested.

I have upgraded three of my ESX Clusters to version 4.0 and have found something interesting.

The first cluster I did, I put each host into maintenance mode manually and vmotion took care of moving the VMs. Then I used vSphere Update Manager to upgrade the host to 4.0, install the 3 released patches for ESXi 4.0, then exit maintenance mode and move onto the next host. I hadn't done anything to the VMs themselves other than allow vmotion to move them around as I upgraded each host. Those VMs that have the option "Check and upgrade tools before each power-on" all seemed to automatically upgrade VMware Tools on the guest when a vmotion performed that moved the VM onto a version 4 host. I would have thought this wouldn't happen, but only when you shut down the VM and power it back on? Anyway, every one of those VMs had the MSVCP71.DLL issue.

The VMs that didn't have the tools upgrade option enabled, manually had their VMware Tools upgraded. None of these VMs had the DLL issue.

On the second cluster I upgraded, I did it out of hours and shut down every VM in the cluster. I then upgraded the hosts to 4.0 and then powered back on the VMs. Each of the VMs automatically upgraded VMware Tools after Windows booted and then restarted. None of them had the DLL issue.

On the third cluster, I did a mix of the previous two. Some VMs I shut down and others I allowed vmotion to move them online. The VMs that were moved with vmotion automatically upgraded VMware Tools and all had the DLL issue.

I have two more clusters to upgrade and I don't like that I will have to shut down all the VMs if I want to avoid this issue

Chris