I have a CyberPowerPC with an Intel chip that supports virtualization. I noticed that VirtualBox is somewhat sluggish with GUI virtual machines so I decided to enable Client Hyper-V to see if that worked better. I followed the powershell instructions here. After reboot my computer wouldn't get past the three dot wheel before going to a black screen and rebooting.

I subsequently found a recovery boot screen that allowed me to boot into safe mode. I used safe mode's power shell to disable Client Hyper-V. Upon restart the system went back to normal mode without my re-enabling it (I guess that's default behavior?) and still wouldn't boot.

I checked to make sure virtualization was enabled in UEFI and it was. I tried disabling it. Still no good.

After attempting to get back into Safe Mode the computer went straight to a Restart Screen and now I'm back in normal mode.

Please Help. I don't even know how to consistently get into safe mode. I can't even reach a login screen unless it's in safe mode and I don't know how to consistently reach safe mode. My boss is in the other room and doesn't' know about the trouble I'm having. My stomach is in my throat. Panic

Right now I'm in safe mode attempting a data backup.

UPDATE: More data: Processor Intel Core i7-3820 @3.60 GHZ, 16 GB Ram, 64-bit Windows 10 Pro

Problem: Enabled Client Hyper-V via PowerShell and rebooted when prompted. Boot process reaches dot circle loading screen before cutting to black and auto-rebooting in reboot loop.

Troubleshooting Steps taken: 1) Booted into safe mode, disabled Client Hyper-V via PowerShell. Rebooted when prompted. Booted into normal mode. Result: Still see dot circle loading screen cut to black auto-reboot loop.

2) Disabled virtualization in UEFI. Result: Same

3) Re-enabled virtualization in UEFI. Result: Same

4) Booted into safe mode to backup all data. Hyper-V appears unchecked in 'Turn Windows Features on/off' menu.

UPDATE2: I noticed in msconfig.exe that there are several services labeled Hyper-V. I unchecked all of them and performed a normal boot. Result: same.

  • Do you have a Gigabyte motherboard by chance? Some people have had the same problem after enabling Hyper-V. For whatever reason, disabling the USB3 controller in the BIOS resolved the booting issue. Even if you don't have a Gigabyte motherboard it may be worth a shot.
    – DrZoo
    May 11, 2018 at 15:14
  • I am not sure what the motherboard is. Just to clarify: in UEFI I have a "Legacy USB 3.0 Support" option and have now disabled it. The UEFI says ASUS.
    – mas
    May 11, 2018 at 15:24
  • Problem did not resolve from disabling "Legacy USB 3.0 Support" option in UEFI.
    – mas
    May 11, 2018 at 15:26
  • I'm not sure if it would be the legacy option or what. I'd have to look at the BIOS. That being said, you have an ASUS motherboard and not a Gigabyte.
    – DrZoo
    May 11, 2018 at 15:27
  • How do you log in to BIOS on a UEFI machine? Is there a BIOS on a UEFI machine? I thought UEFI was replacement for BIOS.
    – mas
    May 11, 2018 at 15:29

7 Answers 7


Did you ever sort this out? I just ran into the issue while trying to run Docker in Windows 10 x64.

It's definitely being caused by Hyper-V, but I haven't discovered exactly why or how to fix it yet. What I have found though in the meantime to still be able to boot into Windows (not just Safe Mode, and obviously without Hyper-V being usable once booted) is to toggle off Hyper-V via your BCD file.

You have to be able to get to a command-line though. What I've been doing is wait for startup repair to fail, then boot into Safe Mode. From there I open up an elevated (Admin) Command-line and type this:

BCDedit /set hypervisorlaunchtype Off

Then reboot.

If you have more than 1 item in your BCD you might need to specify which item to turn hypervisor off on. You can view all BCD items just by typing:


And to specify the item to alter, just add in its ID:

BCDedit /set {<long string of numbers here>} hypervisorlaunchtype Off

NOTE: When installing Hyper-V, it apparently automatically sets that flag to "Auto" (on) in your BCD, which causes the BSOD/Boot Repair Loop. Once you get the problem sorted out, you'll need to set that flag back to "Auto" to use Hyper-V again. I always make 2 boot choices in my BCD; one with Hyper-V enabled, one with it disabled. Then I select the one I want as needed.

  • 1
    No, I never solved it and simply reinstalled windows. I can therefore not check your answer, but it sounds good and it's the only one so I'll just accept yours. ;-)
    – mas
    Dec 3, 2018 at 14:33
  • 1
    Thanks! I had the same issue and your solution works perfectly. I initially tried disabling hyper-v in safe mode, but that made it worse as the feature could not be uninstalled since windows couldn't boot doh!
    – Rado
    Jan 1, 2019 at 2:26
  • Hello, i am trying your command BCDedit /set hypervisorlaunchtype Off and after that i check with bcdedit it is still remains auto, any ideas ? Feb 14, 2020 at 8:51
  • @dhaval not really sure, I've never encountered that problem before. The best i can suggest is to be sure that you're running the command as administrator, and also confirm that you're both running the command and checking later against the exact item. Feb 14, 2020 at 9:46
  • @J.ScottElblein thank you for your answer, yes i was running command prompt as a administrator but still can't figured it out and later i found one youtube video : youtu.be/Pt6H-mqF02g that helped !! Feb 14, 2020 at 11:49

Try to restore Windows to its state before, with this procedure.

  1. Boot into recovery mode or try to boot three times to trigger automatic repair
  2. Click on Advanced Startup
  3. Click on Troubleshoot
  4. Click on Advanced options
  5. Click on System Restore
  6. Click Next
  7. Select the most recent known working restore point
  8. (Optional) Click the Scan for affected programs button to see the applications that will be removed if they're installed after the restore point was created
  9. Click Close
  10. Click Next
  11. Click Finish
  12. Reboot.


  • Just initiated system restore on a point from this morning that said Windows-Module-Install (or thereabouts) which implies to me a restore point created just before I installed Hyper-V. If that one doesn't work, can I still try it on the previous one, from yesterday morning, which says Critical System Update?
    – mas
    May 11, 2018 at 14:46
  • System restore point failed to correct the problem. Will try other restore point now. If it also fails to correct the problem, does that point to a hardware problem? Is it possible that the attempt to enable hyper-v fried something?
    – mas
    May 11, 2018 at 14:50
  • Everything is possible with computer "science". If nothing works, you will need to do Startup Repair.
    – harrymc
    May 11, 2018 at 14:53
  • Second system restore to the point created yesterday also failed to correct the problem. Startup repair says "Startup Repair couldn't repair your PC." it says there's a logfile. Going to boot into safe mode to check it. Wait. Crap. I forgot to write down it's location.
    – mas
    May 11, 2018 at 14:58
  • Would you have any advice about where to look in the logs to find the issue? I see a ton of errors for today under System log from DistributedCOM error: "DCOM got error "1084 attempting to start the service CarboniteService". Like literally thousands of them, probably 20 a second.
    – mas
    May 11, 2018 at 15:04

This worked for me once I was able to get back into Windows:

  1. Open "Window Security"

  2. Open "App & Browser control"

  3. Click "Exploit protection settings" at the bottom

  4. Switch to "Program settings" tab

  5. Locate "vmcompute.exe" in the list and expand it

  6. Click "Edit"

  7. Scroll down to "Code flow guard (CFG)" and uncheck "Override system settings"

  8. Reboot


The cause of this problem is that Windows 10 does not add the "hypervisorlaunchtype auto" entry to the BCD file when Hyper-V is switched on. That is why it will not boot. The moral of the story is: add this entry to BCDEdit BEFORE switching on Hyper-V. If you haven't (and I hadn't!) you have an unbootable Windows. The workaround is to boot up with a WinPE bootable CD (you have made one and tested it, I hope), then use Diskpart to navigate to the disk and relevant partition (the EFI partition), select this partition, assign it a letter (suppose it was J:), exit, then run BCDEdit and point it to the BCD file J:\EFI\Microsoft\boot\BCD in order to add the missing entry. The command would be

bcdedit /store J:\EFI\Microsoft\boot\BCD /set {default} hypervisorlaunchtype auto The response should be "successful". Then reboot your system. You can then use BCDEdit online in a command prompt (bcdedit /enum) to list the file; the {default} system entry should now carry the parameter hypervisorlaunchtype auto. That's it. Now Microsoft - fix this please in Windows 10!

  • The bizarre thing is that I listed the properties and it said it was on auto. I set it to off to be able to boot again. Then I set it to auto to try to debug the issue and it worked. Mind boggling. Aug 5, 2021 at 21:11

However this is not the whole answer. Windows 10 may not boot if Hyper-V is enabled even with the required BCD entry. You may have to set the BCD hypervisorlaunchtype entry to OFF to keep Hyper-V switched off and use a reliable alternative such as Oracle's VirtualBox.

  • (1) What is not the whole answer?  (2) How does one set the BCD hypervisorlaunchtype entry to OFF? … … … … … … … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. Jan 31, 2020 at 18:19

It's actually worse than that. IN Win 10 1909, even if the BCD entry is AUTO and Hyper-V is ON, system will fail to boot. The only reliable way to run Win 10 1909 is to leave Hyper-V OFF and have no entry in BCD, or the entry "hypervisorlaunchtype Off" (it may be deleted anyway).


Strange. I had the same problem with the circling dots for a day. But then I did some OSX updates in Sierra, and then it booted back into Windows 10 1909 no problem.

Not the answer you're looking for? Browse other questions tagged or ask your own question.