Istari6

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

Unfortunately, I'm back. I don't think the Varjo power cable is the cause of the CTD issue I've been having lately. Yes, if the Varjo headset cable gets loose in the socket, I get a "conventional" crash in DCS. I think that's what you're seeing in those .ZIP files. It's a standard DCS crash where the screen freezes, I get a blue pop-up within DCS telling me DCS crashed, and I have to restart. In these cases, the Varjo headset goes black, then comes back on, and the lenses reset for IPD. This is a separate issue from the CTDs I'm having. I've known about those and I know what to do to avoid them (don't bump the cable while putting on the headset). But I've now secured the power cord connection tightly, fired up my standard test mission just now, and very quick CTD within minutes of mission start. No black view in headset, no IPD resizing, etc. I don't think the Varjo is losing power. To support this, I'm noticing that when I look in the DCS Log folder, I see the DCS.log file with data from today right up the moment of the crash. But there's no updated ZIP file. The .ZIP file in the Log folder is back from 2/3/25, I think that's the data dump that happens when the headset gets unplugged. How else can I proceed in isolating a cause? Here's the DCS log from just now, and the .ZIP file that's in the same Log folder. As you can see, one is updated from today's hard CTD, the other is an older .ZIP file, not updated after today's crash. dcs.log dcs.log-20250203-225439.zip

Huh! I knew I was having a problem with the Varjo power cord connection at the headset getting loose, but typically if there would be an issue, it would lose power when I was putting it on. The HMD would go dark, then come back on, the IPD would reset and if DCS was already running, it would crash with the blue error popup message (conventional DCS crash). I'd have to restart DCS if that happened, but it seemed stable once it was on my head. I never had the issue where the HMD went dark and reset once it was on. So it sounds like it's only momentarily losing power during flight, not enough to reset the whole Varjo HMD, but enough to throw off DCS and trigger a CTD. Wild. Thanks for the information! Let me try to better secure that power connection at the headset and see if the CTD goes away. Then I can return and mark this as the "Solution". It's awesome to finally have a lead to pursue in fixing this really annoying problem.

Attached below. The "good" news is that this CTD problem is so frequent that I can easily create additional files if we need more examples. The strange thing is that I had a mission the other day with friends flying the P-51D that went for almost an hour without any CTDs, but F-14 or F-16 and I get CTD within usually 10 min, sometimes less. I've done full Repair multiple times on my DCS installation, and even renamed the Saved Games folder to try to eliminate any corrupt files. dcs.log-20250203-225439.zip

OK gotcha. Sorry for delay in responding, had a busy work schedule the last few days. Just had a chance to fire up DCS to reproduce the issue, and sure enough, crash within 5 min of mission start. See how short the DCS.log is for how quickly these CTDs happen. What else can I provide to help isolate the issue? BTW - I did follow the troubleshooting guide you linked, and I'm definitely category "C: DCS Crashes during a mission" and I'm the first category inside C, "There's no such line". dcs.log Isn't the non-MT version basically retired at this point?

All, I've been trying to troubleshoot a serious recurring CTD problem. It's brought my DCS playing almost entirely to a halt, very frustrating. MAXSenna and sleighzy have been great about jumping into help with ideas. One suggestion they made was to capture the Windows EventView log after these CTDs. I'd never used EventView before, but sure enough, it's capturing each of my DCS CTDs, even though DCS isn't throwing any error messages. Here's what I see in the most recent CTD. Does the community here have any ideas on how I can use this information to help isolate a cause? I'm just totally stuck on where to go next to get DCS working again.

OK, done the following: * Deleted Saved Games\DCS\MissionEditor * Game Mode OFF (it was ON) * Hardware accelerated GPU scheduling OFF (it was ON) * Updated the NVIDIA driver from 566.36 to 572.16 Figured I'd give this a go first before doing Core Isolation and disabling Core Parking. -> CTD again, but more info below... Based on this, I pulled the Windows EventView log, which I'd never used before. Interesting - it is seeing the DCS Application crash, with error codes. See screenshot below, along with newest DCS log file and DxDiag after latest crash. With this info from Windows EventView, does this help narrow down what the cause could be? Nice to finally have some information to work with instead of a mysterious CTD! DxDiag_02032025.txt DCS Crash #1 Feb 3 2025.log