Archive
Version mismatch with vmx86 driver
Well, it happened again. I upgraded VMware Workstation from 16.1.0 to 16.1.1. After rebooting I started a VM & got an error that said, “Version mismatch with vmx86 driver: expecting 401.0, got 308.0. You have an incorrect version of driver ‘vmx86.sys’. Try reinstalling VMware Workstation. Failed to initialize monitor device.”
I clicked OK & got another error that said, “Transport (VMDB) error -14: Pipe connection has been broken.”
The vmx86.sys file sounded familiar. Sure enough, I had a very similar problem last year & wrote a blog post about it.
https://patrickhoban.wordpress.com/2020/04/05/failed-to-start-the-vmware-authorization-service
Long story short, there’s an old version of the vmx86.sys file again. Do a repair on VMware Workstation, reboot, & try again.
Failed to start the VMware Authorization Service
When starting a VM I received an error that said, “VMware Workstation failed to start the VMware Authorization Service. You can try manually starting the VMware Authorization Service. If this problem persists, Contact VMware support.”
Looks like both the VMware Authorization Service & VMware Workstation Server service aren’t running.
I try to start VMware Authorization Service but get an error that says, “Windows could not start the VMware Authorization Service on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 6000009.”
Checking the Event Log I find one System event & three Application related events.
Event ID: 7024
Log Name: System
Source: Service Control Manager
Message: The VMware Authorization Service service terminated with the following service-specific error:
%%6000009
Event ID: 1000
Log Name: Application
Source: vmauthd
Message: Version mismatch with vmmon driver: expecting 385.0, got 308.0.
Event ID: 1000
Log Name: Application
Source: vmauthd
Message: Try reinstalling VMware Workstation.
Event ID: 1000
Log Name: Application
Source: vmauthd
Message:
Yes, the third application event really did have a blank message.
I don’t see any references in the registry or file system for anything named “vmmon”. I notice that the VMware Authorization Service depends on VMware vmx86 & it was running.
Get-Service -Name “VMware vmx86”
Below are the details for the VMware vmx86 service from the registry. Note that the ImagePath is “\SystemRoot\system32\DRIVERS\vmx86.sys”.
The properties of vmx86.sys show a File Version of 12.5.1.3 & build date of 6/19/2017. That seems pretty old for VMware Workstation 15.5 from 2020.
Let’s try a repair.
Using the PendMoves utility from SysInternals, it would appear the vmx86.sys file is going to be updated on reboot.
After the reboot, everything looks much better. Services are running.
vmx86.sys now has a file version of 15.0.0.84 dated 3/7/2020.
But most importantly, all VMs powered on properly.
What’s interesting about this issue is that about 5 months ago I upgraded from VMware Workstation version 12.5.7 to 15.5.1 & everything has been working. Which means that VMware Workstation version 15.5.1 works with vmx86.sys version 12.5.1.3. The issue started after upgrading from VMware Workstation 15.5.1 to 15.5.2.
If the repair doesn’t work for you, I also found a VMware KB article that walks you through manually removing the vmx86 service. In the end, you still have to reinstall.
Hyper-V host blue screens (BSOD) after being added to SCVMM
Description
When rebooting a Hyper-V host running on VMware Workstation after adding it to System Center Virtual Machine Manager (SCVMM), the host will not boot & blue screens (BSOD).
Cause
When a Hyper-V host is added to SCVMM, several hardware IDs are added to the Multi path I/O (MPIO) list. One of these hardware IDs are not compatible on VMware Workstation.
Information
To see a list of hardware IDs added by SCVMM run:
Get-MSDSMSupportedHW
It’s worth noting that when the MPIO role is installed, the only ID in the list is a generic entry for Vendor 8 Product 16.
Solution
Boot the Hyper-V host to the last known good configuration. Once it’s back up, add the Hyper-V host to SCVMM again. Before rebooting, remove the MPIO entry for MSFT2011SASBusType_0xA by running the following PowerShell command:
Remove-MSDSMSupportedHW -VendorId "MSFT2011" -ProductId "SASBusType_0xA"
Now reboot the Hyper-V host.
Nested VM Performance is Slow
This is taking forever!
That’s what I was thinking when deploying nested virtual machines on vSphere 6.5 in my lab (OK, it’s my laptop). The configuration was simple enough; the latest version of VMware Workstation, an ESXi host VM, & a Windows Server 2012 R2 VM nested in ESXi. Simple enough, right?
Watching the console of the nested VM I notice it seemed…slow. When the VMware logo on the POST screen finally appeared I could see the screen painting making it look like an 80’s arcade game.
As you can see that took way too long. So with Process Monitor running on the laptop I power on the VM again. After it runs for about a minute the fun task of sifting through the ProcMon log begins. If you’ve ever used ProcMon you know it’s more of an art than a science. The first thing I always do is use the analysis tools from the menu.
Honestly, I just go through each of them & see if something jumps out at me. Real technical, I know. In all the sifting & sorting one thing that kept jumping out was the Anti-Virus software.
This wouldn’t be the first time an Anti-Virus product interfered with an application working properly so I started digging through the AV interface. After clicking around for a bit I come across some very interesting settings.
“Enable hardware-assisted virtualization” & “Use nested virtualization where available”. Those look promising. I uncheck both of those settings & give the laptop a reboot. This time when the nested VM boots it POPS!
According to Avast’s website, the software is supposed to detect that virtualization applications like VMware Workstation or Microsoft Hyper-V are installed & automatically disable these settings.
Cheers!
Visitors
Patrick's Blog 