Do you guys know how to disable all CPU mitigations in Windows?
- Thread starter ttx9
- Start date
There's two workarounds available:
1. From the Components screen, remove System / Processor microcode update - Servicing
2. From the Registry screen, add this reg file:
Obviously you're trading improved performance for less CPU security, since the exploits are already out there.
1. From the Components screen, remove System / Processor microcode update - Servicing
2. From the Registry screen, add this reg file:
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverride"=dword:00000003
"FeatureSettingsOverrideMask"=dword:00000003Obviously you're trading improved performance for less CPU security, since the exploits are already out there.
- Messages
- 1,203
- Reaction score
- 237
Since a Windows update (summer 2025), it's these values now
Code:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverride"=dword:2000003
"FeatureSettingsOverrideMask"=dword:00000003The 00000003 value "disables" CPU threads in Windows, since that update
At the time, when I tested it with benchmarks, removing Processor microcode update - Servicing didn't change performance, unlike modifying the registry.
But since certain microcode (BIOS) updates, the gains are less significant than before.
What about
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationAuditOptions"
"MitigationOptions"
?
I have set them all to zero and/or deleted them and didn't notice any change, but I haven't measured too strictly.
Also in IFEO...
What about security? I put my hopes in double (reverse) Security Through Obscurity -> No attacker expects these "defences" to be disabled, but I enjoy better performance.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationAuditOptions"
"MitigationOptions"
?
I have set them all to zero and/or deleted them and didn't notice any change, but I haven't measured too strictly.
Also in IFEO...
What about security? I put my hopes in double (reverse) Security Through Obscurity -> No attacker expects these "defences" to be disabled, but I enjoy better performance.
Last edited:
- Messages
- 1,203
- Reaction score
- 237
Did you use the value "00000000" ?
You need to test with the correct value.
I was also modifying the mcupdate_GenuineIntel.dll file so that Windows would only "take into account" the BIOS microcode.
Otherwise, Windows uses the more recent version of the microcode between that file and the BIOS.
I haven't done any testing in a long time, and the latest microcode revisions are better than the first ones after that famous patch.
But in normal use, the difference isn't really noticeable, it's more apparent in benchmarks.
As for security, I figure if someone wants to "hack" your PC, they'll always find a way.
EDIT : But to get the true performance, you need to use a BIOS with the microcode from before this modification.
That's where I really see the difference in benchmarks with the modded BIOS.
You need to test with the correct value.
I was also modifying the mcupdate_GenuineIntel.dll file so that Windows would only "take into account" the BIOS microcode.
Otherwise, Windows uses the more recent version of the microcode between that file and the BIOS.
I haven't done any testing in a long time, and the latest microcode revisions are better than the first ones after that famous patch.
But in normal use, the difference isn't really noticeable, it's more apparent in benchmarks.
As for security, I figure if someone wants to "hack" your PC, they'll always find a way.
EDIT : But to get the true performance, you need to use a BIOS with the microcode from before this modification.
That's where I really see the difference in benchmarks with the modded BIOS.
Last edited:
Binary values, I edited them in place. "MitigationAuditOptions" & "MitigationOptions".
What about
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationAuditOptions"
"MitigationOptions"
?
I have set them all to zero and/or deleted them and didn't notice any change, but I haven't measured too strictly.
Also in IFEO...
What about security? I put my hopes in double (reverse) Security Through Obscurity -> No attacker expects these "defences" to be disabled, but I enjoy better performance.
If I recall correctly, 22 is disable. 00 tells Windows to use the default. Like this:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationOptions"=hex:22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,\
22,22,22,22,22,22
"MitigationAuditOptions"=hex:22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,22,\
22,22,22,22,22,22,22,22
NOTE: The number of options in that field has changed over the years, so that exact reg may not match your build.
Of course, that's why I only edited it directly, and later abandoned it, because I couldn't find solid reference, and (as far as I can remember) some programs/windows components stopped working with everything turned off.
Like seen here:
GitHub - WildByDesign/GFlagsX: Enhanced version of the GFlags tool
Enhanced version of the GFlags tool. Contribute to WildByDesign/GFlagsX development by creating an account on GitHub.
github.com
(MitigationOptions-RS3.xlsx)
and here:
Release GFlagsX (2018-01-24) with source · WildByDesign/GFlagsX
GFlagsX (2018-01-24) with source Black Theme this build only adds an all Black Theme slightly polished up button spacing, etc. still NOT compatible with Windows 10 RS3 REG_BINARY MitigationOptions...
github.com
and the project it was forked from.
I seem to recall seeing a powershell or bat script that would determine how many of MitagationOptions fields were available in any particular build. It's also my understanding that setting them makes them the default for the kernel and system wide, but they can be changed on a per program level through Image File Execution Options. I've had all of mine turned off for 5 years now on Windows 10 and the only issue I ever had was a game called Valorant. The anticheat requires two bits turned on (with 3 instead of 2), and I do so via IFEO.
Whether it's prudent to do so is another debate, but the original poster expressed the desire to turn off all mitigations.
Whether it's prudent to do so is another debate, but the original poster expressed the desire to turn off all mitigations.
What's frustrating is the bitmask pool is divided into two different groups:
For the longest time, if you waded through all the stupid KB articles (they multiply like rabbits), most of them end with 0x3 & 0x3 as "disable all mitigations". It looks like they randomly threw in 0x200000 as "disable Downfall".
- Mitigations which are enabled by default, and need a bit flipped to disable them
- Mitigations which are disabled by default, and need a bit flipped to enable them
For the longest time, if you waded through all the stupid KB articles (they multiply like rabbits), most of them end with 0x3 & 0x3 as "disable all mitigations". It looks like they randomly threw in 0x200000 as "disable Downfall".
I guess I picked the "zeroes=off" logic from here (or from similar pages from that time).
But I can definitely feel the performance difference when I turn off everything manually through GUI in Defender (exploit guard). Of course, it is well known that VBS takes a great performance hit, but no one can agree about the percentage. And it's not only VBS there.
I am also sure I could feel the difference between DEP on and off in XP days, although many swore they couldn't.
What I am not sure of, is whether when I take out Defender with NTLite, do these kernel settings remain or not (does it use defaults or not; and how to turn them off). I think that's worth investigating for NTLite usage.
But I can definitely feel the performance difference when I turn off everything manually through GUI in Defender (exploit guard). Of course, it is well known that VBS takes a great performance hit, but no one can agree about the percentage. And it's not only VBS there.
I am also sure I could feel the difference between DEP on and off in XP days, although many swore they couldn't.
What I am not sure of, is whether when I take out Defender with NTLite, do these kernel settings remain or not (does it use defaults or not; and how to turn them off). I think that's worth investigating for NTLite usage.
Last edited:
Necrosaro
Well-Known Member
- Messages
- 690
- Reaction score
- 271
I have always remove defender. Haven't had a malware or infection on my PC in probably over 15 years. I also turn off DEP and any other security measures. I feel why have it when I haven't had a issue in such a long time.
If someone really wants to get in they will figure out a way but most usually want the bigger fish(business) and not the smaller ones
Anonymous Internet User
Active Member
- Messages
- 176
- Reaction score
- 30
I just did this and the Geekbench 5, Geekbench 6 and Passmark results are nearly identical before and after adding these Registry entries.
This. Though I am not going to mess with my firmware, not worth it. My mobos have the latest firmware and I know all those mitigations have been added in the few latest releases. I have not noticed any performance drops after those BIOS updates in the last few years anyway. From what I've read the loss was nowhere near the levels people were freaking out about. Intel said something 30% or more perf loss from Downfall mitigations but it was more like 10% in few extreme and very specific use cases. And even 10% does not translate into something you can actually feel in real life use.
Also, these may affect older CPUs more. I doubt newer CPUs will see any real benefits.
Same goes for DEP: zero difference disabled versus enabled.
I even played around with a no-Defender Windows 11 build last year and I saw no tangible improvements even on older, unsupported CPUs like i5-6500.
So, interesting as a nerdy experiment, pointless under real use.
Damn, I just want the Explorer to be faster, LOL
- Messages
- 1,203
- Reaction score
- 237
Yes, Intel has managed to restore almost the performance levels to before those "patches"
Since I have 2 BIOS on my motherboard, I have one with an older microcode version (2017 or 2018, I can't remember exactly) for benchmarks, best OC, etc...
Since I have 2 BIOS on my motherboard, I have one with an older microcode version (2017 or 2018, I can't remember exactly) for benchmarks, best OC, etc...
Hi. Could you please elaborate on how exactly did you modify mcupdate_GenuineIntel.dll? Also if it's the same for mcupdate_AuthenticAMD.
- Messages
- 1,203
- Reaction score
- 237
Since Windows 11 24h2, for an Intel CPU, you delete (or rename as you wish) the mcupdate_GenuineIntel.dll file and rename the mcupdate_AuthenticAMD.dll file to mcupdate_GenuineIntel.dll
Do the opposite with an AMD CPU.
Alternatively, you can also use a empty .txt file, eg, that you rename to mcupdate_GenuineIntel.dll (with the .dll extension) for Intel
And mcupdate_AuthenticAMD.dll for AMD
And in NTlite, you just need to keep the "Processor microcode update (xxxx)" component associated with the CPU
=> Processor microcode update (AMD) for AMD, eg
If you want to "mod" the DLL, it's best to rename it afterwards
Last edited:
I did this and the registry modification listed by you above. Does the "FeatureSettings" not need a specific value as well? The problem is STIBP remains enabled which is the main performance hog. Even the earliest bios that supports ryzen 5000 still has this component. Have you tried removing it directly from the bios? Does it not brick the bios? I have flashback option in case it bricks it but still... I found 2 instances of Stibp file on my bios with MMTool.