fearlessfrog

EDIT: In a lot more testing with 2.7 I'm starting to think this is a hardware issue on my side. My 2080 voltage is dropping under load and it could be causing this. I'm trying out a longer soak test with a GPU stress app to make sure. Hopefully it's the case where it's not a DCS -> SteamVR issue but just something local for me, and that putting reprojection on triggered it.

For my testing in narrowing down what caused DCS to crash with reprojection, I left the WMR settings file alone and just did the changes in the steps to my forum post here, e.g. just within the UI in VR for WMR using my hand controller. If you've changed your default.vrsettings file then you could rename it and get Steam to verify files, and it will write out a new default one. My default.vrsettings is here, just ensure we're talking about the same thing X:\Program Files (x86)\Steam\steamapps\common\MixedRealityVRDriver\resources\settings\default.vrsettings I can recreate this issue in DCS 2.7 as well, so for me and my system it seems like I can't run with WMR reprojection set to 'Auto' or 'Steam app enabled' and then DCS set to 'Enabled'. It is, especially for a map like Caucasus where I can run reprojection well it's a real pain having to turn it off just to stop the crash. One extra thing I will try tonight is just doing it the 'default.vrsettings' file old way, and putting 'motionReprojectionMode' : 'Auto' in there and then not configuring anything within the WMR for SteamVR or SteamVR dashboard. I don't think it will be any better, but maybe. The downside is that everytime WMR for SteamVR updates it will now rewrite a fresh text file with default settings, as they want us to use where it is store in the SteamVR side now.

So just to be clearer, it doesn't cause the issue at the moment of changing the setting. Once it has been changed though, then within DCS doing what you're describing (module swapping etc) or playing for 10 mins+ will then trigger it 100% for me. With no reprojection on it works fine (or at the very least a lot less often, as I've only found this out a day or so ago). Yep, I agree it's probably a general timeout bug and probably not this setting specifically, but for me and my system the use of VR reprojection being on and then playing DCS allows me to recreate it every time. It's like some long pause between DCS -> SteamVR on updating a frame causes SteamVR to crash out. Perhaps VR reprojection being on just exacerbates the situation as it uses frame history to reproject? I'm just happy that I can get it to run stably now, even if I can't use reprojection. Do you not run VR reprojection with DCS? If you do (as described in my steps link to try it) then does the SteamVR crash happen quicker or more often for you?

I think I can recreate it without reinstalling Steam. Reinstalling Steam didn't fix it, it was more the settings going back to default. It seems like for me and my system, I can reliably recreate the issue by turning VR reprojection on. I've put the full steps to recreate here (I did try to post this here but had issues with images/text mixing and couldn't figure it out quickly): https://forums.mudspike.com/t/dcs-vr-steamvr-has-encountered-a-critical-error-solved/12314/67?u=fearlessfrog (this is a bit of a dupe with here, but put here as well for completeness:

I think I can recreate it without reinstalling Steam. Reinstalling Steam didn't fix it, it was more the settings going back to default. It seems like for me and my system, I can reliably recreate the issue by turning VR reprojection on. I've put the full steps to recreate here (I did try to post this here but had issues with images/text mixing and couldn't figure it out quickly): https://forums.mudspike.com/t/dcs-vr-steamvr-has-encountered-a-critical-error-solved/12314/67?u=fearlessfrog

That sounds great - thanks! Not long now.. So with my edit above, I am happy to report a full Steam uninstall and clean out files (not just SteamVR, the whole of Steam) solved this issue for me. I tried a lot of other things, so surprised that worked, but my best guess is that some sort of older VR overlay sort of utilities I must have used over the years 'broke' vrserver.exe in a way that DCS would tend to trigger - but hard to tell now it's working. I think it's still possible to get SteamVR to freeze out (like you said, jumping cockpits a lot etc, in WMR bringing up the menu if started out of order etc) but this 'It will crash after 10 mins in MP' is issue is now gone - so I'm happy.

Just to follow up on this I have some success fixing it (or at least I believe, after playing for an hour it now seems ok after days of crashes). I had to uninstall, clean out and install Steam again. As in, no files left behind at all and a fresh Steam client installation (for me on another drive). I've left the SteamVR settings all as defaults (which has defaulted back to the resolution I was using at 'Custom' before) and am using the non-beta versions of SteamVR and WMR for SteamVR. Speculation on what was causing vrserver.exe to crash with DCS like that: - Some previous SteamVR dashboard plugin from an earlier version causing an issue. I've had fpsVR, Virtual Desktop, Advanced Settings overlays installed before so perhaps that caused an issue that showed itself with DCS? I'm going to leave them uninstalled for now, but perhaps some historical issue that won't come back on a fresh install of those? - I will eventually re-enable motion reprojection (via WMR), but for now it's off. I don't think it is the reason but basically don't want to now touch it while it's working. - Some sort of file corruption, perhaps from a bad disk sector? I had certainly re-installed SteamVR before enough times so whatever it was it needed Steam completely uninstalled and re-installed. Hope that helps others who had this issue.

@Pikey - Does your experience with the upcoming DCS 2.7 help with any of this? I realize you might not be able to say in detail, but I could do with some hope on this EDIT: Just to follow up on this I have some success fixing it (or at least I believe, after playing for an hour it now seems ok after days of crashes). I had to uninstall, clean out and install Steam again. As in, no files left behind at all and a fresh Steam client installation (for me on another drive). I've left the SteamVR settings all as defaults (which has defaulted back to the resolution I was using at 'Custom' before) and am using the non-beta versions of SteamVR and WMR for SteamVR. Speculation on what was causing vrserver.exe to crash with DCS like that: - Some previous SteamVR dashboard plugin from an earlier version causing an issue. I've had fpsVR, Virtual Desktop, Advanced Settings overlays installed before so perhaps that caused an issue that showed itself with DCS? I'm going to leave them uninstalled for now, but perhaps some historical issue that won't come back on a fresh install of those? - I will eventually re-enable motion reprojection (via WMR), but for now it's off. I don't think it is the reason but basically don't want to now touch it while it's working. - Some sort of file corruption, perhaps from a bad disk sector? I had certainly re-installed SteamVR before enough times so whatever it was it needed Steam completely uninstalled and re-installed. Hope that helps others who had this issue.

Just to add that I am also having this issue. Specs: i9-9900K, 32GB, Nv2080 Win10 latest, Reverb G1. Things I've tried: - Updating from Nvidia driver 457.30 (which works pretty sweet on a 2080 still) to 465.39. Cleared DCS shader cache. - Verified all files in DCS Open Beta using 'slow verify', plus removed all mods. - Tried SteamVR latest beta and non-beta. Also WMR for SteamVR beta and non-beta. Fresh installs and reset settings. - Tried a SteamVR build from 13 months ago (v1.10.32) and SteamVR public branch for v1.15.12, both crash the same. - Checked process priority of vrcompositor etc not set from defaults. - Set manual Windows page file to 64GB over the 32GB RAM. - Turned off any CPU, GPU and memory overclocks. Prime95 stress tested with no errors for 1 hour. - Turned off USB Power Mgnt sleep mode. - Exceptions for virus checked folders for DCS installs and Saved Games\DCS. - Disabled DCS Write log (tried on or off). - Tried DCS non Open beta and Open Beta versions. - Has crashed the same on the Caucasus map, so not just Syria. Can take about 10 mins longer or so. - Tried SteamVR at 50%, 100% and 150% render resolutions with PD set to combinations of 0.5 and 1.0 - the only delay being how long it takes to crash. - I get the VR 'SteamVR has encountered a critical error' in both SP and MP, it just happens quick (sub 15 minutes) in the latter. - Crushed an eye of newt and revolved around three times, finishing facing East. My steps to recreate aren't exact, even though it would be great if they were (as I understand this is tricky to track down for QA): - Free Flight Syria, F/A-18C. Fly for 5 minutes. - Go Multiplayer and join any Syria map. - Sit in the cockpit, play with the map for 15 minutes. 'SteamVR has encountered a critical error'. The Windows app event log will contain an entry for a fault of a Buffer Overflow Exception (BEX64) in vrserver.exe as per the info in here: https://gist.github.com/fearlessfrog/c26f21fc62c6d0d52105ce8a8cedf1e2 DCS carries on happily at about 5 FPS, the headset goes black and recovers to the WMR home. There is no DCS log entry made for the crash. No other SteamVR issues on any other VR games I play on this system, just DCS causes the issue as far as I can tell. I've also logged the bug with Steam here (although got to be realistic about them helping on this, or anything really https://steamcommunity.com/app/250820/discussions/3/3172198151252196351/ I guess at this point it's worth just waiting to see if DCS 2.x upcoming helps, but wanted to say if there is anyone on the test or QA teams that wants to investigate further than I'm happy to do anything I can to provide more info. Without stability it sort of makes the game very hard to play, so quite a serious issue for those that get it.

EDIT: Just seems to be the same info as earlier in the topic. SteamVR will crash out when DCS is under load, with steps hard to reproduce.

No. They'll update here when there's a something fixed or improved: https://docs.microsoft.com/en-us/windows/mixed-reality/enthusiast-guide/mixed-reality-software#release-history

So frame timing is just sort of another way of expressing performance. If your headset is 90 Hz then that's 90 frames per second, so that's a budget of 11.1 milliseconds to render a frame (1000 / 90 = 11.1r) so you don't see a disconnect to where you are looking and DCS is drawing. DCS on more or less any system struggles to work in a budget of 11ms, as it's either the GPU struggling doing something expensive like MSAA or the CPU main thread being blocked with lots of draw calls. As you've seen, it's more realistic to try to aim for some sort of reprojection, where the budget will be 22.2r ms. WMR has an 'always on' rotational reprojection for an app that doesn't reach 90 Hz. Rotational reprojection works well, in that you can move your head around the cockpit, see 90 fps but only be rendering 45 fps. The downside is that you get 'ghosting' where if you look sideways, or at something with an aspect ratio not around the X-axis of your head, then the artifact will 'leap' between frames, i.e. you see 'juddery trees' and the like. The optional opt-in 'motion reprojection' of WMR [1] helps with this, and is like Oculus's ASW and SteamVR's reprojection. For this to work well you need about 60 fps or a frame timing of about 16 to 18 ms. If you can tune for that then the motion reprojection can work well. If this is enabled you'll only see 45 or 90 on your FPS though, so worth tuning the framerate without it. As for DCS PD vs SteamVR SuperSampling (that WMR uses for scaling), I've personally found that a DCS PD of 1.0 and then a SteamVR SS of 212% works well on the Odyssey. Obviously this is not a hard and fast rule for everyone, as clarity and all the various combination of settings is just a personal preference. It is worth a try if you haven't tried that. There is an issue on Win10 v1903 that sort of impacts this, but that will hopefully be fixed soon. [2] [1] https://docs.microsoft.com/en-us/windows/mixed-reality/enthusiast-guide/using-steamvr-with-windows-mixed-reality#enabling-motion-reprojection-for-steamvr-apps [2] https://steamcommunity.com/app/719950/discussions/0/1644292361960505688/

I think the best thing Microsoft WMR could do is just continue to untangle their bits from other groups, so that they don't have to wait for Windows Update to push regular and frequent fixes. They did do some of this, where WMR app updates come from the MS Store update channel side, and the WMR for SteamVR updates do come pretty often, it's just it all goes wrong where the WDI / driver teams get bugs and WMR interacts with it. The trouble with Windows Updates is there is a month turnaround for fixes, i.e. Insider track first etc etc. Rumor is the 1903 fix is about first week of July, but because it goes to everyone with Win10 (WMR or not) it gets a level of QA, bundling with other fixes and docs a simple WMR fix wouldn't normally get. I guess in the interim it might let HP make some headsets with some manufacturing design revisions. It sounds like a cable revision is in the works there.

If it's a Reverb maybe try a different USB socket? There seems to have been reports of 60/90, flickering and sound drops from quite a few people now. Hard to tell how wildspread it is (happy people don't tend to make a fuss).

Flashlight was introduced in 1809. As for the bug on 1903 or not, not sure what the goal is here? Microsoft publicly acknowledged it, said they will fix it, it's demonstrable on the Reverb (it's for all WMR), but doesn't really impact things as bad as the Odyssey. You could be running so much MSAA to make it not noticeable, or your eyes could be useless that it makes no difference, hard to say. I only care about it for the Odyssey, as for that it makes a tangible difference. If I used a Reverb I'd probably wait or probably use 1903 anyway, as I don't think it's serious for that. To deny it completely is just to spread FUD, or at the very least just a bit of light trolling at this point. Maybe that's the goal, dunno.

It does. Makes overclocking much easier, so for those that do that, worth the extra money you pay for that feature.

But you get the 'why' on how DCS can still be a single threaded (more or less) app and you still have graphs like that on Windows 10 and a Coffee Lake architecture or later, right? The i9 is expensive as top of the range premium, and if you don't like to overclock or run things that use the cores (video editing etc) then it doesn't represent very good value for you over an i7 8700K. You are literally paying extra for that 'K' CPU feature of the unlocked multiplier *for overclocking*, so paying for it and not using it is never going to be good value. A lot of these things could be sorted out before purchase, but it is good you can return things anyway and get your money back. By sharing experiences on forums like this you'll probably help others in a similar boat.

Single thread apps can be spread around cores, it's what the Windows 10 thread scheduler does on a shared cached chipset that supports it, which is what you are seeing. It didn't used to be like this. It allows the CPU to run more evenly and cooler rather than a core0 pegged at 100%. The newer Intel (and AMD) designs have a shared cache between cores that makes this 'core spread/hop' have practically no run-time impact. If you find that hard to believe (as a guess) and think that perhaps DCS is now a fully multi-threaded changed in secret or something, then please try disabling your cores in your BIOS and track the linear relationship between load and cores left. Post your results. As for the general comparison between an i7 8700k and a i9 9900K then you're talking about a 6% difference on a single threaded app. Depending on how you systems is I can believe that you didn't see a dramatic difference in DCS. I personally find an i9 overclocks much more nicely than a i7 8700, but perhaps you got unlucky in the chip lottery or weren't sure how to best use it for that or your cooling etc. Cool and stable at 5 GHz is very common for an i9 I think. The misunderstanding of what a 'bottleneck' might be happening as well, in that there will *always* be some sort of limiting factor, it just shifts around as people do different settings/things. To say 'DCS is CPU core speed limited' is only true if the CPU is the limiting factor in how you run DCS. If you use VR and have lots of MSAA and super high resolutions with millions of vertices being drawn then this isn't true - your GPU will be the 'bottleneck'. To say 'DCS is GPU limited' is also not true if you use a very high visibility/object setting with calculations done on the CPU side. A mission with many units or perhaps even a MP session can easily make the CPU the limiting factor. The only other factor in this side is that currently some things *could* be put to another thread but the use of DX11 prohibits it, as in the thread you initialize the render with has to be the one issuing instructions. This makes it hard to change program architecture over to something not designed initially around multiple threads. The Vulkan API isn't 'faster' than DX11 but is at a lower level to be able to do this sort of change, hence the look at that. So, yeah, you're going to get lots of different people saying different things. In a way, some of them can all be right.

With motion reprojection on you'll only see either 45 or 90 in the fps readout, so it's best to turn it off to tune your settings/resolution (ideally about 55-60 fps for motion reprojection to reliably work). The WMR portal settings of 'Settings / Headset display / Visual quality' are just used with WMR, i.e. WMR apps like the Cliff House. SteamVR does not use these, as it does the up/downsampling on its own side. Just set it to 'Very high (beta)' unless you have a very busy cliff house layout. The 'Settings / Headset Display / Experience Options' has the 60/90/auto switch and the 'Auto' behavior will drop the default 90 to 60 if you have over 90 seconds of under 45 fps (which is where the default 'rotational reprojection' is probably being used as well). I personally can see a bit of a flicker at 60 Hz so set mine from 'Auto' to a fixed '90' so this doesn't happen (as in, I'd rather see a game judder badly and change game settings than switch down to 60 Hz automatically to avoid flicker). Some people don't mind 60 Hz, so it's one of those personal preferences. I think that some players with DCS and (and too high settings to run) are actually being automatically switched down to 60 Hz without knowing it, with motion reprojection not being used, but just the plain rotational one instead. The SteamVR app will show the current panel Hz setting used.

'forceHalfRateWithReprojectionMode' was deprecated and replaced with 'motionReprojectionMode' so no need for both. [1] 2.0 is meant to be the best and the max it will accept for now. [2] [1] https://steamcommunity.com/games/719950/announcements/detail/3229520292644260853 [2] Info from Microsoft down from here:

I don't have a Reverb, so perhaps those that do could answer better, but I have been following what's going on with them on the various forums. It sounds like either: - the connector cable is loose or malfunctioning. If you hook it up behind the back headband then it might help, with zipties or something to take the weight. - the USB power draw is too high, in that the headset is either drawing too much power from the USB 3.0 connection or your USB power is not right. People have had some success with using a PCIe USB hub, but one that connects direct to your PC's USB (with a molex of its own etc) as an extra expansion card. Don't use an external USB hub with it's own power supply, as they are often just as bad a motherboard USB chipsets. It's also possible the connector and cable are the culprit, but that a better USB 3.1 connection helps get through that, i.e. the issues are all connected as a design problem. You could try unplugging every other USB device you can and see if it helps, to narrow it down. Personally I would be tempted to contact HP regardless for an RMA, as people on various forums have been saying that their issues are getting addressed, but to the extent they are getting sent replacement updated design cables and the like. I would not be surprised to see a hardware revision coming up, so if you do need a replacement then hopefully you'll be first in line for one of those. Hope that helps.

WMR doesn't use SteamVR motion smoothing or reprojection, as that's in the driver side (same with Oculus if it uses SteamVR). WMR has two forms of reprojection, a simple rotational one that is always on and the opt-in 'motion temporal reprojection' (which is the closest WMR has to the Oculus ASW like method). The WMR motion reprojection needs about 55-60 fps to work properly (it is less efficient that either SteamVR's motion smoothing or Oculus's ASW) but when on works well. So it seems the best ‘tuning’ algorithm for WMR and using reprojection in DCS would be: 1. Go to the default.vsettings file and comment out (using //) the motion line, i.e. turn it OFF (if not already off). 2. Test DCS with your settings. Adjust them so you get to 55 to 60 fps with the resolution / super sampling you want, say 188% on Reverb, 212% on Odyssey etc. 3. Go back to default.vrsettings and uncomment the line (remove the //) so it says “motionReprojectionMode” : “auto”, in there. That way you’ll get smooth tree sideways and the fancy reprojection working properly. See here for more info, docs etc: https://forums.eagle.ru/showthread.php?p=3945739#post3945739

Sounds like this one? Uninstall Open VR Advanced if you have it? https://forums.eagle.ru/showthread.php?t=243025 Otherwise, that can happen if the headset hasn't done its initialization before DCS starts up. The best order seems to be (1) put on headset, do the 'look left/up/right' thing (2) use a Desktop widget in the Cliff house WMR env and double click a DCS desktop icon from there. If the headset is still trying to get a fix on its orientation in that start-up mode then it seems to confuse DCS center position when it starts.

The current WMR bug on 1903 is essentially that the renderTargetScale in that file is forced to be 1.0 and that the maximum buffer size is limited, meaning it upscales a blurrier image. It seems to have about a 10% impact on the Reverb, but a 21% degradation on the Odyssey Plus (so much more obvious). Hopefully a fix or workaround is coming soon. The Reverb number of pixels is so high it's not like a showstopper, but for the O+ it will be nice to be able to move to 1903.