Recently patched our Windows 2008R2 server that hosts vSphere Server with the above patch.
After that, the Update management service starts a java process that runs at 100% CPU, and wont
Rebooting server or Restarting service makes no apparent difference.
Also, killing java.exe only makes it reappear after a couple of seconds.
Memorywise it looks correct.
Any clues on where to start looking for what it is trying to do ?
File included is from procmon, which says that result of java-call is NAME NOT FOUND
I could not find a way to cut'n paste, so text file included instead.
I'm also having this same issue and found the java.exe update manager link using the same process monitor tool from MS. Looks like I'll need to open a support case as well.
Guys, I'm getting ready to open an SR on this. Any chance you able to get an root cause? I don't see re-install as a valid option. If there is an issue, I don't want to have to re-install every time we see it.
In my case, VMware support shared that my previously installed update manager was causing an issue with 4.1.0 build 345043. I did not uninstall my previous update manager before installing 4.1.0 build 345043. Support stated that it was best practice to uninstall previous versions of update manager before installing the latest version. Unfortunately I did not get more detail from VMware on the root cause nor did I further investigate due to the issue being remedied quickly with an uninstall/reinstall. This is the first time that I have seem the issue on this machine which has been upgraded many times since 4.0.
We had exactly the same issue in our environment (java.exe *32 running at 100% CPU after upgrading vcenter to build 345043). We had also done an 'in place' upgrade of update manger without removing the existing version. As soon as update manger was uninstalled java.exe stopped running. We installed the latest version of update manager after a reboot of the vceneter server and we haven't had the issue return (so far).
Based on what everyone has stated above, I restarted the VMware vCenter Update Manager Service and it seems to have brought things back to normal. Previously, I tried logging off all sessions and restarting the vCenter service (everything but a full server reboot); all were unable to bring the processor back down to normal. I'm monitoring the server now to see if the CPU usage goes back to 100%.
Bumping this as we have the same problem with vCenter 5.1 and update manger 5.1 Same issue. This helped resolve it. This started happening after installing the IBM SAN vCenter module. I believe they tried to share the same ports.