[Windows 10] Possible fix for stuttering/hangs/poor FPS in VR (Maybe non VR too)

[Cutesune]

Bottom line up front: Tweak Windows Exploit Control

1. Go to Start Menu, start typing 'Exploit'
2. Click "Exploit Protection" from the list that appears
3. Click "Program Settings"
4. Click "Add program settings to customize", "Choose Exact Path"
5. Find the NMS executable (Steam folder, No Man's Sky/Binaries/NMS.exe)
6. Find NMS in the list, click 'Edit'
7. Scroll down the list, and override Flow Control Guard and Data Execution Prevention, disable both.
8. ????
9. PROFIT



Explanation

Like a lot of users I've been experiencing a lot of stuttering, especially during low altitude flight. I'd also been experiencing problems where the VR headset would become increasingly stuttery and even hang during busy scenes, this got worse over time and I'd have to restart the app every hour or two.

After a lot of analysing the graphs from the VR compositor, processor overhead etc. I couldn't narrow down the problem to either the graphics pipeline OR NMS itself; it was like each tick in the application was being delayed and slowed down by an outside process.

I mentioned this offhandedly to my husband, who incidentally works in cyber security. And he pointed out he'd seen similar issues caused by Flow Control/DEP in Window's new exploit protection system and suggested disabling them.

And, lo and behold, it worked! - No stuttering, hangs, consistent framerate for hours of uninterupted play.

This might not be the case for everyone, but in SOME cases this might be the problem.



EDIT:

Yes this could hypothetically pose a security vulnerability. Though the jury is out on the severity of the risk. Some people have said it is an existential threat to your system and the fix should not be attempted.

Others are pretty sure that an attacker would have to first get access to your system via another means, and then scan the whole system for vulnerabilities, or to know in advance exactly where to target their attack, and thus poses minimal risk if the rest of your defences are up to date and in place.

Nonetheless, I feel it's worth adding a disclaimer that you do so at your own peril, and if you do, please make sure the rest of your defences are in order.

[Aver]

Interesting. Will try it for sure when I get back from work. Thank you!

[Winterpants]

Originally posted by Ryuujin:

Bottom line up front: Tweak Windows Exploit Control

1. Go to Start Menu, start typing 'Exploit'
2. Click "Exploit Protection" from the list that appears
3. Click "Program Settings"
4. Click "Add program settings to customize", "Choose Exact Path"
5. Find the NMS executable (Steam folder, No Man's Sky/Binaries/NMS.exe)
6. Find NMS in the list, click 'Edit'
7. Scroll down the list, and override Flow Control Guard and Data Execution Prevention, diable both.
8. ????
9. PROFIT



Explanation

Like a lot of users I've been experiencing a lot of stuttering, especially during low altitude flight. I'd also been experiencing problems where the VR headset would become increasingly stuttery and even hang during busy scenes, this got worse over time and I'd have to restart the app every hour or two.

After a lot of analysing the graphs from the VR compositor, processor overhead etc. I couldn't narrow down the problem to either the graphics pipeline OR NMS itself; it was like each tick in the application was being delayed and slowed down by an outside process.

I mentioned this offhandedly to my husband, who incidentally works in cyber security. And he pointed out he'd seen similar issues caused by Flow Control/DEP in Window's new exploit protection system and suggested disabling them.

And, lo and behold, it worked! - No stuttering, hangs, consistent framerate for hours of uninterupted play.

This might not be the case for everyone, but in SOME cases this might be the problem.

Very nice, thank you, just tested this in VR and I have zero stutters now, super smooth.

Big thank you to you and your husband for this one.

[Sir Kruntington]

Originally posted by Ryuujin:

Bottom line up front: Tweak Windows Exploit Control

1. Go to Start Menu, start typing 'Exploit'
2. Click "Exploit Protection" from the list that appears
3. Click "Program Settings"
4. Click "Add program settings to customize", "Choose Exact Path"
5. Find the NMS executable (Steam folder, No Man's Sky/Binaries/NMS.exe)
6. Find NMS in the list, click 'Edit'
7. Scroll down the list, and override Flow Control Guard and Data Execution Prevention, diable both.
8. ????
9. PROFIT



Explanation

Like a lot of users I've been experiencing a lot of stuttering, especially during low altitude flight. I'd also been experiencing problems where the VR headset would become increasingly stuttery and even hang during busy scenes, this got worse over time and I'd have to restart the app every hour or two.

After a lot of analysing the graphs from the VR compositor, processor overhead etc. I couldn't narrow down the problem to either the graphics pipeline OR NMS itself; it was like each tick in the application was being delayed and slowed down by an outside process.

I mentioned this offhandedly to my husband, who incidentally works in cyber security. And he pointed out he'd seen similar issues caused by Flow Control/DEP in Window's new exploit protection system and suggested disabling them.

And, lo and behold, it worked! - No stuttering, hangs, consistent framerate for hours of uninterupted play.

This might not be the case for everyone, but in SOME cases this might be the problem.

I don't know if you're the one who pointed this out on Reddit, but I saw it this morning and gave it a shot. Now, I need to do better testing (I sloppily changed a bunch of significant things at once so it's hard to directly compare to my previous recordings), but I just flew around while recording, and experienced the smoothest, most stutter free gameplay in NMSVR yet (for me), and it was at default Rift S resolution, all settings on Enhanced, aniso at 4, TAA (low), HBAO off, and on what has been a pretty punishing planet.

I don't want to get everyone's hopes up just yet. Combined with the latest build it seemed like a pretty stark difference, especially since I'm used to testing at 20% resolution and lowest in-game settings. Again, I'd like to make some more careful direct comparisons, but it really does seem like something has improved significantly. Give me a few minutes to upload my recording, and then I'll post more details about exactly what I changed and perhaps some things I need to do next to be more careful and make better direct comparisons.

Edit: Forgot something. Thank you for posting this and a big thanks to your husband. This is interesting and waaaaay off my radar, so I would never have stumbled into it.

[Sir Kruntington]

Here's the video: https://youtu.be/ZF_5uAM2PzY

Now let me explain:

1. In-game settings are all Enhanced, Aniso 4x, TAA (low), HBAO off
2. Steam SS is at 100% (Rift S)
3. ASW is set to 45 in OTT*
4. I checked "Override system settings" for Control Flow guard (CFG) in Exploit protection.**
5. I installed Intellegent standby list cleaner (ISLC)***

*The reason ASW is set to 45 in OTT is because is I leave it to Auto, then there are additional stutters that are related to the game switching into reprojection when 80fps (12.5ms) cannot be acheived. These particular stutters are related to but seperate from the CPU frametime spike stutters, but they seem to compound on each other because usually, it seems, the frametime spikes slam frametime to the ground, so reprojection is activated (which has a slight stutter of its own), but frametime get's pushed low enough that the system can't even maintain half-refresh (40fps in Rift S), and so the reprojection-on stutter gets amplified by larger stutters caused by failing to even maintain reprojection frametimes. Forcing constant reprojection, therefore, eliminates a part of the problem. It's not ideal, but the experience ends up being far smoother than if I let the system manage reprojection on its own. In other words, it helps specifically isolate the CPU frametime induced stutter, which usually is bad enough to drop all the way down below half-refresh (40fps).

**I recorded this before I saw your post here and had only seen anything about Control Flow guard through Reddit. For this video I had not played with Date Execution Prevention (DEP). That remains untested for me.

***Additional research led me to a recommendation for a similar sounding stutter problem to Intelligent standy list clearner and I was just in the mood of throwing ♥♥♥♥ around to see what sticks. Ideally I would test one change at a time, but I just wanted to play around and see if anything changed at all.

Now that that's all out of the way, I need to disable Intelligent standby list cleaner and test with just CFG, and then just DEP, and then both. Then see if ISLC contributes anything at all. As it stands, my experience of the gameplay was improved but I can't personally say exactly what caused what because I was so sloppy and careless about it.

In the video you'll notice that CPU frametime still pops above 12.5ms, but as long as frametime doesn't go very far above 12.5ms, I don't see any stuttering as a result, because ASW forced on is hiding any stutter transition that would otherwise be there. Now, I still noticed stutters, and the stutters I noticed are correlated with CPU frametime far exceeding 12.5ms (the bars go all the way to the top). What I suspect is going on in those cases is that frametime isn't merely hitting the 16ms mark of the graph, but is going waaaaaay up above that and the graph just maxes at 16ms. Those are the spikes that drop me even below my forced reprojection half-refresh, and thus below 40fps. It's those CPU spikes that I see as a stutter, and since they're below half-refresh, reprojection simply cannot do anything about them. If those can be eliminated then we could hope to hold at least constant 40fps, and even though we'd have to play in constant reprojection, we wouldn't see disruptive stutters.

It's also worth pointing out, again, that the highest CPU frametime spikes (the ones that are very likely going waaaaay above the 16ms limit of the graph) are correlated with me slowing the ship all the way down near vegetation, and thus seem correlated to the game loading or generating assets for that particular location. I don't really get those stutters when I'm flying fast, even if low, because it seems none of the little details are loaded in. They only load when I slow and am also low enough for them to load.

[aggromagnet]

Yeah...someone worth their salt in cyber security wouldn't suggest messing with those on a network connected PC, regardless of whatever performance increases you may/may not actually be seeing by doing so. Especially not CFG...lol...

This is one of the ways people with good intentions end up being unwitting members of botnets and the like.

[Sir Kruntington]

Originally posted by flesyMeM:

Yeah...someone worth their salt in cyber security wouldn't suggest messing with those on a network connected PC, regardless of whatever performance increases you may/may not actually be seeing by doing so. Especially not CFG...lol...

This is one of the ways people with good intentions end up being unwitting members of botnets and the like.

No argument there. To the extent this helps, which is cool, it's a horrible fix for this problem.

[GhostUrsa]

Interesting stuff. I'll explore this at home later. Anyone forward this over to Hello Games yet? As @flesyMeM mentioned above, this stuff isn't ideal to leave off. If No Man's Sky is clashing with this process, maybe the devs can do something about it so we don't need to worry about overriding network security to play.

[aggromagnet]

Originally posted by Sir Kruntington:

Originally posted by flesyMeM:

Yeah...someone worth their salt in cyber security wouldn't suggest messing with those on a network connected PC, regardless of whatever performance increases you may/may not actually be seeing by doing so. Especially not CFG...lol...

This is one of the ways people with good intentions end up being unwitting members of botnets and the like.

No argument there. To the extent this helps, which is cool, it's a horrible fix for this problem.

Yeah, even when CFG was causing all kinds of problems for Chromium the suggestions given weren't to turn off CFG. The suggestions were to suffer through and wait until Microshit issued a fix (which they did) or use a non-Chromium browser until Microshit issued a fix.

Most of the time when people suggest messing around with this stuff, they're the sort that know just enough to be dangerous... :P

[Winterpants]

Would I be correct in my assumption here that the risk would be lower in this case as these features have only been disabled for the NMS executable and not the entire OS? Would it be the case that NMS would have to be exploited in order to abuse the fact the feature where not running?

Or does it not matter and by disabling it for one aspect affects the entire OS?

[Sir Kruntington]

Originally posted by Maxybo:

Would I be correct in my assumption here that the risk would be lower in this case as these features have only been disabled for the NMS executable and not the entire OS? Would it be the case that NMS would have to be exploited in order to abuse the fact the feature where not running?

Or does it not matter and by disabling it for one aspect affects the entire OS?

My understanding is that the risk is lower in this case, but I'd love to hear from somebody with a much better understanding of this stuff than me. The risk could be lower, but still unacceptable given the potential downside.

[aggromagnet]

Originally posted by Maxybo:

Would I be correct in my assumption here that the risk would be lower in this case as these features have only been disabled for the NMS executable and not the entire OS? Would it be the case that NMS would have to be exploited in order to abuse the fact the feature where not running?

Or does it not matter and by disabling it for one aspect affects the entire OS?

Actually turning off DEP for NMS in exploit protection wouldn't have any effect at all, unless someone had specifically turned it on for all apps or NMS specifically (the default is just to monitor core windows apps/services).

Turning off CFG for NMS is just leaving a backdoor into your system wide open for any malware scanning your system for unprotected threads. This isn't limited to malware on your PC--it also applies to things like bad websites, otherwise good websites that unknowingly feed malware via ads, etc.

Sure, it's lower risk for NMS than for other things. But it's still unwise to mess with it.

[Cutesune]

I've now clocked about 8 hours playtime since testing out the fix and still not experienced any of the frame loss, stuttering or hangs I had on a VERY regular basis (Avg 30 minutes intervals). I'm reasonably confident to say this fix has had an effect.

Now if only they'd fix it so that NMS wasn't butting heads with parts of Windows defence mechanisms.

[goldengoose7]

I first read about this stuff in a YouTube video review of the new game called CONTROL. Apparently, these alterations helped that game's RTX performance to a very noticeable degree.

However... A lot of what is wrong with NMS's performance in the areas of stable frame rate and frame times are directly related to HG's continuing POOR optimization of their rendering engine under the Vulkan API.

Anyone familiar with Vulkan knows how amazing this API is at streamlining the runtime performance of high demand graphics calls between a CPU and GPU. However, that lauded performance has so far been lost on Hello Games' Vulkan implementation. Especially in Native 4k where even an overclocked i9 9900k and 2080ti are unable to provide a judder free experience.

So...While I would encourage those with the confidence/ability to alter these Windows 10 settings for NMS, I wouldn't be expecting to see much of an improvement compared to other games.

Improved Draw Distance, Removal of Pop-In and Judder/Hitch free frame rates are not going to come to this game until HG makes a serious effort to optimize their home made rendering engine in Vulkan.

It took them 3 years to get the OPEN GL version to provide average performance on high end rigs, so I wouldn't get my hopes up of seeing any dramatic changes to what we are currently seeing any time soon.

[SugarHiccup]

Originally posted by Sir Kruntington:

I don't know if you're the one who pointed this out on Reddit, but I saw it this morning and gave it a shot. Now, I need to do better testing (I sloppily changed a bunch of significant things at once so it's hard to directly compare to my previous recordings), but I just flew around while recording, and experienced the smoothest, most stutter free gameplay in NMSVR yet (for me), and it was at default Rift S resolution, all settings on Enhanced, aniso at 4, TAA (low), HBAO off, and on what has been a pretty punishing planet.

I don't want to get everyone's hopes up just yet. Combined with the latest build it seemed like a pretty stark difference, especially since I'm used to testing at 20% resolution and lowest in-game settings. Again, I'd like to make some more careful direct comparisons, but it really does seem like something has improved significantly. Give me a few minutes to upload my recording, and then I'll post more details about exactly what I changed and perhaps some things I need to do next to be more careful and make better direct comparisons.

Edit: Forgot something. Thank you for posting this and a big thanks to your husband. This is interesting and waaaaay off my radar, so I would never have stumbled into it.

that was me :)

I did some testing with the fix on and off and overall I am actually getting a 20% increase in performance with this trick, monitoring in OTT.

I am getting 60-65% performance headroom in stations. Before it was 40-45%.
On my base planet which doesn’t have a lot of trees but still some dense spots I am getting now 15-25% in the performance-heavier areas. Still some framedrops, esp. when doing fast turnarounds.
Also flying is such an improvement with A LOT less framedrops and between 20-40%. Unless I am flying over dense vegetation or doing sharp turns.

Settings are: everything on enhanced, 16xAF, FXAA, HBAO off, 150 SS

2080 TI, 9900K, 32 GB 3200 Mhz DDR 4 RAM

[IanL]

Anyone playing this as a single player could play in offline mode, which would reduce the risks with this fix until HG get round to sorting all this out. The only downside is your discoveries would not get uploaded to the cloud until you next connected.

Thanks Ryuujin for the shout on this, got to be worth a try in the meantime!