Can't even start VMware after upgrading to 6.0

[mrizos]

I just installed VMware 6.0 on my Vista laptop. When I go to launch VMware 6.0 i get

Application Failure. hr = 0x80004003:(null)

Any ideas?

[ulaef]

It's the same problem on my Vista machine (Ultimate). I tried to install on XP SP2. There it works without problems.

I tried some suggestions made in the forum and targeting 0x80004003, but with no success.

Please help!

[codecruncher]

Same problem for two of us here.

Installing on Vista 64-bit Ultimate gives me this problem.

Installing on Vista 32-bit Business and it worked for me.

But another person here installed on Vista 32-bit and got this same hresult on launch.

We both installed with "run as admin", we both have UAC enabled, and we are running with the same account that we used for install.

[codecruncher]

Digging into my AppData vista dirs I can see startup logs of vmware like this one:

C:\Users\test\AppData\Local\Temp\vmware-test\vmware-test-3280.log

which doesn't provide much to go on. Help.

May 10 15:39:36.223: vmui| Log for VMware Workstation pid=3280 version=6.0.0 build=build-45731 option=Release

May 10 15:39:36.224: vmui| Hostname=test

May 10 15:39:36.406: vmui| HostDeviceInfo: Failed to enumerate host parallel ports via the registry. Could not open device map parallel port registry key.

May 10 15:39:36.498: vmui| HOSTINFO: Seeing AMD CPU, numCoresPerCPU 2 numThreadsPerCore 1.

May 10 15:39:36.498: vmui| HOSTINFO: This machine has 2 physical CPUS, 4 total cores, and 4 logical CPUs.

May 10 15:39:37.262: vmui| Foundry Init: setting up global state (0 threads)

May 10 15:39:37.262: vmui| Foundry Init: version 2, hostType 1, hostName (null), hostPort 0, options 0x203

May 10 15:39:37.308: vmui| Unhandled COM exception: hr = 0x80004003: (null)

May 10 15:39:39.325: vmui| Exception caught; trying to exit app.

May 10 15:39:39.333: vmui| Exited abnormally.

[RDPetruska]

Delete your preferences.ini file (located in C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\ I think).

[KevinG]

Robert was close, delete the preferences.ini file in

C:\Documents and Settings\\Application Data\VMware

[RDPetruska]

Robert was close, delete the preferences.ini file in

C:\Documents and Settings\<username>\Application Data\VMware

Figures. For once I go on memory and not look up the location... and I get it wrong. What I listed was the location for the config.ini file. Now I remember!

[KevinG]

No problem, I can't remember what I ate for Breakfast most mornings.

[codecruncher]

Yeah, that doesn't work.

And on Vista the path is:

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

I've got a support incident open on this one. Initial reaction has been that some COM registration the installer was supposed to do got fubar'd. They wanted me to regsvr32 a few dlls manually, but when I try to do that, it fails.

[manthes]

I have the same 'crash at start' problem under my AMD Dual Core PC using Vista Ultimate 32bit. On the same machine it works without problems under Vista Ultimate 64bit (dual boot).

I tried it on two other PCs (single core) with Vista Ultimate 32bit. No Problems. Also no problems under Windows XP SP2.

It seems like a bug in Workstation 6.0 or in the installation routine.

Please let us know if you get more information from support.

[codecruncher]

The root cause of this seems to be registry key permissions or some sort of corrupt registry.

On the machines that have a problem, when I use sysinternals.com's process monitor to watch regsvr32 when it fails to register the couple of dlls VMware support wants me to, it shows that a few HKCR entries are access denied even to admins.

Probing further with regedit we find that a handfuls of keys under HKCR are not readable by the admin.

Initial thoughts were this might be the new Windows Resource Protection mess in Vista where the new "TrustedInstaller" service is the only thing that has modify permission to the keys. But even in WRP protected keys, it seems that most/all other users still have read permission and TrustedInstaller is the owner. The mystery/problem keys we find in the registery we have no idea what permissions are on them because regedit tells us we can't view the permissions but we can change them. Which turns out to be false because when we try to take ownership or add back permissions it then says it failed to save those changes.

A very easy test to see if the PC involved has this problem is fire up regedit.exe w/ admin permission, select HKEY_CLASSES_ROOT. Press the + key to expand the tree underneath it, and hold down the down arrow key so that regedit starts to navigate each direct child key. Within just a few seconds we'll find some entry that says "xyz cannot be opened. An error is preventing this key from being opened. Details: Access is denied."

We have not been able to narrow down any common software between the 2 PCs involved that don't work and the 1 that does. But the 1 that does, does not have any HKEY_CLASSES_ROOT children that have this strange permission behavior.

Ack. Vista. What a mess.

[manthes]

Yes, you are right!

My Vista system which shows the problem has this kind of corrupted registry with wrong permissions set and lots of 'access denied' under HKCR.

My other Vista systems, which are able to run Workstation 6, have not one access denied key under HKCR.

Now the question is: how to repair the faulty permission settings in the registry? It seems like only a new fresh install of Vista will help. What a mess (and lots of lost working hours to reinstall and configure everything)

Thanks for your hints!

[ulaef]

Hi,

i over installed vista. The problem with VMWare is gone. I believe it has to do with the registry thing. I had a same strange behavior with using Visual Studio Orcas Beta 1 under Vista too.

It would be great if anyone knows hot to fix the registry without an fresh installation of vista.

Best Regards,

Ulaef

[ClayMon]

I don't have Vista to try this on but I have encountered problems with VMware GSX and registry permissions. Here is what I did then, please let me know if it works in Vista.

Use the AT command to lauch Regedit interactively. Pad a couple of minutes then wait, or you can go into Scheduled Tasks and launch the task right away.

If this works the same on Vista as it does on 2003 then Regedit will be running in the context of the System account and can grant the proper permissions. If this doesn't work, I'll see if i can get my hands on a Vista machine and hack through it.

[DataBitz]

This problem was found during the beta "SR Number: 184926601" and notified to VMWare. Nice one VMWare!

http://www.vmware.com/community/thread.jspa?messageID=632400

Best fix has been posted here.

http://www.vmware.com/community/thread.jspa?messageID=627748#627748

[steve007]

I've been having this problem for the passed couple of hours while with a trial edition of VMWARE6 and after some pain in the butt, tweaking and fiddling I managed to get it to work. These are the steps I took to fix the borked reg entries that it initially installs with, since those are the main problems.

Disabled the UAC so you get no annoying pop ups (you don't need to do this but I did it just incase it caused any permission issues)

Install the product as normal with the borked reg entries.

Create a shortcut to the setup.exe file for VMWARE and used a /c flag at the end of the target for the setup.exe for the shortcut . So it should look like this:

F:\downloads\downloads\vmware\setup.exe /c

Click on the shortcut and you should get a message saying it is going to forcefully delete all reg and installation info for VMWARE etc just click ok and continue.

Another dialogue box should pop up giving you three options: modify, repair or uninstall. Chose repair and click ok and wait for it to finish.

After this just clock on the shortcut for vmware on your desktop or via the programmes menu from start and it should start up with no probs at all. I tried this 3 times and it seems to fix the problem so give it a shot it could work for you.