NoTalent

Any chance anyone else here that has been experiencing this bug is running a NLR V3 motion platform (or, possibly any other platform that may use the MotionSystems ForceSeatPM software)? For me, killing MoSyAppWatcherSvr64.exe did the trick, but I prefer to fly with the motion platform so I will continue to use the double launch workaround until this is addressed.

Thanks, @Flappie, I did that before posting here.

This is still a problem for me after updating to 2.8.7.42583. Maybe a new thread would be better or rename this one to include both of the last 2 releases, not sure which is preferred.

I did when this first came up. After working with support, they suggested that I try again after the next release and open a new case if it's still happening.

For me, it's always the same result, no matter how I start (ie.via shortcuts, from the command line, with arguments, without arguments, etc)

The problem for me is, the dcs.log does not get created. Whatever is happening, is happening before log creation. On the previous working release, on my system, there are a full 10 seconds between the creation timestamp of the DCS process and the first entry in the DCS log. Also, I typically see two DCS processes right around the time the splash screen comes up (like a fork/exec of the initial process), but with this release, I don't see the second process ever getting created and there is no splash screen.. the process just exits without leaving anything in the log directory...

Ok, turned out to be a false positive for me anyway. I should have tried more than once to make sure it was working, but it was late. I still have the issue as well...

@gonvise, any chance you are using Voice Attack (possibly even with Vaicomm)? Oddly enough, I ended up upgrading both tonight and now DCS launches fine for me, without having to double launch. I didn't upgrade them thinking it would make a difference, just wanted to bump both to current releases, otherwise I would have done them individually to see if they made a difference. No idea if it's what did the trick, but I haven't changed anything else so it's all I have to go on...

I have the exact same issue, including the application error in the event log with the faulting module as ntdll.dll. I also rolled back to 2.8.6.41066.1 and everything works as before. I opened a support ticket, but with no dcs.log or crash dump generated, don't have much to provide other than my observations.

I have the same issue, G2 on Windows 10 and it was working for me at one point, but doesn't anymore which is a real bummer as I loved it when it was working and have tried everything under the sun to get it working again, but no bueno. I would gladly pay for something that did this as well...

I have tried everything that I can think of, including every combination of WMR and StreamVR beta / non-beta, etc. I've seen a handful of people with G2 + WMR that have this issue and since I had it working with that same combo, but on my old rig, I think there is something environmental with this. It would be great if the developer could provide a fix, but I think there is something, maybe some conflicting software, driver or config that is the root cause of this since it's working fine for most people. It's a head scratcher, for sure.

Thanks Canard. I've tried that as well, in both of the settings in VRNecksafer as well as in SteamVR. It's too bad that there isn't a baked in solution from ED for this for VR users.

For the record, I'm seeing the exact same behavior. I love this utility and had been using it with great success until I got my new system about a month and a half ago. Got everything installed and jumped into a mission, re-centered in the cockpit and as soon as I rotate my head past the first threshold, I'm above the canopy. I've pulled down every version of VRNecksafer and tried them. I had pretty much given up, but if you need any further data to help diagnose, I'm happy to provide as I would love to be able to use this again