VMware Communities
ralish
Enthusiast
Enthusiast
Jump to solution

Numerous vmauthd ID 100 events logged in Application Event Log

Whenever I open a virtual machine in VMware Workstation (v.6.0.2) an event is logged to the Application Event Log, from vmauthd, with Event ID 100. A sample of such an event is below:

Event Type: Error

Event Source: vmauthd

Event Category: None

Event ID: 100

Date: 10/01/2008

Time: 2:10:13 AM

User: N/A

Computer: METAPHYSICAL

Description:

Cannot connect to VMX: C:\Documents and Settings\SDL\My Documents\My Virtual Machines\Operating Systems\Microsoft\Windows for Workgroups 3.11\Windows for Workgroups 3.11.vmx

Despite the error, the virtual machine will open fine, and can be started and used without issue. The only thing I have noticed is that sometimes opening the virtual machine takes a while longer than expected (e.g. up to 10seconds waiting for the tab for the selected VM to open). Security permissions on the virtual machines are untouched. This issue seems minor, and only cosmetic, but it's still irritating as it floods the Application Event Log with error messages. I did a search on the forum, and some other people have been experiencing this problem, but no fix as of yet is documented.

Please let me know if I can give anymore useful information?

0 Kudos
1 Solution

Accepted Solutions
CrispinH
Contributor
Contributor
Jump to solution

I found a solution having struggled with this for some time and frequent uninstall/reinstall cycles which were driving me nuts. I'm running Vista 64-bit and Workstation 6.03.

It's a permissions issue with the local user and the way you effect the solution may depend whether or not you are connected to a domain controller. Since I am, this is the solution you get:

First be aware that you will need elevated (aka administrator) permissions to be able to perform some of these actions.

If you go to Control Panel > Administrative Tools > Computer Management and browse to Local users and groups, you should find a user called __vmware_user__. I opened up this user and copied the name to ensure no typing errors.

Now you need to find your Group Policy Editor which you can view, but possibly not be able to edit, locally by typing gpedit.msc into the Vista search box (Start button > Start search). Navigate down the tree: Local computer policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments. At this point you may find a padlock on the User Rights Assignments folder. However since you're here, at least check out the problem. Go to Allow log on locally and check to see if __vmware_user__ is in the list. If it isn't that's part of the problem, so if you can edit this record, append the __vmware_user__. Then go to Log on as a service and check to see if the __vmware_user__ is in the list. Again, if that user is missing and you can edit it, then append it. If you've been able to edit, then that should sort it out.

If you haven't been able to amend the records that means you have to edit the Domain Group Policy for which you have to go to you domain controller (note: my domain controller is running Windows 2003 so I can't say what would happen on other platforms) and find Active Directory Users and Computers under Administrative Tools. Right-click on the domain object (yourdomain.com) to get the context menu and then left-click on Properties. Click on the Group Properties tab and then the Open button (if that's not there, I can't help you).

Navigate down Group Policy Management > Forest: yourdomain.com > Group Policy Objects > Default Domain Policy and then select the Settings tab. Click on Windows Settings > Security Settings > Local Policies/User Rights Assignment. Right-click on Allow log on locally and then left-click Edit. This takes you to a new dialogue box which you navigate down Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Add the __vmware_user__ account to both Allow log on locally and Log on as a service.

There's probably a quicker way but I'm a software developer not an IT geek with tons of Group Policy experience. It worked for me, hopefully it will work for you.

Regards

Crispin

View solution in original post

0 Kudos
34 Replies
WPWoodJr
Contributor
Contributor
Jump to solution

I'm having this same error, whenever I start VMWare Workstation 6 I get one of these errors in the Application event log for each of my virtual machines. What is going on?

0 Kudos
ralish
Enthusiast
Enthusiast
Jump to solution

Hello,

I'm still experiencing this problem, no solution has been found yet.

What system are you running on?

This is an XP x64 SP2 box with VMware Workstation 6.0.2.

0 Kudos
ToreT
Contributor
Contributor
Jump to solution

Hi, I'm also having the same problem. Computer freezes for several minutes with short intervals. Most annoying as it leaves me with a unusable solution.

Have created new instance from scratch and tried uninstall/install vmware with no improvement.

This is an XP Home SP2 x32 with VMware Workstation 6.0.2 Build 59824. Do not believe this is host-related, as there are serveral messsages in theese communites describing this problem on different host sw and hw. Also a Beta 6-installation mentioning this problem. No one seems to have an answer.

Anyone having the solution? ..... Any VMware technical representative around...or are you just hopeing for us to go away Smiley Wink ??

Regards Tore

0 Kudos
TJAutomize
Contributor
Contributor
Jump to solution

I'm seeing the same thing as WPWoodJr. Host OS is Vista Ultimate x64.

0 Kudos
Peter_vm
Immortal
Immortal
Jump to solution

Can you change VMware Authorization Service to manual start?

Then, after host successful start (and some delay), execute:

cmd

net start "Vmware Authorization Service"

0 Kudos
CrispinH
Contributor
Contributor
Jump to solution

I agree about it being a bug. I'm running Vista 64-bit Ultimate and Workstation 6.02 and the failure of the VMware Authorization Service to start reliably is driving me demented. Re-installation of Workstation fixes the problem but it's a bore to do it daily and since it requires a reboot, I usually have to close two or three instances of VS2008, SQL Server studio, a stack of web pages, etc, etc and then remember where the hell I was after rebooting.

I've tried installing as the administrator on the local machine (ie not on the network) and that seemed to make it behave for a while, but not any longer.

What's slightly bizarre is that installing Workstation requires a reboot and the authorization service does fire up properly on the reboot - just not on subsequent reboots (but the power gets turned off on those which may be the difference)

In the event log I get a record with a source of vmauthd and ID = 100. The message is:

Failed to retrieve token for VMware user: Logon failure: the user has not been granted the requested logon type at this computer (1385)

I've also tried starting the service 5 mins after firing up Workstation. This doesn't seem to work either.

Please can we have a real, permanent, long-lasting fix soon.

Crispin

0 Kudos
ToreT
Contributor
Contributor
Jump to solution

Peter,

Did as you suggested, but no luck. Still same problem. Smiley Sad Host and guest freezes in intervalls and then come to live again, and still vmauthd-message in event-logg.

The one who finds the fix for this, should be nominated for a VMware SuperChampion title. Smiley Happy

Rgds Tore

0 Kudos
stevenestrada
Contributor
Contributor
Jump to solution

Hello,

host=W2K server, guest=W2K3 server, wmware workstation=6.0.3-8004

Experience is the same with the vmauth eventid 100 errors and frozen screens - plus vmware hardly uses any of the hosts 2G RAM regardless of the settings.

Is there a fix yet?

Thanks

0 Kudos
crote
Contributor
Contributor
Jump to solution

I just had, quite literally, the same issue as you and the result was due to a missing VMware Briding Protocol. Maybe this is the same issue for you?

SOLUTION: In your Network Connections folder, go to the properties of each network adapter (except the virtual VMware adapters...VMnet1, VMnet8, etc). Under the "This connection uses the following items:" section, be sure you have "VMware Bridge Protocol" installed and that it IS CHECKED. If not installed, click "Install" --> "Service" --> "Add" --> "Have Disk" --> Brows to your "C:\Program Files\VMware\VMware Workstation". Click OK. This should find the netbridge.inf file and let you choose the Bridging protocol again.

0 Kudos
stevenestrada
Contributor
Contributor
Jump to solution

>> I just had, quite literally, the same issue as you and the result was due to a missing VMware Briding Protocol. Maybe this is the same issue for you? <<

crote,

Thanks for posting and trying to help.

I reinstalled the netbridge.inf file, but it didn't make any difference.

0 Kudos
ralish
Enthusiast
Enthusiast
Jump to solution

Peter_vm: Tried your suggestion, had no effect. The VMware Authorisation Service seems to start fine on this machine anyway. Regardless, I manually stopped it, waited a minute, then started it again; re-opened VMware Workstation and opened a VM, got the usual error in the Application Event Log.

crote: I checked my Network Connects, and the VMware Bridge is enabled on all relevant network cards. The only NIC it's not enabled on (apart from the VMware Virtual NICs) is the 1394 Connection (which isn't used anyway).

Further, I just uninstalled VMware Workstation 6.0.2 completely, then installed 6.0.3. The same exact problem still persists, despite the upgrade. Smiley Sad

0 Kudos
fabienfr
Contributor
Contributor
Jump to solution

I have same problem on VMserver 1.05 : The host is W2K pro and guest is W2K pro also.

When I start Host, I have this message and I must start manually the service.

VMware bridge is enabled also.I don't know why the service can't start automatically.

I installed a lot of server and the only one created this problem.

Have you a solution ?

0 Kudos
krytie
Contributor
Contributor
Jump to solution

I am running VMware Worstation 6.0.2 build-59824 on Win2003 64bit & get exactly the same errors everytime i resume my guest machines.

Has anyone found a solotion for this yet?

If not, isn't it about time VMware responded to this, it seems to be far too common to be user error

0 Kudos
CrispinH
Contributor
Contributor
Jump to solution

I agree that VMware should offer a solution soon. I've scoured the forums for possible answers including logging on as a local administrator, but the vmauthd service just doesn't survive the second boot. Everything fine after the initial post installation boot, but the next reboot kills is.

My workaround is not to turn off the computer if at all possible but patch Tuesday comes around routinely and that frequently requires a reboot, uninstall of VMware Workstation followed by a re-install. This is boring.

Crispin

0 Kudos
ralish
Enthusiast
Enthusiast
Jump to solution

Hello again,

Problem still exists sadly, so nothing to report! Smiley Sad

After re-reading all the posts in this thread, it seems people are getting different "symptoms" from what appears to stem from the same problem, some issue with the VMware Authorisation Service.

Just to clarify, the effect it has on my machine is VM's take a while longer to load (and by load, I mean open their tab, not running the virtual machine; starting the virtual machine will take a few seconds longer than usual, but once the BIOS comes up, the VM works as normal).

So my specific problem is that opening VM tabs takes a while longer AND the Application Event Log is filled with access denied messages from the VM Auth Service as a result of opening and starting each VM.

So yes, we seem to be having a variety of different problems, but it all seems to relate back to the VM Auth Service.

So, uh, any more suggestions for us VMware people? Smiley Happy

-SDL

0 Kudos
mikedp
Contributor
Contributor
Jump to solution

Same error event experienced here when opening any vm, event ID 100 source vmautd - cannot connect to VMX

It just takes a little longer when opening a VMX - it still works OK and without error. Particularly painful when opening my 'virtual lab' which is a team of 20 vm's.

"Event ID 100 Source vmauthd Cannot connect to VMX: E:\vpcse\eos3c1\Clone of eos3c.vmx "

This has been bugging me for quite some time, and there seems to be no solution from support, even when many users share the same issue.

Host1 XP x64 sp2 - VMware Workstation 6.0.2 build 59824

Host2 Windows 2003 server sp2 - VMware Workstation 6.0.2 build 59824

This error comes every time AFTER the very first time a vmx is loaded. Repeated with multiple fresh installs of clean OS, clean VMware, result always the same. Easily & consistently repeatable - come on VMware Support - when will this issue be resolved?

Clean OS install - clean VMware install - load any VM without error. Power down vm's and exit vmware. Restart vmware & load a vmx = ERROR event ID 100

This needs to be fixed by VMWare Support.

Cheers all,

mikedp

0 Kudos
CrispinH
Contributor
Contributor
Jump to solution

I found a solution having struggled with this for some time and frequent uninstall/reinstall cycles which were driving me nuts. I'm running Vista 64-bit and Workstation 6.03.

It's a permissions issue with the local user and the way you effect the solution may depend whether or not you are connected to a domain controller. Since I am, this is the solution you get:

First be aware that you will need elevated (aka administrator) permissions to be able to perform some of these actions.

If you go to Control Panel > Administrative Tools > Computer Management and browse to Local users and groups, you should find a user called __vmware_user__. I opened up this user and copied the name to ensure no typing errors.

Now you need to find your Group Policy Editor which you can view, but possibly not be able to edit, locally by typing gpedit.msc into the Vista search box (Start button > Start search). Navigate down the tree: Local computer policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments. At this point you may find a padlock on the User Rights Assignments folder. However since you're here, at least check out the problem. Go to Allow log on locally and check to see if __vmware_user__ is in the list. If it isn't that's part of the problem, so if you can edit this record, append the __vmware_user__. Then go to Log on as a service and check to see if the __vmware_user__ is in the list. Again, if that user is missing and you can edit it, then append it. If you've been able to edit, then that should sort it out.

If you haven't been able to amend the records that means you have to edit the Domain Group Policy for which you have to go to you domain controller (note: my domain controller is running Windows 2003 so I can't say what would happen on other platforms) and find Active Directory Users and Computers under Administrative Tools. Right-click on the domain object (yourdomain.com) to get the context menu and then left-click on Properties. Click on the Group Properties tab and then the Open button (if that's not there, I can't help you).

Navigate down Group Policy Management > Forest: yourdomain.com > Group Policy Objects > Default Domain Policy and then select the Settings tab. Click on Windows Settings > Security Settings > Local Policies/User Rights Assignment. Right-click on Allow log on locally and then left-click Edit. This takes you to a new dialogue box which you navigate down Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. Add the __vmware_user__ account to both Allow log on locally and Log on as a service.

There's probably a quicker way but I'm a software developer not an IT geek with tons of Group Policy experience. It worked for me, hopefully it will work for you.

Regards

Crispin

0 Kudos
Kimbo
Contributor
Contributor
Jump to solution

In response to CrispinH - I would like to pass on my gratitude to him for providing such a detailed solution to the issue being experienced.

I have WinXP SP2 and WS 6.03 and have been experiencing the Event ID 100 entries, seemingly, since upgrading to the latest Build (80004).

While appreciating the very extensive guide provided by CrispinH I managed to follow the pathways he set out for Vista - is much the same as for WinXP apart from the slight difference in policy names.

Having inserted the user __vmware_user__ where the user name was missing - I monitored the event viewer each time I either accessed Workstation, closed it down, restarted the Host PC, restarted the either via warm or cold boots, restarted Workstation and the very pleasing result was that the offending Event vmauthd event ID 100 disappeared from the log.

I therefore assume the solution provided by CrispinH works without causing Workstation any major hernias from this point forward. Perhaps with the community VMware gurus obtaining any assistance from within VMware support that some credence will be given to providing a certified patch for users to install without having to change Group or User policies.

I thank you CrispinH for taking the time to provide such a detailed solution and I hope that all the frustrated users before me find the solution provided works for them as well.

Looking forward to hearing more positive feedback - and an appropriate patch from VMware very shortly!

Now back to finding a solution for a sporadic, jittery and stodgy mouse with double cursors!.

Regards to all VMware users.

Kimbo

0 Kudos
krytie
Contributor
Contributor
Jump to solution

Crispin,

I tried this on my VMware WS lab machine running Win 2003 X64 with WS 6.02. This machine is not a Domain member, so the properties can be amended in secpol.msc which is the local security policy editor. The changes are reflected in gpedit.msc, so the settings are the same.

I assigned both log on locally & log on as a service to the user __vmware_user__ & then rebooted to ensure the user's rights were refreshed.

Unfortunately, i still get a log full of red 100 events when i try to run VMware & launch a machine

I then tried updating to WS 6.03, as i spotted that this was the version you are using. As VMware uninstalls first, before updating, i had to re-add the account to the user rights, but i still get the same vmauthd 100 events.

Come on VMware, it is about time you stepped in and helped out with this one!!!

Jerry

0 Kudos