It’s not often that I actually install Hyper-V on a client OS, so it was only by chance that I came across a bit of a weird issue when installing it on Windows 10 1709. Obviously I performed the usual process: Virtualization was enabled in the BIOS, enabled Hyper-V in Windows Features, rebooted and it all appeared to install/enable successfully.
Launched the Hyper-V console, and the local PC wasn’t automatically selected. Odd. Added ‘Localhost’ to the view, and received an error that indicated the services may not be running. Sure enough, Hyper-V Virtual Machine Manager was running, but Hyper-V Host Compute Service (vmcompute.exe) wasn’t. When trying to launch it, I received “The service did not respond to the start or control request in a timely fashion”. Event viewer detailed the exact same error – nothing more. Awesome!
Tried it on another machine in the same environment and experienced the exact same issue. Apparently, another Adexian (Hayes) also installed Hyper-V on one of his 1709 PCs recently – and his worked fine – so what the trigger is, I’ve yet to determine. On a related note, Hayes’s machine won’t shut down since the Hyper-V install – it reboots instead (and he’s yet to find a fix for this).
Obviously it’s time for Google – and it seems to be quite a common issue with 1709. Apparently Microsoft added some additional security policies that prevents Hyper-V running in certain scenarios (usually when there’s some non-Microsoft dll’s loaded in vmcompute.exe). There’s even a Microsoft support article detailing a similar issue where the vmcompute.exe process is crashing (rather than in my case where it wasn’t even launching in the first place).
In the end, the recommended solutions I could find were pretty varied:
- Roll back to 1703 (no thanks – plus it wasn’t an upgrade)
- Uninstall Sophos (wasn’t installed)
- Uninstall any other Antivirus (McAfee installed in this instance, though anecdotal evidence suggests uninstalling it doesn’t work – didn’t try)
- Configure ‘Control Flow Guard’ in the Exploit settings of Defender to be ‘On’ (which it was)
Going with the easiest option first (configure Control Flow Guard), I figured I’d set that to ‘On’. You can find this setting under:
Windows Defender Security Center > App and Browser Control > Exploit Protection Settings > Control flow guard
For me, it was already set to ‘Use Default (On)’. Damn. Ok, so what happens if we turn it off (and reboot). Unsurprisingly, it didn’t fix the issue. What it did do though, was cause vmcompute.exe to start launching and generating a crash error (as detailed in the microsoft support article).
Given the setting is meant to be ‘On’, I decided to turn it back on and see what happens. And it works. Why? No idea!
Either way, the solution for me (on two computers) was to disable CGF, reboot, re-enable CFG and reboot again.