Hyper-V running even after being disabled

Question

Hello community,

Can you please help? What would cause Hyper-V to continue to generate logs even after the software is disabled and this feature is turned off? The adapters have been deleted from the drivers list however, with each reboot they will reinstall all the Hyper-V drivers and continue to run. Containers Gone Wild!!!

(Image: Features for Hyper-V and Virtual Platform are disabled and logs are still being generated)

(Image: Hyper-V-Compute Logs are generated and showing service started even with features disabled)

(Image: Dual Hyper-V adapters. Is there confirmed Virtual Driver Protections for dual use drivers that are seen here?)

(Image: Driver Verification Passed with the dual adapters issue)

Please do not respond with format and reinstall system OS this repair does not fix the root cause of this repeatable problem.

Please help with a response that can resolve this without a full Windows 10 software reinstall.

Is there any hardware like a security enabled network interface card that will take full control of the network bus with the main hosts software thus blocking out unauthorized access to the NIC? Again, meaning any virtualization or containers would be forced to interact with the physical software for virtualization for access to the NIC? Maybe in the future for high security appliances. . . A container security equipped network interface card.

Answer 1

Hi,

Thanks for your post in Microsoft Community.

I understand that you have encountered the problem that Hyper-V still generates logs after disabling the Hyper-V function.

The problem may be that Hyper-V is not completely shut down, you can try to run the command prompt as administrator and execute the following command:

bcdedit /copy {current} /d “windows10 no Hyper-V 

bcdedit /set {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} hypervisorlaunchtype OFF 

Then restart the computer.

Note: Replace "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX" in the second command {} with the serial number that appears in {} after the first command is executed.

If shutting down Hyper-V with the command doesn't solve the problem, I recommend you ask in Microsoft Docs. Here are professionals who know more about Hyper-V.

Please feel free to let me know how it goes.

Kirk | Microsoft Community Support Specialist

---

* Beware of scammers posting fake support numbers here.

* If your problem is not solved, you could reply to the post again and we would continue to provide technical support for you.

* Please check and vote this answer if it helps as it will be beneficial to more community members reading here.

Answer 2

Each instance of a driver followed by a number such as the "#4" in your case is actually considered a different instance, so to Windows those two virtual drivers are completely separate, even though they undoubtedly ran exactly the same driver from the drive.

This situation typically happens when something significant changes relating to the current driver and Windows decides to create a new instance to deal with the issue. In most cases careful inspection of the drivers shows that the original instance has been disabled and the latter running in its place. The really odd thing in your case is that since the second driver indicates #4, this implies that 2 other revisions of the driver had existed and been removed before the final one named with #4 was created.

So I believe there were likely multiple sets of issues that occurred before you noticed the 2 instances of the driver existed.

Rob

Answer 3

Thanks for the reply,

This command generated a boot option with every Windows 10 start that lets you choose Hyper-V or without when the computer starts.

(Image: Commands Ran)

After this was ran, I still see the dual adapters being regenerated and one service continues to run for Hyper-V.

(Image: New Boot Option enabled do to command. No change with drivers being disabled. I selected no Hyper-V)

(Image: Dual adapters that are signed still running after system booted with disabled Hyper-V option selected)

(Image: One Service for HV Host still running after reboot)

(Image: Logs continue even after new boot menu for disabled Hyper-V selected)

Thanks you again, for the reply. This helped with some trial and error testing for a resolve.

This also stopped many of the services that were originally running with Hyper-V however, one is still running, and the dual adapter continue to reinstall themselves. I also no longer have access to Google Chrome for some reason if I shut it down, any shutdown of the Chrome application once it has been in use causes issues restarting the Chrome application, I must close Chrome within task manager before restarting do to this change over. Chrome is also set to be running a trail set of software called Privacy Sandbox that uses containers similar to Windows 10 Sandbox containered software.

This partially repaired my issue.

Answer 4

Thank you again!!

One can clearly conceptualize growing concerns and issues that stem from virtualization, container use, BSD Jails, and data marshalling performed with cloned MAC or network level 2 hardware addresses. I have explained this issue to some of my Professors and the rely is, this is indeed a current and growing issue, there is currently some 3rd party container/VM scanners again sometimes they do not catch all of the issues, and even current antivirus software can not scan inside of the encrypted containers placed on the host machines. Issues like this are cutting edge for cybersecurity and continue to be a growing concern to look out for. This leaves me wondering what kind of mitigation will be needed to remedy such a problem, again what hardware and code adaptions are needed to give the physical host and its software complete control over use of the physical NIC to protect it from unapproved data marshalling.

Answer 5

Jonathan,

My own Windows 10 Go tablet that has never been operated with any of the other Hyper-V services (all set to manual) to support virtual machines, still has that single HV Host Service running.

I've confirmed this HV Host service is not running on an older desktop system upgraded to Windows 10 from 7.

My question for you is whether it's possible that within Windows Security - Device security - Core isolation, the Memory integrity setting to prevent attacks on high-security processes might have been turned On.

I ask because this is the only reason my Microsoft Go tablet likely has this HV Host Service running, as that's required in order for the Memory integrity option mentioned above to be enabled. This setting and the Hyper-V support it requires were also known to cause conflicts with older versions of 3rd-party virtualization products, because in most cases these each assumed they would have exclusive access to the virtualization hardware.

If this option was enabled, I suspect that was the primary issue and assuming the full set of Hyper-V virtual machine management had been properly uninstalled, disabling those other Hyper-V services typically wouldn't have been required.

As I understand it, Microsoft had been working in Windows 11 to remove this issue and at least allow the operation of Memory isolation under Hyper-V, while still also working in combination with other major virtualization products. This is actually required for Windows 11 to include the Intel virtualization products that support Android emulation among others, so many of the problems you're referring to actually only exist in Windows 10.

Rob