I have been a member of the Windows Insiders group since 2014, and have enjoyed testing out the updates and looking at some of the new features coming to a new Win10 release in due course. A very few Insiders builds were bad - and just did not work. But that was rare and for the most part, the new builds work well.
I recently encountered an issue whereby after the upgrade, no Hyper-V VM would start. The error log shows an error message about MCompute faults - which looks like this in the event log.
Faulting application name: vmcompute.exe, version: 10.0.21354.1, time stamp: 0x1aa49b37
Faulting module name: vmcompute.exe, version: 10.0.21354.1, time stamp: 0x1aa49b37
Exception code: 0xc0000005
Fault offset: 0x00000000001c065a
Faulting process ID: 0x23a8
Faulting application start time: 0x01d72d3e4d15903d
Faulting application path: C:\WINDOWS\system32\vmcompute.exe
Faulting module path: C:\WINDOWS\system32\vmcompute.exe
Report ID: f8375064-c2fc-4a89-a8f1-af662c551008
Faulting package full name:
Faulting package-relative application ID:
I reported this error multiple times, but to no avail. Every week, Windows Update would offer a new build that would fail to restart Hyper-V.. I'd revert to a working build, report the issue - then wait a week and repeat. Despite multiple reports, I never got any response from MSFT.
I decided to take a near-nuclear option - which worked! In hopes that someone else who encounters this issue and, using their search engine, finds this post - here is my solution:
- Start, then shut down all VMs.
- Took an inventory of the VMs.
- Remove all the un-needed VM snapshots - there were too many and all are now gone!
- Export all the VMs to a backup drive (removing the snapshots helped reduce the time).
- Remove the Windows 10 Hyper-V feature - all of it.
- Accept the latest Insiders update and let it install.
- Once the upgrade is complete, add the Hyper-V feature back in.
- Open up the Hyper-V console and install the necessary VM switches (two in my case).
- Import the VMs specifying the location on the VM location on the host's disk of the VM (and not the backup!).
- For some VMs< i need to specify where the virtual hard disks were stored (I use a non-standard location).
- Start the VMs and enjoy.
PS C:\Foo> Get-VM | Format-Table -Property Name, PathName Path---- ----***Cookham1 D:\VMs\Cookham1CH1 D:\V8\CH1DC1 d:\v8\DC1DC2 d:\v8\DC2HV1 D:\V8\HV1HV2 d:\v8\HV2Hyper-V Server D:\V7\HyperVServer\Hyper-V ServerOld - Bridge D:\V7\BridgePSRV D:\V8\PSRVSMTP-2019 D:\V8\SMTP-2019\SMTP-2019SRV1 D:\V8\SRV1SRV2 D:\V8\SRV2SS1 D:\V8\SS1
After all the updating, in step 11, I pointed the MMC's import wizard at the path noted above and most of the VMs came in fine. For the "V8" VMs, I had to specify the same path to let the wizard know where each of the disks was stored.
Hope you never encounter this issue but if you do the is a workaround.