VMware Cloud Community
StJoes
Contributor
Contributor

DLL corruption during VMWare Tools install (msvcp71.dll)

We recently upgraded our ESX server to vSphere 4.0. After bringing the vm's back online, and then upgrading the Tools, we had issues with several applications working. Troubleshooting seems to have revealed that during the Tools installation a new version of msvcp71.dll is used, and any existing version is (apparently) removed from the system32 directory. We found three copies of the dll in various directories under Windows\temp all in directories used during the VMWare Tools install.

By copying the file back into the system32 directory, the application (MS SQL was the main application with issues) now works correctly.

Brian

Reply
0 Kudos
24 Replies
htwnrver
Enthusiast
Enthusiast

Can you post the other applications so that we can be aware of them when we upgrade?

Thanks,

Reply
0 Kudos
StJoes
Contributor
Contributor

We also had problems with pcAnywhere (v10), and Symantec Antivirus Corporate Edition (v10), which we believe were associated with the same issue. We haven't yet reinstalled those applications to test whether this fixed there issues or not.

Brian

Reply
0 Kudos
TAMW
Enthusiast
Enthusiast

We had the exactly same msvcp71.dll problem with MS-SQL 2000.

After the vmware tools update the SQL service refused to start with the error that is was missing the msvcp71.dll

Reply
0 Kudos
jawad
Contributor
Contributor

I have also had this problem on host that has SAV10 installed. Did a repair on the SAV install and all OK.

But pretty annoying to do this on 40-50 VMs...

In the shadows...
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Moved to Virtual Machine and Guest OS.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
AndrewAbo
Contributor
Contributor

I encountered multiple VM's where Symantec Endpoint stopped working after the upgrade to 4.0. Posting this due to multiple others with Symantec products experiencing issues.

The problem was fxed by going to Add/Remove Programs, and running Modify-->Repair on Symantec Endpoint.

Reply
0 Kudos
AVK82
Contributor
Contributor

We had the same problem with all SQL instances after upgrading: the msvcp71.dll file was completely missing. Copied from another similar machine: it works like a charm now.

Thank you for posting the solution!

Reply
0 Kudos
sbolter
Contributor
Contributor

Apparently when you install the upgraded VM Tools on the virtual machine, it deletes a file called msvcp71.dll from the System 32 directory.

This also impacts IBM\Tivoli (TSM) Backup software. The TSM Service requires this Dll to start. Quick fix is to copy this file from another server with the TSM software back into the system32 folder. I noticed this once the VM Tools upgrade completed logging in produced the error that service could not start due to msvxp71.dll file missing. Once the File is replaced the service starts. Also upgrading the Hardware to v7 has no impact on this dll from what I have seen only during the VM Tools upgrade.

Error on the side of Caution Take a snapshot first!!!!

Reply
0 Kudos
gkheigde
Contributor
Contributor

We upgraded last night. The same problem. VMWare Tools installation busted our DATEV installation. You have to do the repair the "Installationspacket" in the DATEV Software.

Reply
0 Kudos
apohlgeers
Contributor
Contributor

This also affected our Laserfiche 7 servers. We couldn't get the server to start but luckily when I started the client it reported the missing file. Replacing the .dll in the system32 folder worked but is really is a pain. Anyone know why the VMware upgrade does this?

Reply
0 Kudos
chjones
Enthusiast
Enthusiast

Hey all,

Has anyone heard anything from VMware about this issue? I experienced it as well today. SAV 10.x failed on 30+ VMs after VMware Tools was upgraded.

-


Chris Jones

Canberra, Australia

Reply
0 Kudos
Chuck8773
Hot Shot
Hot Shot

We have not upgraded the tools on many VM's yet. I have two experiences with this dll.

1. I imported a VCB backup of hardware 4 with old tools onto a vsphere 4 host. The VM was created with hardware 7. The tools were still old. When it came up it complained about this dll andSQL Server simply would not start. We troubleshot it for a while before noticing that the hardware had been upgraded. We restored it again to a 3.5 host and everything worked just fine.

2. Saturday, I upgraded the vmtools and hardware on our virtual vCenter and sql server. They started up just fine. Yesterday, the vcenter server started complaining about that dll at about 10:30 am. Then the vcenter service crashed. I couldnot restart it. I rebooted bothVM's and still nothing. vCenter was reporting the the login to the database failed. I tested the password we have on file and it worked. I ended up resetting the password to the database within vcenter and it started working. vCenter forgot the password. When I spoke with VMWare about this, I asked them to add this dll information to the ticket for future reference as the timing of the events was too close to be coincidence. It seems like the issue with that dll made vCenter forget the password. Not sure how that can be.

Hope this helps someone.

Charles Killmer, VCP

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

Charles Killmer, VCP4 If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
Reply
0 Kudos
adamsb
Contributor
Contributor

One way I "fixed" this was after i finished the tools/updates I assigned a new package to be applied to the clients group. This ran across the guests and reinstalled the clients "fixing" the problem.

Reply
0 Kudos
jjahns
Enthusiast
Enthusiast

Note: 64-bit machines keep the file at C:\Windows\SysWow64

If you have good backups, or copied itt, simply restore it after the VMware Tools upgrade. There's another workaround.

If you don't backup, use the Windows Install CD. It works. Tested it already.

Our "patient zero" ended up being a production instance of SQL Server 2000 that processes utility meter reads for our company on an hourly basis. So... our downtime was significant. Given that this is only the 2nd bug I have ever experienced from VMware in over 2 years, I can overlook this error. Its not that big of a deal because there are smart people on these forums who spotted this problem straight away.

Good luck everyone.

Reply
0 Kudos
jjahns
Enthusiast
Enthusiast

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.

Reply
0 Kudos
rogerfinch
Contributor
Contributor

just found this out by upgrading the tools on a few servers.

why isn't this a known issue?

Reply
0 Kudos
jjahns
Enthusiast
Enthusiast

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.

Reply
0 Kudos
JoFu
Contributor
Contributor

Today I upgraded from ESXi 3.5 U4 to ESXi 4. I ran into the same problem, in my case Panda Security failed to start because of the missing dll.

I'm about to reinstall the Panda protection right now, and I assume it's fixed after that.

Reply
0 Kudos
jjahns
Enthusiast
Enthusiast

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.

Reply
0 Kudos