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

OK after some more testing, just had another CTD, probably 15 minutes into a mission. This is after renaming my Saved Games folder and then going through and manually setting up options again. The only files I brought back over to my new Saved Games folder were a mission for testing, and my F-14 Kneeboard. Same pattern as before. Mission seems to be going fine, then just crash to desktop. DCS just seems to close, but no popup messages, nothing. I'm just back to my Windows desktop without a clue what happened. Here's the DCS log from the crash tonight and the Windows DxDiag report. Does this provide any clues? DCS - Crash #1 020225.txt DxDiag_020225.txt

Thanks - I would have never thought of wiping out the old Saved Games folder. I did rename it tonight, and so far had a 45 min missions without a crash. It'll take awhile to reset up all the old bindings, graphical settings etc, but promising so far. I need to fly some more time before I can confirm problem fixed, but optimistic so far! I'll do a search on the forum to see if there's any way to read out the old Graphics settings, etc from the old data. I restored the basic Windows 11 power settings, thinking that unparking the CPU cores might have contributed to the problem. That's why they still show as parked. I am trying the approach of wiping out the old Saved Games folder and seeing if that restores stability. If I get another crash, will definitely get that Windows DxDiag report. Appreciate the quick responses so far.

Been flying DCS since 2016. I've really enjoyed being "along for the ride" as it's progressed from the days of "cotton ball" clouds, practically no DLC campaigns and the Caucasus to what we have today. But in over 8 years, I've never had the problems I've started having in the last few weeks. Regular CTD without any error messages, sometimes rendering the game completely unplayable. Tonight I was trying to teach my brother the Tomcat (he's a new brand DCS player), and it crashed 12 times in a single hour . I've had no problems playing other games besides DCS, but just in case it's my system, I've tried the following tests: * 3DMark Stress Test "Steel Nomad" - 99.0% pass. No issues identified. * MemTest86+ - "Pass" x 2 Within DCS, I've done the following: * Removed all mods * Done multiple "slow" Repairs Still getting regular CTDs after the above steps. I've captured multiple DCS logs just tonight, one after each crash. Will include a sampling of three below, I have many more. None have any information in the final lines saying "try to write dump information". What else can I do to fix this? DCS - Crash #1.log DCS - Crash #3.log DCS Crash - #14.log ADDENDUM: The only other item that's changed lately that might be related (?) is per Reflected's YouTube video "DCS 2.9 Optimization Guide in 2D and VR (Quest 2)" where he recommended unparking CPU Cores to remove stutters. I used the utility recommended in his video here: "https://coderbag.com/programming-c/disable-cpu-core-parking-utility". I used it to unpark cores, but after the CTDs, I closed the utility and reset my Windows 11 Power settings to "Balanced" and then "Best Performance", which should have reset CPU Core parking to defaults.

THE PROBLEM My group recently moved to flying "2007 era Vipers" after several Liberation/Retribution campaigns set in other eras (1986, 1996). These other campaigns allowed us to learn the DCS Viper progressively (CCIP bombing in the 80s, HTS/HARM in the 90s, etc). So we know the Viper well, but only recently started using the latest weapons like JDAM, JSOW and CBU-105. In our campaign, we found ourselves repeatedly missing targets with JSOW and CBU-105 WCMD. At first we thought it was due to mistakes in our switchology or understanding of the weapons, but we kept checking and rereading the manual, and still kept missing. This was getting quite frustrating. Finally on our 9th campaign mission when one of us launched four CBU-105s and every single one hit with a similar deviation from the target, we became convinced it must be a mod conflict or bug. RESEARCH TO DATE I've run a series of tests to try to isolate the issue. I created a test mission with flagpoles to mark distance off the target (for deviation) and flew the same approach each time for delivery. Of many variables tested, the only one that controls the behavior seems to the presence of "winds aloft". When winds aloft are blowing, JSOW and CBU-105 miss every time with consistent deviations. When winds aloft are reversed exactly 180 degrees, the weapons miss by exactly the same deviation on the other side of the target. When winds are set to zero, they impact accurately. I've repeated these results over and over to confirm them. Here are some other variables I checked and confirmed OK before submitting this bug: - GPS System Accuracy (DED) - HIGH in all cases - Area Track isn’t being commanded properly - (e.g. check TMS Right bound properly) - bound properly - Once commanded, Area Track isn’t being established - checked symbology in TGP - Once established, Area Track isn’t passing to JSOW - tested via target far off STPT - Laser ranging - done before release in all tests Here's a set of variables tested that showed no effect. - Hot Start vs In-Flight - Map: Syria vs Nevada - XRNeckSafer active vs not running - INS Drift over Time (flying >30 min to target versus start nearby) - Retribution Mission (with included mods like Splash Damage) vs Non-Retribution Mission (with baseline mods) - Single Player vs Multiplayer - Modded DCS vs Vanilla DCS (all mods removed except TacView) HOW TO REPRODUCE Use the attached test missions. - In each, fly an approach to STPT 1 at CRS 190, 24,000 ft and release CBU-105 at ~6.9-7.2nm. Observe impact deviation when winds are present using flagpoles near SA-15 at STPT 1. - Then turn and fly out beyond 20nm and fly same approach (190 CRS, 24,000 ft) and release JSOW at 19-20 nm. Observe impact deviation when winds are present using flagpoles near SA-15 at STPT 1. Track files are included: - In 1st track (Winds), 3:45 is CBU-105 missing wide of SA-15. 9:30 is JSOW missing wide of target. - In 2nd track (No Winds), 3:43 is CBU-105 impacting target, 8:30 is JSOW accurately blanketing wreck of previously hit SA-15. WINDS ALOFT USED This is the Winds Aloft settings I used. These were generated by Liberation for a mission we had those 4 CBU-105 misses in, so I used them for my testing. I don't believe the bug is restricted to these particular wind values. TEST 1 T 34C 30.34 QNH 0900 5 kts at 33 ft, 159 deg 10 kts @ 1600 ft @ 159 29 kts @ 6600 ft @ 139 37 kts @ 26000 ft @ 171 39 Turbulence TEST 2 (all same except for following) 0 kts at 33 ft, 159 deg 0 kts @ 1600 ft @ 159 0 kts @ 6600 ft @ 139 0 kts @ 26000 ft @ 171 0 Turbulence CLOSING Please let me know if there's other information that would be helpful. CBU105_JSOW_TestZeroWinds_010624.trk CBU105_JSOW_TestNormalWinds_010624.trk Nevada Hot Start_2007_JSOWTesting_NoMods.miz Nevada Hot Start_2007_JSOWTesting_NoMods_NoWind.miz

Dangerzone - that's great. Thanks for that approach. Much easier than backing out all the mods and trying to ensure a clean installation. Will definitely use for the future. I'm about to submit the bug report on this one.

Cool thanks Ah, I've heard of OVGME but never used it. I'll check it out. I've avoided any mods that affect the core DCS game directories, since I didn't want to be going through there trying to extract out files when deinstalling. OVGME is probably the better way to go.

Cool, thanks for the quick reply. I reviewed the DCS.log (which I think is the file you're referring to) and don't see any other mods being loaded besides TacView. I've run the Repair, so should be all good there. Do you know if ED requires us to remove TacView as well before submitting any bugs?

I think I have a significant bug to report with the CBU-105 and JSOW when released from the F-16. I know that ED would like us to have all mods removed to ensure it's a problem with the vanilla game and not a mod conflict. I think i've removed all mods and still can reproduce the problem, but is there any log file I can check to ensure I haven't missed anything? Right now, I've cleared everything from my my base game Mods folder, leaving only Tacview. Thanks!

As other have said, this isn't a limitation of DCS, it's a limitation of the real-world Viper. Unlike something like the F-4, F-5 or F-15, where there were stability systems to enhance flight, the F-16 is so unstable that without the active assistance of the FLCS, you'd swap ends with any maneuver. So no, unfortunately, there isn't any way to turn it off. If you're looking for a rougher and more visceral feel, I recommend the F-14 Tomcat.

Makes sense. Thanks!