VMWare Workstation 7.1.3 crashes on "Edit Virtual Machine"

[DonkeyHootie]

Just bought a new computer and migrated all my data to it.  Hardware is Intel Core i7 with 12G memory, running Windows 7 64-bit.  Installed VMWare Workstation 7.1.3.  Whenever I do something that would cause the "Edit Virtual Machine" dialog to open (whether on an existing virtual machine or choosing Customize when creating a new virtual machine), VMWare Workstation crashes (See screenshot.)

I tried doing a "repair installation", and uninstalling VMWare and reinstalling, but same result.  So I cannot edit any of the settings of a virtual machine (other than opening the text file with an editor.)

[a_p_]

Welcome to the Community,

Please take a look into the Application event log to see whether there is a more detailed information what is causing Windows to stop VMware Workstation.

André

[DonkeyHootie]

OK, that was helpful.  I looked in the Application log in Event Viewer (I think this is what you mean, rather than the  VMWare menu item for Message Log) and found this Application Error.

Another data point: I did try booting in Safe Mode and I was able to get to the dialog without error in Safe Mode.

Faulting application name: vmware.exe, version: 7.1.3.14951, time stamp: 0x4cdc5fe1

Faulting module name: VNETLIB.dll, version: 7.1.3.14951, time stamp: 0x4cdc4693

Exception code: 0xc00000fd

Fault offset: 0x00039cef

Faulting process id: 0x9b0

Faulting application start time: 0x01cba7a93c96d8f3

Faulting application path: C:\Program Files (x86)\VMware\VMware Workstation\vmware.exe

Faulting module path: C:\Program Files (x86)\VMware\VMware Workstation\VNETLIB.dll

Report Id: ca670d13-139c-11e0-9274-005056c00008

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

  <Provider Name="Application Error" />

  <EventID Qualifiers="0">1000</EventID>

  <Level>2</Level>

  <Task>100</Task>

  <Keywords>0x80000000000000</Keywords>

  <TimeCreated SystemTime="2010-12-29T22:41:36.000000000Z" />

  <EventRecordID>2048</EventRecordID>

  <Channel>Application</Channel>

  <Computer>brian-home</Computer>

  <Security />

  </System>

- <EventData>

  <Data>vmware.exe</Data>

  <Data>7.1.3.14951</Data>

  <Data>4cdc5fe1</Data>

  <Data>VNETLIB.dll</Data>

  <Data>7.1.3.14951</Data>

  <Data>4cdc4693</Data>

  <Data>c00000fd</Data>

  <Data>00039cef</Data>

  <Data>9b0</Data>

  <Data>01cba7a93c96d8f3</Data>

  <Data>C:\Program Files (x86)\VMware\VMware Workstation\vmware.exe</Data>

  <Data>C:\Program Files (x86)\VMware\VMware Workstation\VNETLIB.dll</Data>

  <Data>ca670d13-139c-11e0-9274-005056c00008</Data>

  </EventData>

  </Event>

[a_p_]

There seem to be are some issues with Workstation 7.1.x on Windows 7 64-bit.

Can you try to start VMware Workstation as the "Administrator" (Run as ...) to see whether the error occurs too?

Community member continuum has some hints on his webpage http://faq.sanbarrow.com/index.php?action=artikel&cat=3&id=114&artlang=en which might be worth reading.

André

[DonkeyHootie]

OK, that helped -- running as administrator causes this crash to not happen.  

Does this point us to a cause, or is it just a workaround?

[a_p_]

Basically it's not a crash but more a functionality Microsoft introduced with - I think - Windows Vista.

Does this point us to a cause, or is it just a workaround?

Good question. IMO running an application as the Administrator should only be a workaround. However, I guess we should wait and hope continuum reads this and might have some more information on this issue.

André

[continuum]

> IMO running an application as the Administrator should only be a  workaround.

yep - full ack....

If running as admin is necessary I guess the setup of the drivers was not fully successful.

Have a look here

http://faq.sanbarrow.com/index.php?solution_id=1113

there I listed some checks to verify correct driver setup.
Please go through it and post your results

[DonkeyHootie]

Driver files:

hcmon.sys
vmbus.sys
VMBusHID.sys
vmci.sys
VMkbd.sys
vmnet.sys
vmnetadapter.sys
vmnetbridge.sys
vmnetuserif.sys
vms3cap.sys
vmstorfl.sys
vmusb.sys
vmx86.sys
vnetinst.dll
vnetlib64.dll
VmbusCoinstaller.dll
vmbuspipe.dll
vmbusres.dll
VmdCoinstall.dll
vmicres.dll
vmicsvc.exe
vmictimeprovider.dll
vmnetbridge.dll
vmstorfltres.dll

Services: all the services listed in that page are present (and more); all started.

Pseudo accounts: not present

[continuum]

can you run as admin ?

net stop vmauthdservice

net start vmauthdservice

can you view the key HKLM\SAM ?

[DonkeyHootie]

Services stopped and started successfully.  Still nothing in  HKLM\SAM\SAM.

[continuum]

nothing at all ? - then you still need to fix permissions
or are just the two keys missing ?

if just the keys are missing I could send you a patch

[DonkeyHootie]

I believe the keys are missing; when i run regedit as administrator, I see nothing below HKLM\SAM\SAM.  

[continuum]

no - if you see nothing its permission issue.
Set permissions for HKLM\security first - then it should be possible for SAMi

do you have teamviewer ?  - I am interested in looking into it more closely

[DonkeyHootie]

OK, having set permissions on HKLM\Security, HKLM\SAM, and HKLM\SAM\SAM, running the instructions on your web page for querying the pseudoaccounts now yields:

HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Aliases\Names\__vmware__
    (Default)    REG_NONE  

HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names\__vmware_user__
    (Default)    REG_NONE  

[DonkeyHootie]

Here's a screen grab of the pseudo-user subtree in regedit.

[continuum]

that is ok

hmmm - next I would seriously consider to do a clean install of version 7.0.1 following the instructions from my howto.

do you have any special apps installed like Antivirus/ Firewalls , USB-lockdowntools ...
anything else I should know ?

[DonkeyHootie]

No security software yet.  This is a new computer; I generally install the anti-virus last since it can interfere with installations. Plenty of ordinary utilities (Dropbox, Evernote, Google Toolbar) that get their hooks into things, though.

[rbv4531]

I can repro this (edit settings causes immediate crash, unless running as admin).  This started happening when I updated VMware Wksta to 7.1.3 build-324285

Host system is also Win7 Ultimate x64.

[PnwGuy]

Any news on this? It's been nearly 2 months and I'm having the exact same problem. It's 100% easy to reproduce.

Trying to blame this on Vista or Win7 64 is just plain wrong. 7.1.2 didn't do this on Win 7 64 and doing nothing but upgrading to 7.1.3 creates this problem. Hacking permissions and/or the registry is hardly an acceptable solution.

The only reason I upgraded is I was getting *REALLY* tired of of the netstop/netstart routine to restore network connectivity after the host OS was suspended for power management (a serious bug in 7.1.2).

The majority of new PC's have 64 bit Win 7 on them--especially anyone wanting enough RAM to properly run VMWare workstation. So trying to blame this on running a 64 bit OS is really misguided.

How about it VMWare? Any fixes? Problems like these are why so many people I know who used to love VMware are giving up on the product and going with VirtualBox or other solutions. If the stability of Workstation keeps getting worse intsead of better I'm going to join them along with countless others. Why pay for something this broken?

[DonkeyHootie]

I have not found a solution.  I backed off to an earlier version of VMWare (7.0.x) and got the same basic result.  I have not gone through all the "uninstall, turn off UAM, manually clean registry" steps yet.

I had been using the trick of running VMWare as Administrator but that put me in a position where the owner and permissions on some files were such that I could then not access them when I ran not as administrator.  So that workaround did not work.