win10 -- a situation I think I finally resolved... windows security | Device Security | Core Isolation | Memory Integrity [on/off] > I would throw the switch to ON but it always turned itself off saying incompatible drivers, and listed 4 but no obvious updates, so I more or less forgot about it for months... Then while doing something else, I noticed the Hyper-V & VBS were ON in the msinfo32 screen, so what turned it ON, and saw that bcdedit /set hypervisorlaunchtype ON so it always started on reboot despite Memory Integrity switch being off. Then found that Cyberlock was blocking making the edit bcdedit /set hypervisorlaunchtype OFF, but it took a little while to realize Cyberlock was blocking this edit, and disabling Cyberlock allowed setting hyper-v to OFF, and then I started dealing with incompatible drivers. After checking and double-checking that win10 was not using these drivers I uninstalled them one by one, while wondering at the same time if win10 was not using them, why did they block memory integrity. Per chatgpt it was just "windows being windows"... ugh.
Then I had to deal with VMware (running fedora as VM) which prefers not to have hyper-v & VBS running on the host. So turn Memory Integrity off on host? or disable side channel mitigations in VMware, I did latter, and now I longer get that popup when I boot fedora, and overall fedora VM runs a tad smoother. Thought I'd post this since I was basically ignoring the Memory Integrity incompatible drivers because I did not know how to fix that. Chatgpt, Lumo, and Claude were helpful in resolving this, but it took several hours, and y'all can read this post in a minute or two, might help if this is an issue for you. did I make right choice -- host memory integrity ON with VMware side channel mitigations OFF??
Yes, that is generally a reasonable trade-off if your priorities are:
- keeping Windows 10 host protections stronger
- avoiding Hyper-V/VBS-related VMware slowdowns or warnings
- still running the Fedora VM acceptably
What you changed
From what you described, the final state is roughly:
- Host: Memory Integrity ON
- Host: Hypervisor/VBS active
- VMware: side channel mitigations OFF for that guest
That combination can make sense. Memory Integrity is a host security feature, while VMware’s side channel mitigation setting mainly affects how VMware handles certain speculative execution class risks inside virtualization scenarios. They are not the same protection layer.
Why VMware complained
VMware often performs best when it can use its preferred virtualization path directly. On Windows 10, when Hyper-V/VBS/Memory Integrity are enabled, VMware may have to run through Microsoft’s hypervisor framework instead of having full direct control. That can lead to:
- more overhead
- reduced performance
- compatibility warnings
- slightly less smooth VM behavior
So the smoother Fedora VM after your changes is believable.
About the driver issue
Your conclusion there is also mostly correct:
- Memory Integrity can be blocked by old or incompatible drivers even if they are not actively doing anything useful anymore
- A leftover driver package can still be present in the driver store or still be loadable by the system
- Windows checks compatibility based on the driver’s presence and ability to load, not just whether you personally use the related hardware/software
So it is not just “Windows being Windows,” although the experience often feels like that. It is more that HVCI/Memory Integrity has stricter driver requirements, and old kernel drivers are a common reason it refuses to stay on.
Did you make the right choice?
In general, yes.
If choosing between these two:
- Host Memory Integrity OFF, VMware side channel mitigations ON
- Host Memory Integrity ON, VMware side channel mitigations OFF
many security-focused users would consider your current setup the better default, because protecting the host usually matters more than enabling every optional mitigation inside VMware, especially on a personal system.
The host is the foundation. If the host is better protected, that usually has more practical value than giving up that protection just to satisfy VMware performance or compatibility preferences.
Important limitation
I would not say this is universally the “best” choice for every threat model.
Whether VMware side channel mitigations should remain OFF depends on things like:
- whether the VM is exposed to untrusted code
- whether you use the VM for browsing risky content, malware testing, or unknown software
- whether performance matters more than defense-in-depth in that guest
If this is just a personal Fedora VM for normal use, your choice is easier to justify.
If it is a high-risk lab VM, then disabling mitigations is a more meaningful security trade-off.
Practical recommendation
Your current setup is reasonable if:
- the Windows host is your primary system
- you want Memory Integrity enabled
- the Fedora VM is for normal trusted use
- you accept a small reduction in VMware’s mitigation coverage for better usability
If you want the most conservative security posture, the cleaner approach is usually:
- keep Memory Integrity ON
- keep Windows fully updated
- keep VMware updated
- only disable VMware mitigations if you actually need the performance/compatibility improvement
One caution
Be careful with advice from AI tools on low-level Windows security settings. They can be helpful for troubleshooting steps, but they sometimes blur together Hyper-V, VBS, HVCI, Core Isolation, and Memory Integrity as if they are all interchangeable. They are related, but not identical.
Bottom line
Based on what you described, keeping host Memory Integrity ON and turning VMware side channel mitigations OFF is a defensible choice, and for many home users it is the better balance than weakening the Windows host.
