Resolving Hyper-V issues with WIn10 Insiders builds

 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:

1. Start, then shut down all VMs.
2. Took an inventory of the VMs.
3. Remove all the un-needed VM snapshots - there were too many and all are now gone! 
4. Export all the VMs to a backup drive (removing the snapshots helped reduce the time).
5. Remove the Windows 10 Hyper-V feature - all of it.
6. Reboot.
7. Accept the latest Insiders update and let it install.
8. Once the upgrade is complete, add the Hyper-V feature back in.
9. Reboot.
10. Open up the Hyper-V console and install the necessary VM switches (two in my case).
11. Import the VMs specifying the location on the VM location on the host's disk of the VM (and not the backup!).
12. For some VMs< i need to specify where the virtual hard disks were stored (I use a non-standard location).
13. Start the VMs and enjoy.

Here is what I see now!

Once you are up and running, make sure to remove the backups.

From start to finish, it took me a couple of days elapsed time (the backup to an external USB2 drive was slow!). 

In step 2, I took inventory (including identifying the snapshots and working out how much data had to be backed up. One useful step wasn running this query and saving the output. 

PS C:\Foo> Get-VM | Format-Table -Property Name, Path

Name           Path

----           ----

***Cookham1    D:\VMs\Cookham1

CH1            D:\V8\CH1

DC1            d:\v8\DC1

DC2            d:\v8\DC2

HV1            D:\V8\HV1

HV2            d:\v8\HV2

Hyper-V Server D:\V7\HyperVServer\Hyper-V Server

Old - Bridge   D:\V7\Bridge

PSRV           D:\V8\PSRV

SMTP-2019      D:\V8\SMTP-2019\SMTP-2019

SRV1           D:\V8\SRV1

SRV2           D:\V8\SRV2

SS1            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.