DCS Causing SteamVR Fail | Description, evidence and how to replicate

[RealDCSpilot]

Just to add more context information: https://forums.eagle.ru/showpost.php?p=4528333&postcount=78

[Stal2k]

Hi Buddy.

Well, apprently your "black screen" is not the same as the one I've had 3-4 of in as many months.^^

 

This took me by surprise.

 

The HMD itself appears to shut off, the lenses go black, black like an unpowered device, not like a black screen but with an obvious backlight. Does that make sense? I'll try to adjust my capture, might not be as pretty but the one thing you aren't seeing is a little window appearing over the steamvr box (that can be seen in orig) that states SteamVR failed. I tried to set OBS to grab it, but short of just capturing an area of the desktop you can't. Based on what you're saying I see the value in doing so and lining it up against timing so I'll adjust accordingly for next test.

 

That reminds me of a Rift thing way back, but what I have seen is DCS get disconnected the helmet goes black, but it enters the basic "grid" view and tracking is still functioning. Yes makes perfect sense, its a "powered blackness".

 

I think I'm doing a poor job, probably because I'm over-explaining. I would define powered blackness as the state of just loading into a game or something where the screen is black but still backlit. That isn't what is happening, to either the Rift S or the Index. For me, the screen turns OFF, totally off like in the state it's in when you pull it out of the box. The only indication there is still power to the device is the lights on the front. You have to effectively power cycle it to get it to display again.

 

To answer your question on how to record inside the headset, I use OBS + SteamVR plugin for OBS to record the view directly - what you see is what you record, except some trimming to 1080 ratio.

 

Same, I'm using that plugin. The one minor thing you aren't seeing in the videos because the capture freezes effectively w/ the headset is the disconnection notice in the DCS mirror right after. It's like a TRACKIR removed note, basically the same as if you plug/unplug a USB hotas or something during gameplay.

 

I still need to review this after work, especially the videos. This is now heading in a direction especially by the frequency and ease of reproduction, that this seems to be not something in DCS at all and may even be in the realms of hardware behaviour. You shouldn't consider that as some sort of failure, no one is pronouncing death of anything, it just seems to be building a picture that way and that's my current opinion for all that's worth.

 

I get it, I don't want to repeat myself because I addressed that in a bullet in the last post. I completely understand that, that is what it looks like but I just point to the quantity of other folks that not only Have vr --> "qualify" for the crash --> play MP or denser missions that cause the crash --> check the forums. Getting 20+ folks including testers that filter through that fallout tells me if it is hardware-related, it's something that needs to be developed around. Because I'm currently the only one doing all these tests, it's easy to get tunnel vision on my specific system. Going back to the original post, I was able to get this to happen on a totally different computer (same HMDs though) and I do play a myriad of other VR games, this doesn't happen EVER on anything else.

 

My last question is, "with the amount of success you had reproducing this, and the variations you tried, what is your revised steps to reproduce?" Can you iterate on the version I tried or is it the same? If I can get that, then I can get the folks I do testing with to all try a fixed process and feedback, it will definitely help make the picture more visible.

 

A final comment. It sounds unplayable? Is it? A bit of reverse thinking here but... what settings actually work?

 

Amount of success: I never failed to reproduce, it was more a question of when then if. FWIW because of the easier time I had reproducing on the vanilla install with the pumped up (200%) SS an 2xMSAA it still really seems like there is a "line" in terms of what you can get away with related to memory.

 

Variations/revised steps/version: You can reference the notes for each package, I would summarize as bouncing between the more formal steps you established and just regular gameplay. In terms of revised steps, I tried to get something done w/ using the mission editor and loading two different maps + unit lists prior to loading the test mission in the interest of creating the instability needed to cause the crash. Aside from package 3, I didn't really have success in this regard to the degree I'd feel comfortable documenting the steps. So in a nutshell, I think what you have is fine and it never failed to work, it would just take longer then if I just bounced between two slots (SC and airbase) and used aggressive F2/F10 use to cause instability. I like that with your steps there is a noticeable progression to getting to that instability. The version of your original mission was left untouched, I updated mine (mission 2) to remove the A4, I used that for normal gameplay.

 

Is it unplayable?: This is the real question. I can sort of answer it by looking at how much of my free time I've spent to get to this point :). It does happen, almost every time. You do learn to work around it, i.e. delaying the onset. This is very much a "feel" you develop very similar to learning how not to rip off the wings of an F-14 or set the C-101EB engine on fire.

 

This is a combination of two behaviors, 1) avoiding using F-10 or really anything that involves switching the screen drastically when the performance is anything but smooth (it rarely is). 2) recognizing the slowdown and, for whatever reason, alt tabbing to the task manager and just letting it sit there will smooth it out (yes, I realize that sounds stupid). Doing those things will at least delay it, sometimes it comes out of nowhere, which I think you can see in package 8 but usually you will see/feel it coming.

 

So in summary, the game isn't unplayable in the sense of if I modified my behavior to only do small scenarios or really well-made campaigns like Raven one, it's unlikely I'll see or run into this. However, if I fly with friends or participate in one of the popular multiplayer servers that run on PG/Syria I'm very much on borrowed time.

 

I know that is a lot and very anecdotal, but if you comb through this thread and the reddit thread of people that are providing some detail, you will see a lot of commonality with the 1) HMD going black, 2) what it feels like in terms of when it's about to happen (F-10 menu being a biggy) and 3) roughly the time this became prominent again, which is sometime around ~2 months ago and *after* the launch of the SC.

 

Like you said, I did a ton of tests and can only offer so much more value as an individual. One thing I could and would be willing to do since we can force the crash so quickly is to figure out EXACTLY which open beta patch introduced this for me personally. Based on Rob's account and a few other random posts I could find, this has happened to some degree before. I ballpark this as a patch after the SC and before Syria. So what I might do is ask you to either transplant your mission or let me use my mission 3 as the tester and use PG as the "home." Using our steps and see if it crashes, continue bumping the version until it does.

 

edit: I narrowed the list of versions this likely occurred but it doesn't seem like I'm able to get them anymore from the server using Skatezilla's updater. I'll look into if there is another way to get them but for whatever reason, it won't even let me grab something as recent as 7/15 (2.5.6.52196). Without being able to test my best guess is it occurred in between builds 2.5.6.50321 (6/02/20) and 2.5.6.53756 (08/18/20). There are changelog entries in builds .50726 & .52196 that would align with what we are seeing memory wise.

 

Thanks for your time.

Edited October 19, 2020 by Stal2k
more context on version stepping

[Pikey]

Hi again.

I watched the videos. I had about four new thoughts. :(

1) Very cool to see code I wrote in Jan 2018 reused in stuff you fly today! What was that mission? I remember trying to put together the mission naming conventions and looking at my wife playing World of Warcraft and picking out a bunch of nouns for the random table that were either animals or classes!

2) You have used SteamVR beta 1.15.x in every reproduction. I have never gone past 1.14.16 and after watching this, I feel I dont want to update. If you want, try that. It's soemthing, I dont hope.

3) I still dont know your PD setting.

4) Your setup is somehow broken worse than I even thought. I'd rather get you working than continue this torture. I can't hope to get anywhere as close to these headset steam VR crashes. Mine can wreck my game, but the headset hangs on and as long as I just clear down the memory, it will be fine without ever disconnecting or crashing steam VR.

 

There's something fundamentally wrong. Whilst I can get my machine to stress and slow down just as easily, the primary difference that seperates me and you and perhaps others, is the SteamVR crash which causes the VR device to actually get disconnected. I dont have your setup, I have WMR for Steam, WIndows Mixed Reality Portal, Steam VR and a HP Reverb. Even more junk in between. Those vrcompositor messages... I have none. "Failed to wait for GPU work". Nope. its not remotely similar. I'd be interested if this is hardware related messages or I could get them on Reverb.

 

I know you said you could do this on Oculus, but this is absolutely more about the VR softwares reaction to DCS than anything else. I think it needs someone using an Index and even get on identical versions of the middleware.

 

Frankly, if I thought you reproduced this much, after giving up with reproducing, myself, I'm kindda worried you can't actually get it working reliably again. Can you? What would you do to enable that? I know you said you avoid the situations, but there were quite normal dogfights there and you arent lasting 20 minutes. Generally I have to fly for 2hours for our sqn missions.

 

I realise we use VR differently, I was testing use_shared_stereo_parser = true today and all my CPU and GPU were in the green once airborne, a tad of orange scattered through it. 45 on the ground 30-40 on SC, 60-90 FPS in the air in small missions. 0.8 PD 140%SS no AA, medium textures. I couldnt get over 22FPS at the begining of the year. I just wonder if its not just better to get good frames and experience than hunting this? Let me know how close you can get to normality.

[Stal2k]

Hi again.

I watched the videos. I had about four new thoughts. :(

1) Very cool to see code I wrote in Jan 2018 reused in stuff you fly today! What was that mission? I remember trying to put together the mission naming conventions and looking at my wife playing World of Warcraft and picking out a bunch of nouns for the random table that were either animals or classes!

2) You have used SteamVR beta 1.15.x in every reproduction. I have never gone past 1.14.16 and after watching this, I feel I dont want to update. If you want, try that. It's soemthing, I dont hope.

3) I still dont know your PD setting.

4) Your setup is somehow broken worse than I even thought. I'd rather get you working than continue this torture. I can't hope to get anywhere as close to these headset steam VR crashes. Mine can wreck my game, but the headset hangs on and as long as I just clear down the memory, it will be fine without ever disconnecting or crashing steam VR.

 

There's something fundamentally wrong. Whilst I can get my machine to stress and slow down just as easily, the primary difference that seperates me and you and perhaps others, is the SteamVR crash which causes the VR device to actually get disconnected. I dont have your setup, I have WMR for Steam, WIndows Mixed Reality Portal, Steam VR and a HP Reverb. Even more junk in between. Those vrcompositor messages... I have none. "Failed to wait for GPU work". Nope. its not remotely similar. I'd be interested if this is hardware related messages or I could get them on Reverb.

 

I know you said you could do this on Oculus, but this is absolutely more about the VR softwares reaction to DCS than anything else. I think it needs someone using an Index and even get on identical versions of the middleware.

 

 

1) It's a version of The Round Table by Mith.ar https://www.digitalcombatsimulator.c...files/3311949/. I modified it to suit my needs including the transplanted BFM arena.

2) This has been going on since June, so I've used every version since then and even tried flipping back to stable

3) My pd in DCS is 1.0, I never change it inside DCS

4) Like I said, the vanilla copy with the MSAA and 200% SS we were using for testing makes it pretty rough. There were probably instances during the videos I could have also avoided the crash by calming down the cycling, but since we were trying to crash it I didn't.

 

I don't disagree with you that there is something wrong, but I just don't see this anywhere else when I use the PC. I thought about temperature, I thought about bad SSDs I even thought about something wrong with my GPU. These issues would crop up in other games, and for the SSD I used a different drive for the vanilla DCS I installed. Same thing with my ram, if I had a bad module it would crash other stuff that I do.

 

Frankly, if I thought you reproduced this much, after giving up with reproducing, myself, I'm kindda worried you can't actually get it working reliably again. Can you? What would you do to enable that? I know you said you avoid the situations, but there were quite normal dogfights there and you arent lasting 20 minutes. Generally I have to fly for 2hours for our sqn missions.

 

I realise we use VR differently, I was testing use_shared_stereo_parser = true today and all my CPU and GPU were in the green once airborne, a tad of orange scattered through it. 45 on the ground 30-40 on SC, 60-90 FPS in the air in small missions. 0.8 PD 140%SS no AA, medium textures. I couldn't get over 22FPS at the begining of the year. I just wonder if its not just better to get good frames and experience than hunting this?

Let me know how close you can get to normality.

 

So the first thing I do is switch back to my main install that has shader mods that take off some of the weight. Secondly, I just avoid the Syria map as it's easily the worst. Oddly enough though if I just kind of 'take my medicine' and eat a crash or two I can stay in the game awhile. Otherwise I've just kind of learned how to be careful when doing things that would cause it to crash. I can play on the Caucasus with a pretty high success rate and haven't really tried the Persian Gulf recently but it's somewhere in between NTTR and Syria.

 

For giggles I also tried the shared parser, even though I know that also #triggers BigNewy :) I hadn't used it in awhile. Still crashed, I also saw someone say something about Malwarebytes and DCS not liking each other, I do use that software so I got rid of it temporarily. Unfortunately same thing.

 

There is a pretty wide spectrum of how DCS runs in VR just based on the HMD you are using, I do think the people with Reverbs and Rifts tend to have a better time than those of us with lighthouse based hmds like the Index and Vive. I *can* get DCS to run in what I'd call a semi-decent state in certain circumstances for a while, but since it's heavily CPU bound in VR my GPU is underutilized and going to 32gb of ram was a big performance gain. I actually had another fairly lengthy thread about what you actually get performance-wise in VR, but that is a whole other therapy session. I guess in a way you are sort of winding around to the reason I made this thread in the first place. It's super frustrating and its to the point now where I'd gladly just get a damn 3090 or whatever to avoid it if there were any around for something close to retail.

 

Best option would be for ED to fix this, like I have stated multiple times it's not just me while I totally realize how much it looks like it's localized to my system. To your point, it'd be great if one of these other people that +1'd would hop in and do some testing. Unfortunately, the only one of the guys I fly with regularly that had the same issue upgraded his GPU so he no longer has it. Maybe those two testers are doing stuff behind the scenes :joystick:

 

Edited October 21, 2020 by Stal2k

[Woody01]

Hey for what its worth guys, I have been following this thread closely as it is something that effects me a lot. I thought I would try Pikeys page file settings and instant improvement (going from 'let windows manage it'), in that I dont have to try 4 times just to be able to jump in an aircraft on our MP server (crashing at the selection screen), maybe just twice now. Also had slight improvement across the board crashes wise but alias it is still crashing under the same circumstances. Tonight after a 700 mile, 3 refuel round trip with under 100 miles to go back too the boat after an amazing 2:45 mission I was scrolling through the kneeboards to find the carrier BRC, slipped off the modifier (thereby hitting F10 with my HOTAS setup) and bam! No more DCS for you. Sad guy :(

I am glad to see you guys are getting somewhere with this, if I can help in any way let me know. But I apologize, I am not a professional bug reporter, just a guy trying to fly in VR and I dont really know my way around windows settings, SteamVR settings, windows settings etc... But keen to get too the bottom of it.

[Stal2k]

Hey for what its worth guys, I have been following this thread closely as it is something that effects me a lot. I thought I would try Pikeys page file settings and instant improvement (going from 'let windows manage it'), in that I dont have to try 4 times just to be able to jump in an aircraft on our MP server (crashing at the selection screen), maybe just twice now. Also had slight improvement across the board crashes wise but alias it is still crashing under the same circumstances. Tonight after a 700 mile, 3 refuel round trip with under 100 miles to go back too the boat after an amazing 2:45 mission I was scrolling through the kneeboards to find the carrier BRC, slipped off the modifier (thereby hitting F10 with my HOTAS setup) and bam! No more DCS for you. Sad guy :(

I am glad to see you guys are getting somewhere with this, if I can help in any way let me know. But I apologize, I am not a professional bug reporter, just a guy trying to fly in VR and I dont really know my way around windows settings, SteamVR settings, windows settings etc... But keen to get too the bottom of it.

 

It's good (sort of) to see this as it's seemed like it's been a bit of just me and Pikey trying to figure this out lately and naturally turning the focus back to something specific I'm doing. It's not good in the sense you are having a problem, but good in the sense of validating I'm not crazy and there is in fact an issue that is hitting some people and not others.

 

Of course, if you'd be so kind as to add a bit more detail it'd be helpful. Even if you kind of scroll through the last few pages and see what is being asked for in terms of, your system specs, VR HMD etc. There very well may be some sort of commonality between all of us nobody has noticed yet but as of right now it seems to just be in-game behavior. Can you verify the crash happens as I've laid it out, with 1) the black HMD and 2) DCS continuing to run 3) VR client fail, be it Steam, WMR, or in the case of Oculus it just shuts down.

[Woody01]

Yes sorry i should have given more actual information, it was getting pretty late though. I will compile what I can as soon as I can following the trend over the last few pages, we will get too the bottom of this!

[divinee]

I can quickly answer for this from my part. I haven't had time to run all these tests but i hope this helps

My system:

i5-9600k @5GHz with AIO cooler

Asus RTX2080 Super OC 8GB

32gb 3000mhz ddr4

1tb M2 ssd

hp reverb

 

1) HMD goes black BUT i can use hand controllers to get mirror view visible in my HMD so i can land after that crash. Perf is really bad in that situation and fps is like ~15-20

2) DCS is still running after crash

3) Problem is with steamvr crashing because WMR softwares and DCS keep running (like in part 1)

 

I mostly fly very big PvE missions and crashing is not the biggest problem because if i stay out of F10 map i haven't managed to make the game crash (yet). The most annoying thing is that everytime i die or change slot i have to restart everything to clear vram. Otherwise i will get huge fps drop, stutters and fpsvr shows GPU frametimes go from 15-20 to about 30+. Cpu frametimes stay 9-13. After that fps drop the risk of crashing steamvr when pressing F10 increases a lot.

Also tried with everything low and 100% SteamVR SS / 1.0PD without help. Last spring/summer i was able to fly from supercarrier and change slots with even 200% steamvr SS and high textures without any problems. That "vram memory leak" started after the patch when Syria was released (or possibly next? not 100% sure) and i'm quite sure these crashes and bad vram usage are releated.

 

Edit: I forgot to mention that vram leak happens with all maps, not just with Syria

Edited October 23, 2020 by divinee

[Pikey]

Hi thread.

Well I would love to say the problem isnt there, but for the first time in months I crashed my HMD during a testing session. Black screen, SteamVR did the oh no! message and dcs continued to run a sub 5 frames in the mirror view. Hard alt-f4. Began with poor frames only swapped planes once or twice, all ww2. This was on Channel map which is pretty hard on performance.

Nothing I hadnt done before fine, same mission, less players. I do recall considering if I could be bothered to do my normal restart before the session and foregoing it. Might still be about vram. It didnt happen again so it stood out as a bad session inside a normal evening. Nothing was really in common and it didnt give me any clues. Still feels HW+driver related than DCS. I think DCS provokes the situation, absolutely, but its really nothing to do with this crash. DCS has to be the only commercial software I know that can collapse your PC's hardware and you can set it to do that, or give it workable settings.

Side note... this is not owned or accepted as a bug with DCS until its a problem with its code. At best there are multiple performance issues. The ED developers have nothing to fix until there are reproducible steps that they can see and get the crash themselves. I'd be delighted to reproduce and champion a software bug. Everytime I try it resists, then out of th eblue, reminded me I was not looking for it.

 

I strongly suggest ruling out a bunch of issues by using conservative settings and reporting on the frequency of the SteamVR crash.

 

PD 0.7/0.8 Massive savings. People already found that in game PD was very expensive and should be traded for Steam SS at every opportunity.

SS 150% is behaving well for me, I went over that and began to induce performance slow down.

Textures... maybe, I have tinkered and medium or Low works better than High.

MSAA off. Here is your sacrifice.

Terrain distance could be anything, try to keep it higher for horizon and light popin reasons

Water has to be high, game broken without it. SHip wakjes go, etc.

rest of it is fairly inconsequential

 

Until you run the game in VR at lower settings successfully the settings are neither ruled in or out.

 

It's just a game of ruling things out until nothing is left. I accept settings might be contributory, but I since I cannot achieve your crash rate at your settings, you should try to change your crash rate at my settings. Because the actual settings might have nothing to do with the frequency or liability of the SteamVR crash. If we rule out settings its a vast item to cross off the list.

[Stal2k]

I strongly suggest ruling out a bunch of issues by using conservative settings and reporting on the frequency of the SteamVR crash.

 

PD 0.7/0.8 Massive savings. People already found that in game PD was very expensive and should be traded for Steam SS at every opportunity.

SS 150% is behaving well for me, I went over that and began to induce performance slow down.

Textures... maybe, I have tinkered and medium or Low works better than High.

MSAA off. Here is your sacrifice.

Terrain distance could be anything, try to keep it higher for horizon and light popin reasons

Water has to be high, game broken without it. SHip wakjes go, etc.

rest of it is fairly inconsequential

 

Until you run the game in VR at lower settings successfully the settings are neither ruled in or out.

 

It's just a game of ruling things out until nothing is left. I accept settings might be contributory, but I since I cannot achieve your crash rate at your settings, you should try to change your crash rate at my settings. Because the actual settings might have nothing to do with the frequency or liability of the SteamVR crash. If we rule out settings its a vast item to cross off the list.

 

Sure, in the interest of ruling things out, what are your thoughts on this. Since I couldn't get an older OB from the server, I DO have an older copy on my laptop still that is 2.5.5.41962 (well before the patches that caused it to act up for me). Would copying that to this computer and effectively running the same sort of steps (would have to be on PG) and in essence NOT getting the crash prove/rule out anything? To me that would show it's certainly code related in the sense of aggravating the driver/hw components your're speaking of, my suspicions are patches .52196 or .50726. I can be 90% certain it didn't happen prior to .version .49798 and was 100% present for Syria, that is a time span of about 2.5 months or so. Both the versions I listed as suspect have changelogs containing items that are at least related to some of the things we are seeing like F10 maps and 'improved startup times.'

 

Aside from that, I will try less than 1.0 PD settings in DCS. I already run w/ the low textures and MSAA off, I guess really the only thing you suggested I don't currently do is the PD. The frequency of the issue is very map dependant, I played for a few hours straight on Caucasus in a pretty heavy mission and aside from just, generally not great performance it didn't actually crash. If I load up Syria, it's just a matter of time, I suspect Channel is the same but I've rarely used that map although I do own it.

I might just copy that older DCS version over out of morbid curiosity.

 

[divinee]

I just had a time to make some testing. i went to a big PvE server which had Syria running and spawned in F-16 in Incirlik. I started to hit F10-F1-F10 several times. Same time i checked fpsvr frametimes and memory usage. GPU memory stayed at about 7,7GB but frametimes started to go up from 20ms to more than 100ms and didn't return to original 20ms. If i'd keep doing that i know that the steamvr will flip.

After that i removed windows page file to 800mb and restarted computer. Then i repeated the same procedure but this time GPU frametimes stayed at about 20ms.

This only worked in Syria.

 

Can anyone else try this?

[RealDCSpilot]

@divinee

 

Okay, 7,7GB means that your VRAM usage is maxed out. But can you please be more specific about your page file settings? Did you just change the size from XXXmb to 800mb or did you disable it? Did you also try to change the size to 32000mb or more (best practice for the windows page file is having it set to 1.5x your RAM capacity and prevent dynamic size changing by setting the same size for min and max)?

[divinee]

Vram usage in syria is always maxed out. Even with everything low and 0.8PD. Windows requires 800mb for some recovery files so i put 800 to 800. I didn’t have time to test with bigger page file.

i’m not absolutely sure about this and it is always possible that i wasn’t able to trigger that bug causing crashes.

 

Edit: I will try today with bigger page file and post the results..

 

Edit2: I wasn’t able to replicate the results anymore. I have make more testing..

[Stal2k]

OK, I've been having good luck. While I'm not ready to say it's for sure a fix it's good enough that I thought I'd add it here to let some others having the issue test along with me.

 

In windows, hit your Windows Graphic Settings (Windows key an type Graphics as a shortcut), turn off "Hardware-accelerated GPU scheduling" and restart. I've not had a crash since I've done this, although performance seems notably worse. I've also ordered another 32gb of ram (giving me 64gb total) and will try it with and without the GPU scheduling option.

 

If this turns out to be the root cause, my hope is this won't turn into a cop-out for ED to drop the issue and call it "fixed" because the GPU scheduler is still a feature of Windows that will impact users who don't know they need to go in there and turn off something that is by all accounts an improvement in latency and performance.

 

If someone keeping up w/ this like Divinee can verify it stops crashes or Pikey is feeling froggy and wants to turn his ON and see if he can get crashes by all means. That should help w/ duplication if this is in fact the problem.

Edited October 31, 2020 by Stal2k
edit to clean up some wording

[divinee]

I’ve had that ”off” all the time. Tried to put it on for testing and had massive stutters so i couldn’t make proper testing.

I’m still quite certain that the root cause for the crash is bad vram handling and vram leaks (which occurred at the same time as Syria).

[RealDCSpilot]

I've also had this off since it was introduced, tested it back then and found no real benefit. The occasional Steam VR crash still happened on my old 2080ti until i replaced it.

[RealDCSpilot]

@Stal2k

 

Any changes on your end after the patch yesterday?

• Terrain: improved background preload for less stutters
  
• Terrain surface textures: improved details at altitude for HIGH terrain texture option
  
• Terrain: improved loading resources and memory management
  
• Terrain: fixed excessively curved paths
  
• Terrain: fixed leak after destroying scene object
  

[Stal2k]

I did two things which I believe had an impact. 1) I've only had one crash since I disabled the GPU Scheduling which is a huge improvement 2) Disabled the let windows adjust scaling to improve blurry text. At least anecdotally it seems this cut down runaway GPU usage with the Desktop Window Manager process which was another big problem.

 

Since the patch, I've only flown on NTTR, actually the Viggen Red Flag campaign which is fairly busy and it ran decently. I should do a liberation mission with some people this weekend and will report if there are any major problems. I will also say that unsurprisingly the additional 32gb of ram I added (64gb total) didn't really change much other than being able to comfortably leave Chrome open while I play.

[Stal2k]

Alright, so I haven't had any crashes and played a good bit over the weekend. I will say that the F-14 in Syria, at least for the mission we were playing (liberation) was basically unplayable. I got into an F-18 and also an A-10 and everything was fine. The Tomcat, gives me like 5-13fps with that Desktop Window Manager process going crazy. So ya, I'm fairly confident, at least for me that the GPU scheduling feature and DCS = poopstorm for SteamVR. Now it's just back to regular hit or miss VR performance.

[=Panther=]

I'll add my system to list of having issues with this. Been suffering for about a month or so with no solution, as my pc isn't on the Windows 2004, still on 1909. For my scenario, I'm not doing any interaction with views, just parked in my jet cruising along when I'm greeted rudely with a Rift S going black, and desktop saying SteamVR shut down (sorry exact phrase escapes me ATM).

[hooti]

Same Problems for me. Ryzen 5900X, RTX 3080, 32GB Ram, Windows 20H2 and Reverb G1. Playing Syria Map is some sort of lottery. Before the crash it often loses tracking as well and i think it got even worse since the last update. But the second part is only a „feeling“.

[=Panther=]

Very long shot in the dark here, but for everyone having issues with SteamVR crashing. Do you also have error code: 157 "Disk # has been surprise removed" in your event viewer/windows logs/system? 

 

Additionally in Device Manager/ Disk Drives do you see "Xvd"?

 

Internet research shows this is a virtual disk drive by Microsoft, for XBOX Game Pass games. Which I do have a few games via that. I'm curious if others have the same chain of events, as I get a random game pauses which matches with the timestamps that the "Disk # has been surprise removed". On some of those pauses, is when SteamVR crashes.

 

I have uninstalled the Game Pass games, and the XBOX app for now. The virtual drives have stopped showing up and disconnecting randomly, and my DCS isn't pausing. Didn't do a long flight to see if SteamVR was stable. Have that on schedule for tomorrow evening. 

 

Over 2 hour flight and no SteamVR crashing. Very likely the issue at least on my end.

Edited December 5, 2020 by =Panther=

[ButchNZ]

Is anyone still working on this issue? I've been intermittently affected by this since october-november last year and it seems to be getting worse..

[Vähäkylä]

Is this problem related to Reverb G2 seizing SteamVR, and Cliffhouse launching while DCS crashes as SteamVR is hung?

The headset never truly dies, it just shows a frozen DCS image then cliffhouse, and it seems SteamVR hanging is teh cause of the crash. Seems to be most produced by having a SteamVR notification popping up, or calling the Action Menu up.

[wos]

Made recovery of local files WMR for Steam. Steamvr has stopped crashing. Maybe this will help someone.