Keep getting constant ACCESS_VIOLATION crashes in VR multiplayer

[Snarf98]

Hi, running a new PC here, with DCS, which has been working fine for over 3 months. No issues. Now since a couple of weeks, getting constant crashes when in multiplayer VR, but also when running the game in non-vr mode. Edit: Im using a Quest 2 with openxr. Most recent crash files attached. I've tried the following things:

- The source seems to be irratic, like attached, the error is thrown from DCS.exe, but I've seen it from weapons.dll and other files aswell.

- Removed all custom mods like SRS and Tacview

- Ran a stress test on GPU, removed drivers with DDU in safe mode and reinstalled Nvidia drivers.

- Cleared out FXO and metashaders folder

- Reinstalled DCS completely and ran a repair

- reverted back to v62 of the oculus meta quest software manually, as this was marked as a solution somewhere on the forum

I don't know when the issues began, but I had the feeling at first that it was caused by using ReShade, which I removed as soon as the issues started. But now, after reinstalling, I'm not so sure. I also switched from HDMI to Displayport cable, but since the issues are in VR only (and I've tested both cables afterwards) I dont really think this has something to do with it. 

I'm really puzzled as to what is the cause now, hope someone can help!

dcs.log-20240511-204356.zip

Edited May 12 by Snarf98
Added vr headset model, v62 solution

[silverdevil]

3 hours ago, Snarf98 said:

Hi, running a new PC here, with DCS, which has been working fine for over 3 months. No issues. Now since a couple of weeks, getting constant crashes when in multiplayer VR, but also when running the game in non-vr mode. Edit: Im using a Quest 2. Most recent crash files attached. I've tried the following things:

- The source seems to be irratic, like attached, the error is thrown from DCS.exe, but I've seen it from weapons.dll and other files aswell.

- Removed all custom mods like SRS and Tacview

- Ran a stress test on GPU, removed drivers with DDU in safe mode and reinstalled Nvidia drivers.

- Cleared out FXO and metashaders folder

- Reinstalled DCS completely and ran a repair

I don't know when the issues began, but I had the feeling at first that it was caused by using ReShade, which I removed as soon as the issues started. But now, after reinstalling, I'm not so sure. I also switched from HDMI to Displayport cable, but since the issues are in VR only (and I've tested both cables afterwards) I dont really think this has something to do with it. 

I'm really puzzled as to what is the cause now, hope someone can help!

hello. did you empty the shader folders in saved games\dcs? at the very end of your log, your VR headset disconnected. do you have hot plug disabled in dcs options?

2024-05-11 20:44:21.455 INFO    APP (Main): Device unplugged: [USB] Oculus XRSP Interface

i thought it would be a good test to rename the scripts folder to scripts.bak. there are seemingly script errors in the log too. 

 

PS another idea is known past issues with oculus. what version of software are you running?

Edited May 12 by silverdevil

[Snarf98]

41 minutes ago, silverdevil said:

hello. did you empty the shader folders in saved games\dcs? at

41 minutes ago, silverdevil said:

hello. did you empty the shader folders in saved games\dcs? at the very end of your log, your VR headset disconnected. do you have hot plug disabled in dcs options?

2024-05-11 20:44:21.455 INFO    APP (Main): Device unplugged: [USB] Oculus XRSP Interface

i thought it would be a good test to rename the scripts folder to scripts.bak. there are seemingly script errors in the log too. 

 

PS another idea is known past issues with oculus. what version of software are you running?

 

the very end of your log, your VR headset disconnected. do you have hot plug disabled in dcs options?

2024-05-11 20:44:21.455 INFO    APP (Main): Device unplugged: [USB] Oculus XRSP Interface

i thought it would be a good test to rename the scripts folder to scripts.bak. there are seemingly script errors in the log too. 

 

PS another idea is known past issues with oculus. what version of software are you running?

 

Hi @silverdevil Thanks for your reply.

 

1. Ive removed the folders fxo and metashaders2 from my saved games\DCS folder completely. Not from any other locations, if that is what you ment.

2. I think that was me turning it of and unplugging it since it crashed, but I will double check the hot plug option.

3. Will also try the script rename

4. Know about that issue, from here on the forum as well, and reverted back to v62 manually in an attempt to solve this issue. But it did not make any difference for me.

 

Will let you know how it turns out.

Edited May 12 by Snarf98

[silverdevil]

12 minutes ago, Snarf98 said:

4. Know about that issue, from here on the forum as well, and reverted back to v62 manually in an attempt to solve this issue. But it did not make any difference for me.

i personally do not use oculus. there may be an update past v63. the issue with the oculus was supposed to have been fixed in the past couple dcs patches.

[Snarf98]

Just tried another run, changed these things:

- Hot plug disabled

- Scripts folder in de Saved Games\DCS folder removed

- Reinstalled the Oculus software to run v64 (which indeed should be supported by the latest bugfixes)

 

...but still a crash. I'm still crashing with the ACCESS VIOLATION, but this time with the C:\Windows\SYSTEM32\d3d11.dll as the cause...

A new log attached, I'm still not sure what is happening... Any help is greatly appreciated!

 

dcs.log-20240512-184122.zip

Edited May 12 by Snarf98

[Snarf98]

So I think I found the solution, by searching the forum some more. Just played for over an hour with no issues what so ever. Using other posts, I found that RAM timing issues might be the problem. I've got a AMD B650 Asus motherboard, which I set the ram to EXPO1 for. This should make for a stable RAM usage, although on OC, running on 6400 Mhz, which is the spec for these two RAM modules.

However, there is something going on that trains the memory once in a while when setting it to EXPO1, apparently. Setting it to EXPO2, should train the memory at each boot. Thus, explaining how I got the issue, the training did not take place for a while, making for an unstable system.

Now, for the testing I've just reverted to the AUTO setting, which runs my memory on 5300 Mhz for now. It's stable, and I might experiment with the EXPO2 (which makes for a slower boot, but a more stable system apparently...)

I'm also checking if the RAM combined with my motherboard even supports EXPO, or only XMP. I might have gotten those two mixed up.