Enabling Hyper-V causes continuous reboot

[updated 9/24/2015]

This is a post that I am getting out to pull together a symptom that I am seeing in the TechNet forums and is spread across multiple threads.

I will be updating this thread as I follow things unfolding.  If you have this issue, please follow this post or the thread I mention below.

The current take aways:

• BIOS / chipset
• NIC / drivers

A bit of background; Hyper-V takes advantage of hardware virtualization features.
As new releases come out it is not unusual for the platform to take advantage of some hardware feature that is not properly or fully implemented in hardware.  This has played in historic releases.

Now, I am not being critical by pointing that out.  What is am saying is this:
Step 1: check for BIOS updates from your system / motherboard manufacturer and update the BIOS.

As revealed in this thread:  Windows 10 x64 Pro infinite reboot loop with Hyper-V enabled this pattern has played out again.

This thread has been deleted for some reason.  Unknown as to why or by whom.

There is a new hardware feature that has been implemented with Windows 10: IOMMU

According to Wikipedia, iommu is a memory management feature that is present in both Northbridge and Southbridge Intel processors.

Quite honestly, I see folks with i7's reporting this problem.

 

That said, I have long mentioned that manufacturers release processors in families.  And within a family a feature may exist, but not across all processors in the family.  So you must always check your particular chipset with the manufacturer to ensure that your chipset actually implemented the feature that you think you have.

 

Manufacturers do this so that they can offer a range of prices for end products.  Be mindful of that.

 

I bring that up because I cannot tell you hoe many times I have helped folks wit an issue that turned out to be related to them thinking they have a feature (the motherboard implemented it) but the chipset actually lacked it (the particular processor they had didn't implement it, but the processor family did).

 

Now, here is the latest advice from MSFT folks:

 

There is a known issue where the machine will fail to boot when Hyper-V is installed but DEP/NX/XD is disabled in BIOS. You mentioned that you have enabled these options, but you are continuing to see the same problem.

One other thing we can try is disabling the IOMMU policy and see if that helps. (The hypervisor's usage of the IOMMU device by default is new in Windows 10, and might explain why you are seeing this only on Windows 10).

You can disable IOMMU usage by the hypervisor by running the following command from an elevated cmd window & rebooting your machine:

bcdedit /set {default} hypervisoriommupolicy disable

Can you try this and let me know if it helps?

If you can also share msinfo32 information with us, that will be helpful with the investigation.

• One poster reported resolution when they simply disabled Data Execution Prevention and enabled it again (this requires a cold boot).

That said, iommu has (actually) been around for a long time.  And, most likely has not been taken advantage of, so I can understand the recommendation of disabling it in the bootloader.
That said, when do you set it?  Before or after enabling Hyper-V?
Did you update your BIOS?

As MSFT reports this issue to manufacturers, the BIOS update will become more relevant.
If you want to understand how important this is, search the Hyper-V forum for "Sony Viao" - Sony chose to release a system that reported chipset virtualization as being enabled, when in fact it was not.

Step 2: Check your network card drivers.

This one was a surprise.  Now, the networking stack has been undergoing an overhaul over time.  And in this release there are some big changes under the hood (that are pretty much hidden).

That said, recent reports are that rolling back to older versions of Network drivers can al alleviate this issue.

Here is the report from one recent poster in TechNet:

thanks for sharing your experience with Hyper-V on Windows 10 and the Broadcom wireless driver because it looks like you helped find a solution I could use in the meantime that does not crash/BSOD the Dell Precision M3800 laptop.
I used "Update Driver">"Browse My Computer">"Let me pick from a list of device drivers on my computer" to list the drivers on my machine and I happened to have a 6.x version of the driver already on my machine.
Specifically I changed drivers from/to:
-- Before -- "Dell Wireless 1560 802.11ac Version: 7.35.295.0 [7/30/2015]"
 -- After -- "Dell Wireless 1560 802.11ac Version: 6.30.223.259 [11/28/2014]"
After picking the 6.x driver I reinstalled the Hyper-V role, created a Virtual Switch(had to do it twice) and added it to the imported VM. I've been working with it all day and haven't had a BSOD/crash yet.

This is interesting, as most likely, you got new drivers through the upgrade process.  And MSFT most likely got them from Dell, or Broadcom, or Intel.

This said, Broadcom drivers do have a long and sordid history with Hyper-V and I generally stick with the in-box delivered drivers as those are usually the ones tested.  But this entire upgrade process is new, and if the virtual switch existed prior to the upgrade it would have one set of capabilities (copied form the physical NIC) and the new driver would give a different set of capabilities.  There is obviously some incompatibility here.