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

[Stal2k]

Hi guys...I admit I have not read all the 7 pages...but trying to help with my CB tester fellas (some of us have VR, but only few of us a WMR one) , I would like to reproduce the issue.

I have an Index, 32gb ram and 2080ti with 11gb (full specs in the signature)...

I use 100% SteamVR SS (200% of index physical res and staemvr reports 2016x2260 per eye)

DCS settings are pretty high for VR (high visibility, shadows on low, texture high, terrain textures low) in similar situation to the one described by the OP, I got very high ram and vram usage...with very low FPS (in similar situations I got the usual 40fps). Usually restarting DCS, or sometimes also just ALT-TABBING seemed to solve the issue.

But I never got a CTD in this same situation.

So what I ask here...is it specifically a WMR/Reverb issue. Or the users reporting those crashes are using also other kind of headsets?

Thanks

 

Great to hear, thanks for joining in the fun here.

 

I've also experienced the phenomenon of the high use/low fps and seemingly switching to task manager to 'threaten closing dcs' does the job and it's straightens out. It's kind of comical, strangely the "Desktop Windows Manager" process has super high GPU use that coincides with what you are talking about.

 

I digress :)

 

I don't think it's a WMR/reverb issue, so far I've been able to get this to happen on both an Index and Rift S. Many folks have reported on the Reverb and to summarize the rest of the thread(s)

 

I have not seen this reported on a PiMax, and since Bignewy is the only one who actually owns a Cosmos :) (joking) he appears immune. I've noted it's a lot "harder" to make this happen on Rift S.

 

I show in my original video this happening via switching modules but most of the folks reporting, myself included experience this when using the F-10 map on busy servers.

 

I would like to formally apologize to everyone involved here, never did I think this would become a 7 page deep thread, I thought what I did was sufficient (in fact was even told as much) and we'd all be moving on with our lives.

 

I'm really not much different than the 20+ other people reporting this aside from the fact I was frustrated enough that instead of just moving on from DCS, to put the time and effort into raising this issue with ED and trying to sort through it.

[Stal2k]

Can I offer a suggestion as well, those whom are having this happen:

 

Post not only your steps to reproduce, but also go and get your STEAMVR logs and post those

 

Thanks Rob, great idea.

 

I need the mission.

The OP has a mission but it has mods in it. That's not going to fly down the line, so it's out.

 

It's the A4, that should be the only mod, I can easily remove it, or are you saying just because it had mods when I made the video it's out? Frankly, I think since we are all kind of resetting I'd rather just centralize it to a server like TTI Syria or PG like Alec is saying, the mission isn't really relevant beyond deliberately creating (I'm being very careful here with wording) "amplifying circumstance to aid in the reproduction." Does that make sense, and would it ease that particular requirement for you Pikey?

 

 

I can't trigger this issue anymore because my GPU now has 24GB VRAM. I already had 64GB RAM before i upgraded from a 2080ti with 11GB VRAM. So VRAM needs to be watched closely, it's the only factor that changed on my end.

 

Steps to reproduce were:

 

1. a) use high settings that demand more VRAM (textures high, terrain textures high, water high, vibility range high, heatblur low or high ...)

b) raise SteamVR render resolution between 150%-200%, ingame PD setting at 1.0 at all times (somewhere is the sweetspot for your system, restart is always required to apply changes)

c) having a bunch of other windows open will also help slightly raising VRAM usage (discord, simshaker ...)

 

2. choose a server with a big mission like TTI on Syria

 

3. choose any aircraft, jump to cockpit, choose next aircraft (F/A-18 or F-14 on supercarrier to have the biggest impact), jump into cockpit, check external views, switch to F10 map, switch back to cockpit, switch to F4 external view of other aircraft a couple of times.

 

4. repeat step 3 and at some point SteamVR should crash. The more different modules you own/can to jump into, the better...

 

I'm totally aligned with what Alec is saying, in fact, I think that is more less what I was saying in the OP minus the focus on settings. I think all of us are eyeballing the ram/vram as a likely suspect. At this point we are trying to just zero in on the cause without the luxuries Pikey outlined of a debug machine/access to the code.

 

I didn't manage to get a single CTD right now, but the worse situation I got is an fps slideshow (only after a while, and usually changing slots and switching views). I will try to rise my SS values and DCS settings for the next run of tests.

 

Virus, if you'd be willing I'd be happy to work closely with you on this as our systems/HMD closely match up. I would love if it were something stupid like DCS needs to be on your NVME drive and not just a SATA SSD or something. The situation you describe of where DCS starts chugging, if you hit F-10, F6, hell sometimes even F2 or do something crazy like swap to the F-14 on the super carrier. If your HMD doesn't black out during that, that is a great place to focus on unpacking, because mine will 10 times out of 10.

 

When my system does that I have to treat it like a deep spin/stall and just take my hands off everything and hope it fixes itself quickly or I'm going to die :). My DCS settings are a bit more conservative then Alec's where when it was happening to him (no MSAA, low textures etc) and my SteamVR settings were dialed down from the default to 150% SS and have been for awhile.

 

If you're willing, I think a good place to start might be a deep comparison of our systems and running software (like HOTAS stuff) and driver versions. Again, with your consent I'd be happy to move that discussion to something like a Discord PM so we aren't clogging this thread.

 

My username is Stal2k#4371 for anyone here in the peanut gallery that wants to get involved we can set up a small group.

 

edit: removed an extra [/Quote] and added the two final paragraphs to Virus.

Edited October 16, 2020 by Stal2k

[Pikey]

@Pikey

It's not depending on a specific mission! Public Training servers hosting the Syria map, like from "Havoc", "Kirk's Hangar" just to name a few. They all have a certain amount of ground vehicle activity, all modules available including the supercarrier plus tankers and AWACS in the air.

 

 

So now itsnot specific to a mission? then I cant provide specific steps to reproduce.

 

I'm not taking part in guessing games.

I cannot believe I've asked three times for the same thing now and no one in this thread can give specific steps to reproduce something that is apparently affecting so many people.

 

 

Are you absolutely sure this is an issue?

[Stal2k]

So now itsnot specific to a mission? then I cant provide specific steps to reproduce.

 

I'm not taking part in guessing games.

I cannot believe I've asked three times for the same thing now and no one in this thread can give specific steps to reproduce something that is apparently affecting so many people.

 

 

Are you absolutely sure this is an issue?

 

I do not see how many people experiencing the HMD shutdown across maps/missions preclude us from creating very explicit steps for you to recreate the circumstances both known/unknown to prompt the outcome.

 

You said you need Exact steps and we are all clamoring to make you happy here. I personally haven't had time to dive back into this beyond replying here and expect to have some time over the weekend.

 

You've been given steps to reproduce it from both myself and Alec, clearly, based on your experience these are not universal enough. Being that we aren't psychic we didn't know that at the time and are working to firm things up.

 

To be absolutely, 100% crystal clear - This issue is not limited to a specific map/mission. I've had it happen across SP/MP and all maps. However, *IN THE INTEREST OF GETTING YOU WHAT YOU ASKED FOR wouldn't it make sense to centralize on a single map/mission to reduce unknown variables that could be contributing, the goal being getting this issue documented to that JIRA friendly state of reproducability?

 

I do think the TTI Syria server/mission is a great candidate because it has the groundwork to easily prompt the crash not to be confused with the only circumstance in which it can occur.

[Pikey]

still no steps...

What do you want me to do?

I could say to ED, hey this is easily reproducible, go ahead and reproduce it.

And they will say, "How"?

Don't you see the point of this?

[Stal2k]

still no steps...

What do you want me to do?

I could say to ED, hey this is easily reproducible, go ahead and reproduce it.

And they will say, "How"?

Don't you see the point of this?

 

Am I not allowed to speak in this thread prior to providing you steps? How about answering the questions I asked you - feel free to dial back the attitude. If the objective here is to just get me to move on and leave this issue alone based on your attitude I'm actually pretty content to do that. I do not work for you, I'm trying to help as it's impacted my enjoyment of this game as well as others.

 

So lets baby step this, you asked what I want you to do? What I want you to do is answer my question since it seemed to really frustrate you that Alec shared the issue occurs on multiple maps/missions.

 

So I'll ask it again, would it make sense to centralize on a single map/mission to reduce unknown variables that could be contributing, the goal being getting this issue documented to that JIRA friendly state of reproducability?

 

Lets start there so we know when I'm trying to polish up the report for you, again I'm really sorry this is happening to you.

[Pikey]

I don't know how many times I have to say this. I cannot do what you are saying is easy. I do not know how. I need steps to reproduce the issue in order to log it to a deeloper to have them also see the exact same thing.

 

 

You said it was easy. Treat me like an idiot, please, and tell me what to do step by step to crash my HMD. Once I can do it on demand like you can I can report it and that is that.

 

 

Will you? Please?

[Stal2k]

So now itsnot specific to a mission? then I cant provide specific steps to reproduce.

 

The above quote is why I was asking, in the interest of not wasting any of your time. Since you don't seem to want to answer i'll just move on.

 

Treat me like an idiot

, please, and tell me what to do step by step to crash my HMD.

 

I'll borrow what Alec supplied which is effectively the same thing in my original report, just more concise.

 

Steps to reproduce were:

 

--

1. a) use high settings that demand more VRAM (textures high, terrain textures high, water high, vibility range high, heatblur low or high ...)

b) raise SteamVR render resolution between 150%-200%, ingame PD setting at 1.0 at all times (somewhere is the sweetspot for your system, restart is always required to apply changes)

c) having a bunch of other windows open will also help slightly raising VRAM usage (discord, simshaker ...)

 

2. choose a server with a big mission like TTI on Syria

 

3. choose any aircraft, jump to cockpit, choose next aircraft (F/A-18 or F-14 on supercarrier to have the biggest impact), jump into cockpit, check external views, switch to F10 map, switch back to cockpit, switch to F4 external view of other aircraft a couple of times.

 

4. repeat step 3 and at some point SteamVR should crash. The more different modules you own/can to jump into, the better...

--

 

If those don't do it for you, congrats you are one of the lucky ones. Has anyone from ED just charged you with this issue and rested the resolution solely on your ability to reproduce?

There is another thread that just popped up reporting the same issue and includes people tagged as "Closed beta tester" and "Tester."

 

It's never been a question on if this impacts everyone, it very clearly does not. For example, If you have a 30xx series GPU, you are safe. Otherwise I wouldn't have wasted the time in making a video if anyone with VR could just crash their HMD with relatively easy to follow steps.

 

The more you just ignore the reasonable question(s) I asked you in favor of just yelling "steps" at me, the less likely I am to want to spend more of my time refining those steps already provided to the degree they crash your personal HMD.

 

Once I can do it on demand like you can I can report it and that is that.

 

Will you? Please?

 

If you are impacted by this issue, steps have been provided by myself and Alec. Since they are not working for you, I guess we can all just go home. Alternatively, help me help you. As I said, now the formal testers are starting to see this issue, so I can only assume whatever is causing it is getting worse. As an end user, I'm more inclined to you just have you go bark orders at them rather than continue to go in circles with you.

 

Realistically, if your system was impacted it wouldn't be so hard to crash it, so even if we can refine the steps to a degree beyond what is provided, it's unlikely it will happen to you.

 

Very genuine/serious question for you, that I'm hoping you respond to: In the interest of getting steps that work for people that are, lets say less impacted would cranking various things like Steam SS to an unreasonable amount in the interest of just replicating the crash for debugging purposes be helpful? Obviously, the pushback would be - hey nobody is going to do that, which sure. but if the only goal is getting to steps that cause it 100% of the time would this be valid?

[robgraham]

Ah To be fair my other thread didn't just pop up Stal2k I pointed Newy to it and I posted it over a year ago, it has a lot of extra info in it that I thought might help given that this post now exists. Thing is people need to take a step back for a moment, there is a very real chance that part of this is being driven by a time out caused when the vram gets dumped etc which means that peoples graphics settings, actual systems etc could play a very big part in all of it.

 

What I've had it happen on some one with a 2080ti might not have it happen on, what your reporting etc I might run and never have an issue on, steps are all well and good but if just doing the steps isn't allowing some one to reproduce then you need to start breaking things out a bit more and again look at:

 

1. What are peoples System Spec's? Specifically - Video Cards (and VRAM amounts), Driver Versions, Windows Versions, SteamVR Builds etc.

 

2. What are peoples DCS Graphic settings when the issue occures, does REDUCING the settings IMPACT how quickly it happens, does INCREASING the settings.

 

Getting graumpy at each other when all ppl are wanting to do is help and or get help isn't helpful..

 

I get that it's frustrating, I know that for me I have had it personally happen after a hour or so in the F14, F18 or another high detail ac and then hitting F10 and boom i'm out .. But then I adjusted some settings etc recently and its occurence rate has.. Dropped on me, I can't say fully what I've changed because tbh I've played with a few settings.

 

 

The steps as I understand it that ppl believe will reproduce from those of us experiencing it are:

 

A. whatever rigs we are running (mine is in my sig with a NVME needed to be added).

B. whatever our dcs settings are.

C. whatever our VR settings are.

 

then

1. Running DCS in a mission with a large amount of units and or memory use.

2. Switching through views that cause items to need to load/scene changes to happen.

3. Eventually at some point Steam VR will encounter an error leaving the user with the following symptoms:

 

A. SteamVR window states "SteamVr has encountered an issue/error".

B. If your in WMR you get a breif flicker and or blue shifting zone.. then you go to a black screen with nothing.

C. The Window on the Desktop of DCS will still have DCS RUNNING, Were you asked it to be in VR mode, your likely to still have headtracking etc.. but no vid on your HMD.

D. Due to Steam not allowing you to simply 'reinitalise' your forced to close steamvr and thus DCS, restart and symptoms go away until you do step 1.

 

The issue here is and please take a breath, there are Multiple areas where this can be happening...

 

It could be DCS itself (which is possible... based on the logs that I supplied a year ago and back earlier this year) that it's going into a state where it doesn't communicate with steamvr's server just long enough for it to time out.

It could be SteamVR/OpenVR having issues when large amounts of memory are in use.

And for WMR users it could be the steam - wmr plugin as well.

 

So while it's frustrating etc.. and i get it's frustrating the more info ppl can give and having paitnece while Newy etc pass that info on.. the more chance there is that the exact things needed to get a Dev to reproduce can happen..

 

That is what Pikes is trying to explain when he's asking for steps he can't reproduce it currently on his system. So maybe give him some more info on your settings etc.. I've handed over mine elsewhere.

[RealDCSpilot]

Before we start banging our heads against the walls...

 

@Pikey

 

You already were in the zone for the problem in your video at 6:41 in your mission. At this point, when the sudden framedrop occurs, the chances are high SteamVR can fail. It's kind of a precursor for the crash. Usually, in the same situation, an action like switching to the F-14 on the super carrier and using F10 map after that triggers it.

[Pikey]

Yes we do need to settle on a mission and very specific steps. It doesnt matter that I cannot reproduce whatever you can come up with based on the mission and steps on it's own. If you think that, then, you are thinking too far ahead and not understanding the process. The fact that one person gets it and another doesnt't is fantastic, but only if they both do the SAME thing.

 

Perhaps I need to explain more to get you guys involved in the troubleshooting process.

 

If I can repeat exactly the actions that you do whilst crashing the HMD, then we know for 100% sure that its not what we do, but the configuration. T/S is about ruling out all the possible, until you are only left with the cause.

 

But we already told you that Pikey, the mission doesn't matter! Maybe! But How am I going to tell anyone else how to reproduce if it only happens with me and not someone else? It will only serve to perpetuate the insanity of leaving each person with a problem to define. It is absolutley reasonable to ask for the steps from someone with the problem on demand.

 

I appreciate you are jumping way ahead to a very distant hypothesis... it's VRAM usage, turn your textures up.

 

Work through what happens if for example I pick any mission and process then turn my textures up? And I don't reproduce? Or I do. I have actually taken my own settings and it's my bug. But no one else has the problem, so I have to give my steps to reproduce and submit it as a bug. To which someone says... I can't reproduce... and I say, well just pick any steps and any mission... and so on in a circle.

 

Please, steps+miz.

[Pikey]

Since no one is going to provide steps how to get the HMD to crash I will have a last attempt myself and invent how I think it could be done.

 

 

• I'll take textures and set them to high in both cases to force much higher VRAM shuffling.
  
• I'll add MSAA 2x because I saw someone else talk about this, but I dont know why you would add MSAA and Steam SuperSampling, makes no sense, but.. I dunno.
  
• I'll bump Steam SS to 200%.
  
• I'll create a mission with 1000 units. Mostly so others can use it and see if it works for them. I still think the exact mission would be better but since there were mods and it's some scripted server based mission its not a good start point. I will make sure to concentrate on SuperCarrier, F-14B.
  
• I'll invent a process, because throughout 9 pages of people saying they can reproduce on demand, they cannot produce a step by step guide how to do it.
  

 

The process will be (until someone wants to provide one that actually works):

 

 

1) Configure the graphics settings as per my original video with the changed of textures high, MSAA 2x and SSS 200%

2) Load mission attached from the Mission editor

3) Enter blue slot and take the slot on the top

4) Wait until the cockpit has resolved loading and press F10, zoom in scroll wheel on the map, press F2, F3, F1 then ESC

5) Pick the next slot down from the last and repeat step 4

6) Continue steps 4 and 5, cycling through slots waiting for the HMD to go black and crash.

 

With problem reproduced supply accompanying DCS trk file, DCS logs, dxdiag, Steam VR logs (as per Rob) and as much info as you can find and post into this thread Reproduced with the information attached.

 

If no one can reproduce, then come up with some other steps that do work for at least the people reporting the issue.

 

FWIW didnt work for me, I just got an unplayable game, frametimes exceeding 100ms and a pointless excercise of deliberately trying to break my game and working settings because what else can I do, no one else seems to want to do what needs to be done.

 

Will post the video later.

VRHMDcrash.miz

Edited October 17, 2020 by Pikey
adding miz

[RealDCSpilot]

Back from the depths of the forum: https://forums.eagle.ru/showthread.php?t=236834

[Pikey]

So I ran the above test today and whilst YT is still trying to do the higher res version, it still shows how hard I pushed the PC.

 

I did everything. I made my computer burn. The stench was concerning. I could hang the entire computer for minutes at a time but the HMD was still fine.

 

I did this for 30 minutes, reloaded and turned the settings back to the workable ones with the video still recording.

 

 

No HMD crash.

 

The only thing I can conclude is that this is not stress or texture related at all. The more obvious conclusion is that you require to run settings that will not be running DCS well so there seems to be little point in actually running DCS at these levels, at least on my hardware.

 

Give me steps to reproduce, I can't do anything more to help.

[Pikey]

 

Very genuine/serious question for you, that I'm hoping you respond to: In the interest of getting steps that work for people that are, lets say less impacted would cranking various things like Steam SS to an unreasonable amount in the interest of just replicating the crash for debugging purposes be helpful? Obviously, the pushback would be - hey nobody is going to do that, which sure. but if the only goal is getting to steps that cause it 100% of the time would this be valid?

 

 

I'm only interested in the precise steps that do it for you, im not interested in if it crashes for me, you are guessing ahead too far and not understanding the purpose. If you crash and I dont, I change my config to yours. I've explained this umpteen times now, don't overthink any of this. We need to have a baseline to work on. Guessing with statements like "A mission like TTI" doesnt work. I dont even know what TTI is. Statements like 150-200 SSS doesnt work either. Say what number exactly.

 

 

 

To answer the question (i think...its difficult to understand it)

 

After running settings that gave me 9 FPS I'm not sure of the value of running the sim at these settings. VR has and always will be a trade off between performance and visuals. That's a given. But that's not for me to say, that's for ED to decide to say if they support such a setting. If it reliably breaks the HMD then its still useful information, imo. But its still not useful for people in general.

[RealDCSpilot]

Guessing with statements like "A mission like TTI" doesnt work. I dont even know what TTI is.

 

Okay, now we get closer to the source of a misunderstanding. Please excuse my english, i have to translate everything and it's hard to be exactly precise sometimes.

 

I have to make this guess here, the source of the problem isn't a bad line of code causing an illegal function call somewhere that leads to a crash, it's definitely not that kind of bug. You will never find a step by step procedure to nail it down with 100% certainty that a certain action caused the problem.

 

To be affected by the problem you actually have to play the game in the field. Online, in free for all sandbox missions with other players. If you don't know what the "Through the inferno" missions are, than you seem to play DCS in a different way. I took a look into your mission and found a huge amount of units, yes, but also a lack of variety. Example, having 200 units of the exact same type will make no big difference in VRAM usage. It will just use the amount a single unit of that type needs. You will probably never really run into a problem if you just play DCS in "linear" type of missions, were you basically choose one aircraft, do your mission, finish it and the mission is over.

Missions like "Through the inferno" are very popular online, because you can join them and do whatever you want. All the variety that DCS is providing is available there, you can choose every module, use every weapon. You can choose to train carrier landings in a F14, another group of players in A-10s is attacking an enemy airbase over 100km away, while on the other end of the map a player tries slingloading containers with a helicopter. These kind of missions are usually named "...freeflight...", "...training...", "free for all...PVE" etc.

A typical online session can take 30 minutes or 4 hours, including switching to all sorts of modules, from jet to helicopter to WW2 aircraft. The server itself will always run 24/7. In these missions the problem is very common for some of us, it can happen after 10 minutes or after an hour. If you are lucky, you only get the frame drop problem for 5 or 10 minutes and it sorts itself out after a while. But since a couple of weeks, Steam VR crashes occur more often and it's not a new problem: https://forums.eagle.ru/showpost.php?p=4379001&postcount=3

 

It really looks like a problem of bad or incomplete memory management. Instead of clearing memory resources after i choose another jet, DCS just stuffs the next jet's textures and geometry into VRAM and then the next one and the next one until VRAM is full and then memory swapping starts, trying to sort it out somehow. Sometimes Steam VR is the weakest part in this, and crashes.

The only way to prevent the problem to occur seems to be having a GPU with lots of VRAM, since i got my RTX3090 the problem never ever happened again on my end. DCS now uses a huge chunk of it, up to 17/18 GB.

Edited October 17, 2020 by Alec Delorean

[Stal2k]

Since no one is going to provide steps how to get the HMD to crash I will have a last attempt myself and invent how I think it could be done.

 

 

The process will be (until someone wants to provide one that actually works):

 

 

1) Configure the graphics settings as per my original video with the changed of textures high, MSAA 2x and SSS 200%

2) Load mission attached from the Mission editor

3) Enter blue slot and take the slot on the top

4) Wait until the cockpit has resolved loading and press F10, zoom in scroll wheel on the map, press F2, F3, F1 then ESC

5) Pick the next slot down from the last and repeat step 4

6) Continue steps 4 and 5, cycling through slots waiting for the HMD to go black and crash.

 

With problem reproduced supply accompanying DCS trk file, DCS logs, dxdiag, Steam VR logs (as per Rob) and as much info as you can find and post into this thread Reproduced with the information attached.

 

 

I grabbed your mission as was able to prompt the crash. I realized I didn't do the steps EXACTLY as you listed so I will do this again, in the mean time I did want to supply the video with the realtime SteamVR log. I couldn't get a trackfile because of the way the game exits, but everything else is providable.

 

FWIW it was actually harder to prompt the issue on your mission than the original which was notably lighter. I know you hate speculation :) but it felt like I REALLY had to try make it crash on this mission whereas in the old one you could attribute the actions neccessary to normal use. Without knowing much about how DCS handles this sort of thing, the one item that sticks out to me is the number of slots - on big servers and the original mission I used there were a lot of slots, could be nothing but it was interesting.

 

I really am sorry I didn't read the full post to understand the exact steps and settings you want used. Mine are currently more conservative (included in the zip package) but I hope the video with the telemetry is still worth it.

 

Two notes, 1) If it's not clear from the FPSVR capture my SteamVR SS was at 150% and the HMD blacks out when you see DCS crash happened on the F2 press at 3:42 and the logs settle at 3:58. You can also see DCS disappear from the SteamVR window on the bottom right as a good indication of when it blacks out.

 

Again, sorry I didn't follow you directions exactly - I will do it again, but since I'd already recorded it I didn't want to just scrap it incase there is insight you or anyone else can gain from the view that I'm not seeing.

 

DCS VR HMD Crash Instance 1 Logs.zip

[Stal2k]

@Pikey

 

Here you go, all your steps were meticulously followed. I did get it to crash using those steps albeit it took longer then when hitting F2 multiple times, I was able to actually call the crash before it happened @6:37.

 

One thing that does seem consistent amidst the chaos here is that going to a slot on the super carrier after you've effectively been somewhere else is consistently causing this between my original mission, this instance and when it happens to me during normal gameplay. Not saying it's the SC because it's happened in plenty of places where there wasn't a SC to be found, but it makes it easier to do "on purpose."

 

Same deal as before with the trackfile, there just isn't a great way to grab it due to the way the game exits. Am I correct in thinking this is more of a nice to have since it's not going to mimic the camera changes? If it's going to be a gamechanger let me know of any workaround you can think of.

 

I guess, if nothing else the steps you have listed do work in reproducing it for me, it just takes awhile longer. It'd be great if someone else having this consistently would take a stab at reproducing it with the steps Pikey outlined.

 

 

edit: I'm an idiot and linked wrong video

 

Steps for reference:

 

1) Configure the graphics settings as per my original video with the changed of textures high, MSAA 2x and SSS 200%

2) Load mission attached from the Mission editor

3) Enter blue slot and take the slot on the top

4) Wait until the cockpit has resolved loading and press F10, zoom in scroll wheel on the map, press F2, F3, F1 then ESC

5) Pick the next slot down from the last and repeat step 4

6) Continue steps 4 and 5, cycling through slots waiting for the HMD to go black and crash.

DCS VR HMD Crash Instance 2.zip

[RealDCSpilot]

@Stal2k

 

Would you mind to do another test? DCS is always a bit behind with the latest version of the openvr.api. Currently it uses version 1.0.10.0 while the official api is at 1.14.15.0. You can download the latest version here: https://github.com/ValveSoftware/openvr/blob/master/bin/win64/openvr_api.dll

 

Just place it under \DCS_World\bin and backup the old file. This should rule out any incompability issues with the latest version of SteamVR. Maybe it is a bit more bulletproof in stress situations, maybe not.

Edited October 18, 2020 by Alec Delorean

[Stal2k]

@Stal2k

 

Would you mind to do another test? DCS is always a bit behind with the latest version of the openvr.api. Currently it uses version 1.0.10.0 while the official api is at 1.14.15.0. You can download the latest version here: https://github.com/ValveSoftware/openvr/blob/master/bin/win64/openvr_api.dll

 

Just place it under \DCS_World\bin and backup the old file. This should rule out any incompability issues with the latest version of SteamVR. Maybe it is a bit more bulletproof in stress situations, maybe not.

 

Sure I'll do it later today and let you know. Do you want the full video/logs I just did or would a simple yes / no to the crash suffice?

[RealDCSpilot]

It's just a simple guess, yes or no will be enough.

[Pikey]

Amazing! Excellent! Right, now we are cooking on gas. So we can get a reproduction but it still seems the mission is at least a little in play, which is a concern. You are right, my mission is not as complex as TTI. That's deliberate, we need to make the miz as simple as possible, avoid code, it just confuses the issue and ED wont accept mods and scripting, they are pretty fussy on that, but I believe we don't need mods or complexity to reproduce it.

However, if you can think of ways to generate this condition faster using the same mission, or even much smaller, let me know.

 

So I have lots of questions!

 

1) Is the problem defined as DCS 'crashing', or the HMD crashing? Or ... as might be the case, is DCS crashing because the WMR crashed, because that's normal and I can repro that by leaving it to sleep for long enough. Sorry to return to the problem statement but I was under the impression the fault was the HMD going "black" with the DCS mirror still renderign away like in the OP. Please clarify, it's pretty important. If I had to guess based on what I saw, SteamVR decided to give up. DCS logs closed normally, Steam says it was unresponsive and detached.

 

2) Do you have the lighter mission, can you remove the A4 mod and refine the steps so as to get this to happen faster? You dont have to, but if you think you can, it's best for simplistic reproduction. I think we are learning here how to make VR crash, so eventually we should be getting the steps shorter and clearer.

 

3) On your DCS options picture, this is a perfect way to share the settings, except when I read them, it generates a question because MSAA is equal to 1 and we all know MSAA starts at 2x. Can you verify this and any similar oddities please? Is it 2x?

 

4) Starting SteamVR Home launch beacuse system.generated.dcs.exe exited after 480.214270 seconds

This looks like the point of the crash. Can you keep an eye on that line on every crash to see if this is correct. I think steam is saying that it cannot get hold of the DCS.exe process. Which, let's be honest, sounds about right when the system becomes unresponsive. I think this is the cause of this "crash" at least. But this throws everything into confusion for me. I thought this was an HMD crash.

 

5) Why are the videos ending with DCS still running, but the logs show DCS recieving a shutdown command? I'd really like to focus more on the last seconds to understand exactly what is happening to you as I am not sure I even know the problem description at this point with certainty.

 

6) Which log are you tailing in the video? Doesnt seem to match the Steam ones you put in the zip :(

 

7) Are the DCS logs you attached synched with one of the videos you uploaded? If so please indicate which one. This log shows a normal DCS shutdown. That's thrown me, i didnt expect that at all (am trying to reproduce steam closing DCS right now.)

 

8] Do you have the Steam VR setting "Fade to grid on app hang" on or off?

 

9) DCS Logs review. I've got plenty to discuss and ask from you at this point, theres a lot of logs that have aroused my suspicion and need to be ruled out. Here we go

 

a)

2020-10-17 21:05:29.480 WARNING DX11BACKEND: Shader posteffects/nvd_hdr.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/nvd_hdr.fx is modified.
2020-10-17 21:05:29.736 WARNING DX11BACKEND: Shader effects/pfxdust.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/effects/pfxdust.fx is modified.
2020-10-17 21:05:29.950 ERROR   EDCORE: Can't open file 'bazar/shaders/posteffects/slot.fx.' from fs
2020-10-17 21:05:29.950 WARNING DX11BACKEND: Shader posteffects/slot.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/slot.fx is modified.

This is a no-no, can't be having custom shaders and reporting bugs. If you aren't aware of what you have done/modified then perform a repair, it's just going to be the first thing ED say and they wont touch this with someone else's ten foot barge pole ;) Compiling on the fly causes a lot of extra load. I always recommend loading a mission after a new install and tailing the logs whilst loading a mission with every unit until the logs run clear. Is that what you meant by having lots of unit types? If so... something to consider.

 

b)

2020-10-17 21:05:37.305 DEBUG   LuaGUI: can't open './Config/Input/UiLayer/keyboard/Keyboard.lua'
2020-10-17 21:05:37.308 DEBUG   LuaGUI: Input:    can't open './Config/Input/UiLayer/keyboard/Keyboard.diff.lua'

these and then pages of issues with your inputs, I do not understand. It's not normal. Probably not important, but I thought I'd point it out.

 

c) Make sure Tacview export is switched off. I had huge performance savings with this, I ran it loaded but not doing much.

TwitchtoDCS...I'm not happy with this one as I can't verify it works OK or has no effect. If you can comment him out during testing, that would be great. I believe there is a hook involved to the screen at least.

 

d) Your pagefile is half mine and I dont mess about with pagefiles. Not good when we are using all the 32GB, right? There is always usage of page files if they exist, for every pagefile removal top tip, I'll give you a broken VMWare Admin having an argument with Microsoft. Don't manually configure pagefiles, it never helps. If you want, put it on another fast disk not used by OS or Game.

 

Mine: 2020-10-17 13:19:02.717 INFO DCS: CPU cores: 6, threads: 6, System RAM: 32699 MB, Pagefile: 29770 MB

Yours: 2020-10-17 21:05:13.846 INFO DCS: CPU cores: 8, threads: 16, System RAM: 32715 MB, Pagefile: 12800 MB

 

e) The pylons mod - VARS. I reported a graphical glitch with this... night time lights were screwed: Check oil platforms. I dont trust it and its been off my HDD ever since i looked like an idiot reporting it to BigNewy and no one could reproduce. Same advice applies, it does more than is says on the tin.

 

f) Gave up counting the other mods, but if we really want to compare like for like, you need to get much closer to vanilla. There's only one thing you need to know... mods can and do screw with things in interesting ways that you would have thought completely illogical. I'm not saying anyone of them is causing this, but whilst its in doubt, test vanilla for your own sanity. You've literally got every single one that is well known and even some I wasnt sure of. It's unhealthy for the support process of comparing like to like.

 

g)

2020-10-17 21:07:14.393 ERROR   DX11BACKEND: Can't find precompiled shader enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;.
2020-10-17 21:07:14.393 INFO    DX11BACKEND: Compile shader: enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;
2020-10-17 21:07:14.432 ALERT   DX11BACKEND: Error: Can't find precompiled shader for effect enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;.
Recompilation process will take some time, please wait
(this situation should not occur on end user PC, if there is no manual shader editing)

raycursor.fx

glass_instrumental_material.fx

A couple of these. Is this a recent reinstall? You shouldnt need to be compiling shaders on the fly unless you've only just installed DCS and have no shaders precompiled. This is a sign either of some shader tinkering or a new install or you saw a texture shader that you hadnt seen before, which is kindda odd. Again, vanilla, you cannot guarantee 3rd party changes are great from version to version. ROT: Tinkering makes it worse ;)

 

h) Last but not least:

2020-10-17 21:13:15.224 INFO DCS: application shutdown

Graceful shutdown, nicely logged. I've no doubt that part of the cause is DCS doing something, but its very much pointing on this log set like Steam killed DCS, rather than the other way around.

 

Next steps

I need to resolve some information about which logs matches which video. Especially the dcs log with the 'normal shutdown', the Steam log, which is in the video but I cant find in the log bundle you sent. I could come up with an early hypothesis that Steam is closing DCS when it doesnt see it. This doesnt make sense, maybe DCS closes itself when it doesnt seem steam, I am not a developer so the last seconds before death are pretty important here. If possible, see what on this list you can take action on, especially with creating parity between a vanilla install and a supportable installation, that's important and not too hard to do.

We also need to resolve the exact problem statement. I thought this was an HMD blackness and the mirror still existed and DCS is running fine. Now its not clear anymore, it sounds like dcs was closed. Please, that's super important, we could be barking up the wrong tree there ;)

[Stal2k]

Next steps

I need to resolve some information about which logs matches which video. Especially the dcs log with the 'normal shutdown', the Steam log, which is in the video but I cant find in the log bundle you sent. I could come up with an early hypothesis that Steam is closing DCS when it doesnt see it. This doesnt make sense, maybe DCS closes itself when it doesnt seem steam, I am not a developer so the last seconds before death are pretty important here. If possible, see what on this list you can take action on, especially with creating parity between a vanilla install and a supportable installation, that's important and not too hard to do.

We also need to resolve the exact problem statement. I thought this was an HMD blackness and the mirror still existed and DCS is running fine. Now its not clear anymore, it sounds like dcs was closed. Please, that's super important, we could be barking up the wrong tree there ;)

 

edit: Cleaned up response to #1, corrected repsonse to #6

 

I'm going to try to respond inline to hopefully reduce clutter and (maybe there is a better way) fiddling with quote shortcodes. My response is in orange

 

----Begin response | Pikey text = Black, Stal2k = Orange

 

1) Is the problem defined as DCS 'crashing', or the HMD crashing? Or ... as might be the case, is DCS crashing because the WMR crashed, because that's normal and I can repro that by leaving it to sleep for long enough. Sorry to return to the problem statement but I was under the impression the fault was the HMD going "black" with the DCS mirror still renderign away like in the OP. Please clarify, it's pretty important. If I had to guess based on what I saw, SteamVR decided to give up. DCS logs closed normally, Steam says it was unresponsive and detached.

 

Ok, I don't want to confuse you, short of setting up a webcam looking into the lense - I'll describe it and you let me know if it suffices. This is true for both the Rift S and Valve Index. 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.

 

2) Do you have the lighter mission, can you remove the A4 mod and refine the steps so as to get this to happen faster? You dont have to, but if you think you can, it's best for simplistic reproduction. I think we are learning here how to make VR crash, so eventually we should be getting the steps shorter and clearer.

 

I do, and I will remove it and verify no mods as I've instanced a vanilla DCS instance for this testing. I'll supply it in a follow on post

 

3) On your DCS options picture, this is a perfect way to share the settings, except when I read them, it generates a question because MSAA is equal to 1 and we all know MSAA starts at 2x. Can you verify this and any similar oddities please? Is it 2x?

 

Sorry, that was me being lazy since I forgot to screengrab them in either video or static form. MSAA 1 means the 1st option in DCS, so ya 2x as you noted 0=off 2=4x.

 

4) Starting SteamVR Home launch beacuse system.generated.dcs.exe exited after 480.214270 seconds

This looks like the point of the crash. Can you keep an eye on that line on every crash to see if this is correct. I think steam is saying that it cannot get hold of the DCS.exe process. Which, let's be honest, sounds about right when the system becomes unresponsive. I think this is the cause of this "crash" at least. But this throws everything into confusion for me. I thought this was an HMD crash.

 

It is, as you noted DCS continues to run albeit in an odd state. It selectively responds to inputs (like keyboard) but it runs in the mirror at the equivalent of a ~4-5fps chug (I'm making an analogy here, not saying it's actually hitting 4fps). For example, when I actually exit it in the 2nd video, it doesn't respond to the ESCAPE command on the keyboard, but if I hit the little X in the window via mouseover on the windows taskbar, it will give the in-game optionto exit, I can click yes so it seems to take mouse but no keyboard input. A good way to approximate when the HMD is shutting off is when you see DCS say something about losing the TRACKIR input, or right when the crash happens the mirror will freeze up momentarily.

 

5) Why are the videos ending with DCS still running, but the logs show DCS recieving a shutdown command? I'd really like to focus more on the last seconds to understand exactly what is happening to you as I am not sure I even know the problem description at this point with certainty.

 

I was trying to get you a trackfile, normally if I just hit restart VR DCS will force close. Even though DCS is running, it's in a very strange state as it selectively takes inputs (mouse only) and runs like it's in a ~5fps state. I try to verbally exclaim when it's crashing as I have maybe a 1-1.5 second window of when I can see it coming and that the VR mic will still take input.

 

6) Which log are you tailing in the video? Doesnt seem to match the Steam ones you put in the zip

 

It's sort of an amalgamation of the logs, I've adjust this to include which log is being reported on each line. I accidentally omitted the VRSERVER log from the archive, which is where you see the bulk of the relevant lines. In my defense there are 124 different logfiles in that directory :) , the compositor log would be the closest in the packet, my bad. Since I'm redoing this again I'll be sure to include it. I found a toggle to show the logs and can make sure I don't miss a pertinent one

 

7) Are the DCS logs you attached synched with one of the videos you uploaded? If so please indicate which one. This log shows a normal DCS shutdown. That's thrown me, i didnt expect that at all (am trying to reproduce steam closing DCS right now.)

 

They should be unless I goofed up. DCS is technically shutting down normally for the reasons I've outlined in two other responses. If I need to expand on that further let me know. If it'd be easier I can 'kill' it like I normally would to get rid of information beyond the crash. As I said before I was trying different ways to get a trackfile out of it, if that isn't going to super helpful I'll just end the process quicker either via steamVR restart (forced close) or I can use the taskbar method which prompts a more normal shutdown

 

8] Do you have the Steam VR setting "Fade to grid on app hang" on or off?

 

It's off, that should be evident from the VR on the left, when you see it come up "waiting" many games are really hampared with that setting enabled

 

9) DCS Logs review. I've got plenty to discuss and ask from you at this point, theres a lot of logs that have aroused my suspicion and need to be ruled out. Here we go

 

I'll go through these and answer. I've created a second instance of DCS to use for this from now on to keep everything as vanilla as possible

 

a)

Code:

2020-10-17 21:05:29.480 WARNING DX11BACKEND: Shader posteffects/nvd_hdr.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/nvd_hdr.fx is modified.

2020-10-17 21:05:29.736 WARNING DX11BACKEND: Shader effects/pfxdust.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/effects/pfxdust.fx is modified.

2020-10-17 21:05:29.950 ERROR EDCORE: Can't open file 'bazar/shaders/posteffects/slot.fx.' from fs

2020-10-17 21:05:29.950 WARNING DX11BACKEND: Shader posteffects/slot.fx:DIRECTX11=true;USE_DCS_DEFERRED=1; is outdated as file bazar/shaders/posteffects/slot.fx is modified.

This is a no-no, can't be having custom shaders and reporting bugs. If you aren't aware of what you have done/modified then perform a repair, it's just going to be the first thing ED say and they wont touch this with someone else's ten foot barge pole Compiling on the fly causes a lot of extra load. I always recommend loading a mission after a new install and tailing the logs whilst loading a mission with every unit until the logs run clear. Is that what you meant by having lots of unit types? If so... something to consider.

 

I use two shader mods, one is the removal of flat shadows from everything but the cockpit and the other is the better smoke shader. Just for reference, as I said I've moved this to a new DCS instance

 

 

b)

Code:

2020-10-17 21:05:37.305 DEBUG LuaGUI: can't open './Config/Input/UiLayer/keyboard/Keyboard.lua'

2020-10-17 21:05:37.308 DEBUG LuaGUI: Input: can't open './Config/Input/UiLayer/keyboard/Keyboard.diff.lua'

these and then pages of issues with your inputs, I do not understand. It's not normal. Probably not important, but I thought I'd point it out.

 

This is PROBABLY the result of me moving machines and not wanting to rebind 20 modules. I may have left prior instance of config luas that have the old USB addresses (strings) there. To your point I don't think this is causing a VR crash nor would I imagine the number of folks who are experience this issue have went through the same lengths I have to avoid rebinding :) Nonetheless the new instance should help here

 

c) Make sure Tacview export is switched off. I had huge performance savings with this, I ran it loaded but not doing much.

TwitchtoDCS...I'm not happy with this one as I can't verify it works OK or has no effect. If you can comment him out during testing, that would be great. I believe there is a hook involved to the screen at least.

 

Done, you are right there is a screen hook

 

d) Your pagefile is half mine and I dont mess about with pagefiles. Not good when we are using all the 32GB, right? There is always usage of page files if they exist, for every pagefile removal top tip, I'll give you a broken VMWare Admin having an argument with Microsoft. Don't manually configure pagefiles, it never helps. If you want, put it on another fast disk not used by OS or Game.

 

Mine: 2020-10-17 13:19:02.717 INFO DCS: CPU cores: 6, threads: 6, System RAM: 32699 MB, Pagefile: 29770 MB

Yours: 2020-10-17 21:05:13.846 INFO DCS: CPU cores: 8, threads: 16, System RAM: 32715 MB, Pagefile: 12800 MB

 

My page file is not manually configured, it's automatically configured. In order to match yours I'd have to manually configure it. I have it on my NVME (C:) drive which is my OS drive, I run games off of other SSDs

 

e) The pylons mod - VARS. I reported a graphical glitch with this... night time lights were screwed: Check oil platforms. I dont trust it and its been off my HDD ever since i looked like an idiot reporting it to BigNewy and no one could reproduce. Same advice applies, it does more than is says on the tin.

 

Done

 

f) Gave up counting the other mods, but if we really want to compare like for like, you need to get much closer to vanilla. There's only one thing you need to know... mods can and do screw with things in interesting ways that you would have thought completely illogical. I'm not saying anyone of them is causing this, but whilst its in doubt, test vanilla for your own sanity. You've literally got every single one that is well known and even some I wasnt sure of. It's unhealthy for the support process of comparing like to like.

 

Totally understand, as I'm sure you understand I've 100% tried removing mods/repair/etc as one of the first steps before I became militant enough to partake in a 10 page thread on it :) I also don't like looking like an idiot, but am perfectly willing in this instance. That is why I went a step further and just made a 2nd dcs instance complete with it's own savedgames folder system.

 

g)

Code:

2020-10-17 21:07:14.393 ERROR DX11BACKEND: Can't find precompiled shader enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;.

2020-10-17 21:07:14.393 INFO DX11BACKEND: Compile shader: enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;

2020-10-17 21:07:14.432 ALERT DX11BACKEND: Error: Can't find precompiled shader for effect enlight/raycursor.fx:DIRECTX11=true;MSAA=2;USE_DCS_DEFERRED=1;.

Recompilation process will take some time, please wait

(this situation should not occur on end user PC, if there is no manual shader editing)

raycursor.fx

glass_instrumental_material.fx

A couple of these. Is this a recent reinstall? You shouldnt need to be compiling shaders on the fly unless you've only just installed DCS and have no shaders precompiled. This is a sign either of some shader tinkering or a new install or you saw a texture shader that you hadnt seen before, which is kindda odd. Again, vanilla, you cannot guarantee 3rd party changes are great from version to version. ROT: Tinkering makes it worse

 

Nope it's not a recent install, I would speculate based on the entries that this has to do with me changing my settings to match yours. I typically have MSAA off, and put it to 2x to align with testing settings. Would it make sense to maybe run the mission first before record? I guess I'm that confident in my ability to crash VR that I just YOLO'd it there :) as you can see from the video I wouldn't say there was any 'unique' slowdown

 

h) Last but not least:

2020-10-17 21:13:15.224 INFO DCS: application shutdown

Graceful shutdown, nicely logged. I've no doubt that part of the cause is DCS doing something, but its very much pointing on this log set like Steam killed DCS, rather than the other way around.

 

I agree, that is why going back to my original post I think this issue is severely underreported and hard to get someone to take seriously (#triggerwarning Bignewy :) ). I've found it's best to look at it like a BSOD being caused by an application, sure it isn't the app itself crashing, but you get my point. The way I kind of rule out Steam as the culprit is the fact that it happens on the Rift as well. That completely sidesteps Steam, yes it happens to WMR HMDs as well but the relationship between SteamVR and WMR is pretty incestual so it isn't a free pass for Steam.

 

On that note, and perhaps an important detail I have not mentioned simply because I'm assuming it's a non factor based on the amount of people experience this, because I DO have both Oculus and Steam HMDs, DCS standalone will open the Oculus software alongside SteamVR. This isn't avoidable and is quite annoying. I assume it's benign enough but as you've noted, dumber things have happened. To be clear 1) My rift and Index aren't plugged in a tthe same time and 2) When I've crashed it on the Rift I wasn't running the Rift through SteamVR.

 

Other items you didn't ask, but inevitably come up in this type of troubleshooting are

• Tried different USB ports, 2.0 3.0 different controllers etc
  
• Aggressively disable Windows USB power maangement
  
• Have a sufficiently powered system (800w)
  
• Not using CPU or GPU overclocking, and as you can see from the FpsVR temperature isn't an issue
  

 

---End Response | Stal2k text = black

 

I'll work towards getting another video together with the new instance. While not a showstopper, I would like your thoughts on the pagefile item. Should I effectively double it? If that is the issue I can certainly see that lining up with the amount of folks reporting this. If @VirusAM is still following this, that would be an interesting point of comparison since our systems align closely and he seems to sidestep the crash. Otherwise, the action items for me are

 

• Testing with Alec's suggestion of using the most recent OpenVR api.dll file, I'll be explicit about this as a one off unless it gives positive results (wouldn't that be nice)
  
• Either Adjust OBS to capture the full steamvr area to include the SteamVR fail window or work out some other way to denote the crash. Previously I've tried to do this with timestamps
  
• Remove the A4 from my original mission and share that out
  
• Make sure I include the vrserver log in the next packet
  
• Attempt to crash both with your previous steps and see if I can cause it more quickly using something repeatable. Without question I can crash it faster, but documenting the exact button presses would be difficult and likely not always result in a crash in the exact spot
  
• I would like feedback on the pagefile, because of the things we've covered off on I can certainly see that lining up with where I think we are ALL looking at this point. I'll spare my thoughts on how reasonable it is to expect people to know they need to manually set page files for a videogame vs fixing the problem to myself for now :)
  

Edited October 18, 2020 by Stal2k
clarification on two items

[Stal2k]

Alright I ran several more tests and crashes. Unfortunately, I’m at a 100% success rate here. There were times I tried some of the things mentioned before, like the most recent OpenVR API and also upping my page file. I know between this post and last it’s a lot, so I’m going to try to keep this brief and just answer any questions you have afterwards. Graphic settings never changed, I include an archive of all the relevant logs broken out by package – there are some redundancies here like the dxdiag and my settings so they can standalone with minimal effort.

 

General observations:

 

• Vanilla DCS was actually easier to crash and ran worse than my modded version, which makes sense since one of the two shader mods are is geared toward better vr performance (no flat shadows except cockpit)

• Upping my page file also seemed to make things worse, the game chugged from the get go and never really stopped

• I arrived at a standardized set of 7 SteamVR logs, basing this off of the web console

• I tried to move my head noticeably when switching roles to help identify where the HMD blacks out, the Window will appear just to freeze, keep in mind that is the VR mirror being captured and not the DCS window itself

• When the headset blacks out, the external lights do remain on, so it isn’t a full power down but the screen certainly is off

 

Getting in front of things a developer might say

 

• Yes, I forgot to grab the dcs.log on package 7, by the time I realized I had already ran DCS twice. I don’t think that it’s unique enough to invalidate the result as its not different than the scenario in package 4

• I know how much this looks like it is a hardware issue on my end, especially when we’ve ruled out mods and even some modules via the vanilla install, before blaming my hardware like a bad HMD/memory DIMM/GPU please remember how many other people are reporting this issue, it’s not like it’s mistakable either since the HMD actually blacks out

• My temps were in line w/ normal

• Nothing is overclocked

• Index HMD is actually pretty new

• My relevant software is up to date, this issue has existed across at least 3 different NVIDIA drivers and multiple SteamVR versions (both beta and ‘stable’)

 

Notes

 

The single attachment to this post contains all the logs and missions used for reference. I’m using your original mission, we will call it “mission 1,” mission 2 is the same as the original post, minus the A4, mission 3 while not used in the tests directly is an NTTR version of 2.

 

Package 3: The precursor to this wasn’t captured, you will just have to trust me. I fired up my primary copy of DCS with the A4 in order to remove it from the test mission. After that I opened up the NTTR version of effectively the same mission to pull the A4 from it as well. The game chugged, as I said before it can happen in the mission editor ESPECIALLY when you select the list of units on the left. I exited the game normally, turned on the recording and went to fire up my vanilla instance and it crashed upon loading. So, in effect, the lead up as Alec described perfectly in post 4526701 persisted across DCS instances. When the crash happened on loading you can see the ram/vram isn’t even full, just some I/O. I included logs from both the primary and vanilla copies of DCS

 

Package 4 – Mission 1: This one was a bit of a happy accident, I forgot to install the super carrier to my vanilla instance and still crashed it using our current steps. The SC slots are airstarts. This is good because the issue didn’t start for me until after the SC came out, this would rule out the SC just existing as a cause. Otherwise, this package represents evidence that we can crash it using the steps on a vanilla instance of DCS.

 

Package 5 – Mission 2: This is a long one so I’ll just hit the highlights. The intent was to use what I saw in package 3 and see how it impacts the game, and that buildup that is experienced just by playing it somewhat naturally. I loaded up 2x missions into the editor and hit the unit list to intentionally introduce load that would end up persisting throughout gameplay. I then load up the mission and dance around with the AI for a while, the performance is pretty bad overall, it’s something I learned how to fix by alt tabbing for a few, I didn’t do it for the sake of this test and just let it ride. Things get interesting at the 22:56 mark where the game actually crashes SteamVR while paused and just running amok in effectively the background. Other than that not that interesting, included it because I recorded it.

 

Package 6 – Mission 2: I updated to the latest openvr_api.dll file (1.0.10.0) per Alec’s suggestion, as a note I reverted back to the included version for the next tests. This one was pretty typical of a natural occourence of this crash. I loaded up the mission, spawned some AI and then switched slots. This instance is probably the closest to when this happens out of the blue to me, as I wasn’t trying to prompt it and the performance was actually ok right up until it happened.

 

Package 7 – Mission 1: For this test, I upped my pagefile to 32gb minimum and let it run up to 46gb+ to give a substantial buffer. I fell back to our published steps and actually crashed the game quicker than usual only making it to slot 3 of the mission (the harrier)

 

Package 8 – Mission 2: This test is along the lines of replicating package 6 but with a bigger page file being the only difference. I went for normal gameplay, spawning AI to kill and didn’t get very far. Again not trying to prompt anything it actually crashed here without having to swap slots.

 

 

 

 

 

 

DCS VR Crash Packages 3-8 and missions.zip

[Pikey]

Hi Buddy.

It might be time to take a little break from this so it doesn't consume you. There is a tonne of data here, thanks for the responses. Actually something has surprised me here in the depths of the detail and it's weird and its the top most thing that came to mind, from the innocuous question, "Are we troubleshooting the same thing?"

 

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".

 

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.

 

As something of a comfort, the way the problem is now defined is both useful data and indexable by Google for other headset usage too. So it might be a lot of work, but its for the communities benefit.

 

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'm going to take another shot at this but try to get closer to your setup based on what extra details came out of the reproductions you did. I also will see if I am missing something.

 

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?

 

I'll check back in later today or tomorrow, whenever i get the time to review the videos.