Microsoft released them. Decided to play around with virtual machines again and when launching the manager I got the error "MMC has detected an error in a snap-in and will unload it." Options are to report the error to Microsoft and shut
down MMC, or unload the snap-in and continue running. If I report the error it goes into the problem reports but as of yet there is no solution available. If I unload the snap-in and continue running I get this additional output:
Could not load file or assembly 'Microsoft.Virtualization.Client, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The module was expected to contain an assembly manifest.
Exception stack trace:
at Microsoft.ManagementConsole.Internal.SnapInClient.Microsoft.ManagementConsole.Internal.ISnapInClient.Initialize(ISnapInPlatform snapInPlatform)
at Microsoft.ManagementConsole.Executive.RunningOperationsTable.EnqueueOperation(Operation operation)
at Microsoft.ManagementConsole.Advanced.FrameworkSnapInFactory.Microsoft.ManagementConsole.Advanced.ISnapInFactory.CreateSnapIn(Int32 bookkeepingId, String snapInKey, Object& snapIn)
I tried restoring one of my earlier drive images and got Hyper-V manager working again. Unfortunately continuing to run with this image wasn't feasible as I've had too many changes in the install to apply all over again, my solution needs to be repairing
my image as it exists at the time I discovered Hyper-V was broken. The older image was useful though to use to see just what causes the break. From that restore I stepped through Windows Updates one by one, eventually finding that the fix for KB2898871,
"Security Update for Microsoft .NET Framework 4.5.1 for Windows 8.1 and Windows Server 2012 R2 for x64-based Systems" was what seemed to trigger it. Uninstalling this update on my current image does not resolve the issue. Somehow something
is hanging around that is the root cause of the problem. An additional odd thing with this is that this KB update is marked as February 2014, yet going back through my disk images I found that the problem had existed as early as December 2013, possibly
the month before. If .NET updates are cumulative then that would make sense as an earlier update that is now included in KB2898871 could have been applied before, but I don't know if the updates are designed that way. I have yet to find any information
online directly relating to this problem and those that are somewhat similar haven't produced any working fix. Looking for any thoughts on this while I hope that the problem report uploaded to Microsoft is being worked on.