Istari6

OK, thanks for the quick response! Given that diagram above, I may try seeing if I can get an extra 5 AoA on the aircraft when I'm flying the E and have it perform equally to the "hard wing" in this campaign. Only at the 3rd mission (just learned Lag Pursuit, Lag Roll and Butterfly Setup), but it's a fantastic campaign so far. Great job.

(First, apologies if this has already been answered in another thread. I skimmed all thread titles and didn't see this mentioned, trying not to read through each topic to avoid any spoilers for the campaign) I just completed the 1st mission (teaching STR, ITR, Loop and The Egg). Loving Reflected's careful attention to detail, teaching us exactly how to execute these different maneuvers in terms of precise speeds, AoA, etc. The solution of flipping the auxiliary switch to "lock out the slats" is a great solution to give us "hard wing" F-4B/J handling. However, I'm wondering how to apply these lessons when I return to my slatted F-4E after this campaign. Do I just add 5 units AoA for each maneuver? (e.g. instead of 15-16 AoA for STR, hold 20-21 in the F-4E). There's the Top Gun concept of "you fight like you train", and want to be sure I adjust my lessons so I'm not flying "hard wing" style later when the E might be max performed with different numbers. I came across the following chart in the forums which apparently comes from a McDonnell Douglas brochure about the F-4E:

It's a generational leap, and the Fulcrum wasn't just 4th generation, it was perhaps the best pure WVR dogfighter of the 4th generation. The Phantom was 3rd generation, and it wasn't even particularly good at WVR dogfighting in the 3rd generation - see MiG-21 for a better 3rd gen dogfighter. So it's not just 3rd gen vs 4th gen, it's "average" 3rd gen dogfighter versus the "best of the best" 4th gen dogfighter. That's a big leap in technological quality, and unless the other pilot makes major mistakes, you're likely doomed.

The Viper has had a lot of Early Access issues. My group experienced major issues with CCIP accuracy and GPS-guided weapons missing due to winds aloft. I even logged a bug report with ED showing methodically through a controlled test how inaccurate JDAM, JSOW and WCMD were with any winds aloft. They never replied beyond "we're looking into it", but I did notice that they listed a fix in a recent update, a year later. So I wouldn't be surprised if the Viper just had a bugged RWR earlier.

That's very strange. On the inability to detect the MiG-23s CW signal, I'm 95% sure I've heard MiG-23 launch alerts when I was flying the Tomcat. But it also seems strange that the USAF fitted RWR antennas that weren't tuned to cover the threat band of the F-4s greatest air-to-air threat in the 1970s. I trust Heatblur has done the research and this is how the real F-4E-45MC worked. Just trying to understand why the USAF would possibly implement such a system?

Having learned to fly the F-4, I'm now moving into learning the weapons and defensive systems before diving into Reflected's "MiG Killers" campaign. Just diving into the ALR-46 and how it operates, and was surprised to see the wide array of threats where the ALR-46 cannot detect a launch. In particular, I was struck at the tables in the Heatblur manual that listed the following threats as providing no warning on launch: * SA-5 * SA-11 * MiG-23 * F-4 Wouldn't all these systems work by SARH? Why wouldn't a mid-1970s RWR be able to detect the CW signal of weapon guidance and alert the pilot? It seems like fighting the MiG-23 in particular will be more challenging without knowing we've had an Apex launched at us. (BTW - I know that there's no warning for IR-guided systems like SA-13, that's understandable)

So an update two months later... I've been using a Quest 3 headset to workaround the CTD issue. It's much inferior to the Varjo Aero, but at least I could continue to fly with my friends. I was reluctant to buy a new CPU until I could prove it was malfunctioning, but none of the tests were showing anything. The news of the Trump tariffs forced me "off the fence", and I bought a new i9 14900K before prices rose. It was a bit of gamble, but I really miss flying DCS with high-resolution and a stable framerate. The good news is that it worked. I've now flown multiple hours in DCS without any CTD, including several missions that were reliable triggers in the past. I think that SharpeXB and others on this thread were right, and my original i9 was damaged due to incorrect BIOS settings. Thanks for pointing me in the right direction, it's great to be flying DCS "properly" again.

Hi all, I've encountered exactly the same problems. I actually went to the trouble of spending many hours analyzing the issue, isolating variables, generating track files. I found a reproducible issue, and ruled out many others. I tried to be as helpful as possible, explaining my methodology and offering to add track files. See thread here from January: @Lord Vader replied and stated it was raised internally for analysis. But the thread was locked and I've seen nothing else on this issue since.

Yup, it's a 14th Gen Intel CPU: Intel Core i9-14900K. No other games are having the same problem I'm having in DCS. I was hopeful that updating the BIOS would solve the problem (perhaps due to the microcode fix), but I just updated the BIOS from the Corsair Support site, and boom. DCS crashes again. So updating the BIOS hasn't solved the problem. OK thanks @Flappie. Updating the BIOS hasn't worked, I'll next dive into the BIOS and see if I can adjust the settings around 253W for PL1/PL2 as you're suggesting. More once I try that... @SharpeXB - thanks for the background on your issues with the 14xxxx chips. I'm starting to wonder if my CPU was similarly damaged, given I had solid performance from this machine for almost 12 months, now it's a continuous problem that i can't seem to fix. I've just updated the BIOS, hasn't helped. Crashed again within 5-10 minute of mission start. Do you know if there's any way to verify a damaged CPU? I've run Prime95 and several other benchmarking tests that stress the CPU, and they haven't shown anything. My Corsair machine has a 2-year warranty, wondering if I can prove the CPU is damaged if I can get a new chip under warranty. Not that you'd know how to navigate Corsair's warranty, but I likely need to demonstrate that the chip is damaged to get a new one sent out.

(Apologies if this has been answered already. I've searched all topics back x 2 years and didn't find anything relevant for this problem). ------------------- I currently use the Thrustmaster Warthog joystick, Warthog throttle and TPR rudder pedals. I've used these with the TARGET software for years without any issues. However, last week I had to "factory reset" my PC and reinstall all software from scratch to deal with a nagging technical issue in DCS. Now I'm encountering problems with my Thrustmaster Warthog joystick that I've never had before. Here's the problem: The Warthog joystick, throttle and TPR pedals are all recognized by Windows in the USB Game Controllers window on bootup. All show OK, and when I check them in Properties, they all work properly. However, when I load a profile in TARGET, my PC "loses" the Warthog joystick. It becomes unresponsive. The throttle and TPR seem to work OK after loading a TARGET profile. When I unload the TARGET profile and close the application, the Warthog joystick shows up again in the USB Game Controllers window as OK, but it is unresponsive. Going to Properties and moving the stick or hitting buttons has no response. Only rebooting the PC restores the Warthog joystick back to working normally, until the next time I load a TARGET profile. I've built up a large library of TARGET profiles, and want to keep using them. But right now I can't. In terms of troubleshooting, I've downloaded the latest version of TARGET software, latest version of Warthog drivers and I've updated the firmware for all three peripherals. The problem remains. What can I do to fix this problem? My hardware hasn't changed at all, it's just something that happened with the factory reset and reinstall of the software that's causing a new problem. Thanks for any pointers!

OK I'm back after several days of troubleshooting. First, I'm still unable to play DCS in Varjo VR for more than 5-10 minutes with a CTD. It's immensely frustrating. 2D mode seems to work OK. I've flown several missions with friends in 2D mode without a CTD. The reason for the delay in following up is that it's taken a few days to execute the following steps: Reset the entire PC to Corsair's original factory settings. All previous data wiped. Confirmed a clean SSD, reinstalled everything from scratch including 320 GB of DCS, latest drivers, etc. --> still get CTD, even with this fresh system Rolled back NVIDIA driver from latest 572.16 to 566.14 (September 26th) -> CTD Rolled back Varjo Base from latest (4.6.1) to 4.4.0 -> CTD 3DMark Steel Nova Stress Test - 99.0% (earned Steam achievement "Rock Solid"), all CPU temperatures below 80C except for a single momentary spike to 99.5C across 20 minutes of stress testing. RAM DDR 5 sticks - swapped, checked voltages in BIOS, confirmed 1.35V to both -> CTD Having done a complete reinstall of my entire system from scratch, rolled back both NVIDIA drivers and Varjo Base/OpenXR to earlier configurations (where DCS worked), and done a 20 minute stress test with complete stability, where to go from here? The only information I have are the Event Viewer logs from Windows. There is nothing in the DCS.log files. What I get recurrently are errors like the following: --------------------------------- I do see Flappie's recommendation about a potential solution in the other thread. Thanks for the pointer! See comments below @Flappie: I've reviewed this thread, and the only actionable step seems to be at the end where the author says: " I am lost on what this means. What is a low I2 voltage? Note, regarding some of the other ideas in that thread, they sound reasonable, but I don't think they apply here. I have a "stock" Corsair Vengeance i750 system, purchased 11/2023. 1000 W power supply, nothing OC that I'm aware of. I've not done any changes to the system from the stock Corsair configuration. Stress test shows CPU and GPU temperatures look good. How would I identify if I have something malfunctioning in an individual core during MT operations?

Just to be clear, I haven't solved it yet :(. I realized that the formatting in my original message was unclear, I was cutting-and-pasting from another thread where they had fixed a similar issue. I'm diving back into it tonight, hoping to finally pin this down. I'm "jonesing" here without my DCS fix.

ADDENDUM: Doing a Google search using the search term "0xc00000fd exception Code DCS" cued me to two threads here in the forum: -- - These sound like exactly the same kind of problem I'm having, crashing hard within a few minutes of mission start. The 2nd thread mentions finding and deleting an extra TrackIR profile. That doesn't help me as I don't use TrackIR. The first thread mentions reseating RAM modules, I can try that - although RAM did pass MemTest86+ just fine. But the author in the first post mentions that he the following: Does anyone know what "Deleted temp files, optimise and rebooted" means? What temp files is he referring to? I'm happy to try reseating the RAM, but would love to follow all the steps that worked for him.

Thanks for the additional ideas! I've run a full 3DMark Steel Nova stress test on my entire system, passed 99.0%, no issues identified. I've also done a complete MemTest86+ check on my RAM modules, which passed. So i don't think it's the factory-set overclocking or RAM. On your point about hardware, I did some more testing last night, and I was able to run an entire mission without any CTDs in "flat screen" (2D) mode. This is a mission that is particularly unstable for CTDs, almost always crashes in the first 5-10 minutes. So I'm now thinking it has something to do with the chain of layers to my Varjo Aero headset. I generated more CTDs last night, and plugged the Windows Event Log data into ChatGPT (o3-mini-high) for suggestions. Remember, I'm not getting any error message from DCS and no crash log generated - it just crashes straight to Windows. The DCS log just terminates, no "minidump" or other information. So I'm left trying to use the Windows Event View logs to find out why it's crashing. Interestingly, ChatGPT says the following: What the Logs Tell Us Faulting Module & Exception Code Faulting Module: edCore.dll (a core part of DCS’s engine) Exception Code: 0xc00000fd This code typically means stack overflow, which generally indicates that a function (or a chain of functions) is calling itself repeatedly until the stack runs out of space. Fault Offset: 0x0000000000182e37 This is the location within edCore.dll where the error occurs. Without symbol files (debug information) from Eagle Dynamics, it’s hard to pinpoint the exact function. However, the fact that it’s within a core engine DLL suggests the problem is internal to DCS when executing a particular code path. VR-Only Occurrence You mentioned that DCS runs fine in “flat screen” (2D) mode and only crashes in VR mode. This strongly suggests that the crash (i.e., the stack overflow) is triggered by the VR code path inside DCS. In many cases, the VR rendering or related logic (possibly interfacing with the OpenXR runtime or Varjo-specific routines) may be executing a recursive or improperly bounded call sequence. ------------------- So now I'm trying to figure out what are the "variables" to check in the VR pathway? I also fly IL-2 on occasion, haven't had any crashes there, but that runs in SteamVR. So I'm thinking it might be something in the OpenXR pathway that's causing these crashes, as DCS is the only VR application I'm using with OpenXR. 1. I've updated my NVIDIA drivers to the latest (572.16) after the CTDs started. That hasn't changed anything. 2. I haven't touched anything with OpenXR. Is there a file, driver, or library here that should be updated? 3. I've updated Varjo Base to the latest, will test today. Anything else that I can try to fix in the DCS OpenXR VR pathway?

To confirm my theory that it was the power cord issues you were seeing in the other log, I ran DCS, then deliberately pulled the plug on my Varjo Aero. Sure enough, I get the files below, with the section you were quoting above. This is not the cause of the CTD. Losing power to the Varjo Aero causes a conventional DCS crash (blue pop up windows) with the logs generated below. I know how to avoid this problem. There's something else going that's making DCS almost unplayable for me. What I'm having are sudden CTDs in mission with no DCS .ZIP file generated, nothing showing in the DCS log. It looks like Windows is killing DCS for some reason in the EventView log, but I don't know how to diagnose the cause. dcs.log dcs.log-20250208-033535.zip