VMware Communities
SimArchitect
Contributor
Contributor
Jump to solution

Kernel Security Check Failure after Updating Host to Windows 10 Build 18290 [Skip Ahead]

The computer just crashes wish the Green Screen of Death showing the error KERNEL_SECURITY_CHECK_FAILURE anytime I try to run a Virtual Machine, no matter which guest operating system I try to run.

Same problem with VMWare Workstation 14 and 15.

20181201_221028.jpg

32 Replies
briantimp
Contributor
Contributor
Jump to solution

I also experience this issue on my Surface Book 2 with Vmware Workstation 15.0.2 and 14.1.5 on Windows 10 Enterprise 18298.1000 but i have a desktop running with Vmware Workstation 14.1.5 and Windows 10 Enterprise 18290 which is running fine. I'm going to update my desktop to 18298 and see if the problem stay away there.

Edit: So i did upgrade the desktop machine to 18298 and it's running Vmware Workstation 14.1.5 without any problem.

0 Kudos
dosmond
Contributor
Contributor
Jump to solution

Did  you ever get a working solution?

0 Kudos
briantimp
Contributor
Contributor
Jump to solution

No not at this moment. I'm thinking of opting-out from the Insiders ring on my Surface Book so i hope VMW will start working again. Currently using Hyper-V and that is horrible...

0 Kudos
dosmond
Contributor
Contributor
Jump to solution

I am on an Alienware running Win 10 Pro and per WS 15.0.2 build-10952284 using Windows 10, 64-bit  (Build 18298) 10.0.18298 and was fine till I upgraded to 15.0.2.  Saw a note about repairing MS Visual C++ 2015 redistribution and that did not help. 

Host Name:                 OSMOND-17R4

OS Name:                   Microsoft Windows 10 Pro Insider Preview

OS Version:                10.0.18298 N/A Build 18298

OS Manufacturer:           Microsoft Corporation

OS Configuration:          Standalone Workstation

OS Build Type:             Multiprocessor Free

Registered Owner:          N/A

Registered Organization:   N/A

Product ID:                00330-50402-32962-AAOEM

Original Install Date:     12/11/2018, 4:28:44 PM

System Boot Time:          12/19/2018, 11:23:32 AM

System Manufacturer:       Alienware

System Model:              Alienware 17 R4

System Type:               x64-based PC

Processor(s):              1 Processor(s) Installed.

                           [01]: Intel64 Family 6 Model 158 Stepping 9 GenuineIntel ~2800 Mhz

BIOS Version:              Alienware 1.5.0, 9/10/2018

Windows Directory:         C:\WINDOWS

System Directory:          C:\WINDOWS\system32

Boot Device:               \Device\HarddiskVolume3

System Locale:             en-us;English (United States)

Input Locale:              en-us;English (United States)

Time Zone:                 (UTC-05:00) Eastern Time (US & Canada)

Total Physical Memory:     16,257 MB

Available Physical Memory: 8,842 MB

Virtual Memory: Max Size:  18,689 MB

Virtual Memory: Available: 7,644 MB

Virtual Memory: In Use:    11,045 MB

0 Kudos
briantimp
Contributor
Contributor
Jump to solution

Windows 10 Insider Preview 18305.1000 is just released and they tell me that this build will fix the Kernel Security Check Failure issue. Installing at this moment, will let you know.

jemibu
Contributor
Contributor
Jump to solution

I spoke with a tech from VMWare Support today (who is awesome, BTW) and he said he's going to bring this up at their engineering/support meeting next week. He saw this forum and the Feedback Hub details and was genuinely interested in showing his engineering team.

If 18305 doesn't resolve the issue then at least the right people know about it.

briantimp
Contributor
Contributor
Jump to solution

Yes, for me the latest insider build resolved the issue!

SimArchitect
Contributor
Contributor
Jump to solution

Yes! Windows 10 Build 18305 solved the problem! Now I just hope we can update the clients  

Yay!!!

pastedImage_2.png

0 Kudos
jemibu
Contributor
Contributor
Jump to solution

18305 worked on my Surface Book! :smileygrin: Awesome!!

I will test on my workstation tonight but I'm pretty confident this will fix it.

0 Kudos
remko_
Enthusiast
Enthusiast
Jump to solution

18305 fixed it for me as well, just wondering if it was a bug in the previous flight or an upcoming security feature that will return in the future?

0 Kudos
Scillonian
Hot Shot
Hot Shot
Jump to solution

18305 fixed it for me as well, just wondering if it was a bug in the previous flight or an upcoming security feature that will return in the future?

The issue with the previous two builds might be related to the new Windows Sandbox feature (available in Pro and Enterprise editions) released with 19H1 Build 18305. I'm running Workstation on Windows 10 Pro Insider Preview (Fast Ring) on a Core i5-2350M (a 2ND generation Core i5 processor) which did not have any GSODs with 19H1 18290 and 18298.

At present, for myr system anyway,  the Windows Sandbox feature was not installed by default. However once installed VMware Workstation (15.0.2 in my case) would no longer run VMs giving an error message that Credential Guard/Device Guard needs to be disabled. Uninstalling the Windows Sandbox and a reboot allowed Workstation to run VMs again.

Scillonian
Hot Shot
Hot Shot
Jump to solution

The link below is to an article about how Windows Sandbox works by a member of the Windows Sandbox Team:

https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/Windows-Sandbox/ba-p/301849

jemibu
Contributor
Contributor
Jump to solution

That's a good find. It sounds plausible.

Sandbox is off on my laptop with 18305, where previously build 18290 was green screening. I wonder if MS simply turned off sandbox by default in this build for a quick fix.

Edit: I got the derp out my britches and just tested it. I turned on sandbox in 18305 and it now presents an error:

VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard. Please visit http://www.vmware.com/go/turn_off_CG_DG for details

So maybe the root is CG/DG. I'm not going to go down this branch of troubleshooting. That KB has been out for a while so I'm sure it's in some engineer's stack of to-dos. I'll just turn off sandbox and be mindful of this next time VMware GSODs my workstations :smileyangry:

0 Kudos