Moezilla

Then you may have to investigate if your individual CPU needs to have less load pushed through it due to degradation; by changing the advanced power delivery settings.

I did a quick general search online and the consensus seems to be that nvgpucomp64.dll crashes on 13/14 gen Intel CPUs is related to the overvolting/degradation issue. You state your BIOS is up to date but you may need to "load defaults" and reboot if you didn't already (after first backing up/taking note of any custom settings you have). If that still doesn't solve the crashes, you may need to tinker with (i.e lower) the individual CPU voltage delivery settings like PL1/PL2 and ICCMAX.

@Laxxor are you still seeing this issue with bouncing cargo?

I guess it needs a comment from ED about whether there is a reported general issue with sling-loading on the dedicated server. I assume it's something that was tested in a multiplayer environment initially but maybe some subsequent updates have caused this issue. There's also the collision mesh for the map to be accounted for as well, which could be a 3rd party responsibility for maps like Syria, Germany or Kola. @BIGNEWY are you aware of an issue with sling-loads on the dedicated server acting erratically when dropped off, even when running a Caucasus mission?

In the past it has been a multiplayer-specific issue (and possibly dedicated server only, versus self-host MP). It could be related to how forces on the load/cable are interpolated across packets which would become more critical during the final stage of a descent.

Just going from the crash and the log I would suggest disabling the following: secondary shadows, SSS (screen space shadows, iirc?), SSAO, and SSLR; which all show as "ON" in your log, and the crash directly refers to "secondaryshadowmaps". It wouldn't hurt to reduce shadows to medium as well, which would also reduce VRAM and CPU load a little.

My point above about the texture format the DDS container can handle is incorrect. DDS can handle textures with more than 8bpp (and in theory any height x width, but because of mip-maps and potential rendering optimizations, textures are still usually made with dimensions which are a power of 2). I think the overall point stands, which is that DCS is flagging certain textures as not meeting requirements for conversion - but maybe there are changes going on under the hood to how textures are handled that will mean that these messages are redundant. We'll see after the next patch I guess.

2025-08-07 13:21:12.906 WARNING BACKENDCOMMON (5424 Need to reprocess [DDS] image '/textures/door_Diffuse_RoughMet.dds'. Reason: Conversion requires - expanded pixel size, setting if you're talking specifically about this ^^ message, it's likely because DDS format specifies textures with 8bpp and dimensions that are ^2 (a power of 2) so think 1024x1024, 2048x2048, etc. Maybe some texture(s) got cropped to an odd-numbered size; or was saved with the incorrect pixel setting (like 8.8.8.8) and DCS is complaining that it has to run a conversion on it (if it is even able, which will eat CPU time and a small amount of RAM) As for mods, the core of ED DCS gets updated all the time and official 3rd party module makers have to keep their modules regularly updated to maintain compatibility. Is every unofficial mod maker doing the same? Finally, for stutters and performance issues, a fresh dcs.log and dxdiag.txt are the best tools to start finding the reasons for this behavior.

Looking at the DCS log, the DCS crash, and the Windows Error Reports in the dxdiag in the zip I would suggest the following: add a 32768MB min/max sized pagefile to your fastest SSD and make sure it is the only pagefile on the system and the drive still has at least 10% free space after creating it. uninstall ArmoryCrate, or whatever the Asus bloatware is called. check the Asus website for an updated BIOS for your mainboard (important for RAM compatibility, CPU microcode updates, etc) install the latest Intel chipset drivers disable core parking in Windows by following the tutorial here: https://www.dannymoran.com/windows-cpu-core-parking/ disable HAGS, Game Mode, and Core Isolation in Windows, if available consider updating to Windows 11 24H2 (optional) If after all of that, there is still a crash, send the log here and we can look at disabling XMP, and some other stuff.

This is a known crash which has been reported to dev team here: Your log also says that you have core parking enabled which can lead to stuttters/microfreezes, or even crashes in certain situations. Here is a link with information and a tutorial to disable this setting in Windows 11. https://www.dannymoran.com/windows-cpu-core-parking/

Everything looks ok there. Another Intel hybrid CPU with this issue. Did you disable HAGS, Game Mode and Core Isolation in Windows? BIOS updated?

Your OP was about a CTD, are you still getting a crash on v2.9.18.12899? If yes, please send the log from the session with the crash. For your latest post, you are now having trouble with freezes/stuttering? Please share a new dcs.log.

Wow, everything looks tight. I'll think on it, and try to come up with something else to check because something has to be causing this weird bottleneck.

Everything there looks as expected for HT off. Do you have anything influencing the CPU affinity of the DCS process, like Process Lasso, or an affinity bitmask? If that checks out then the next step, if you even want to take one at this point, would be to look at RAM settings, SSD speeds, and a BIOS update. If you are interested in getting it fixed, CPU-Z, and CrystalDiskInfo are good utils to get a read on your Mainboard+RAM, and storage setup, respectively. For context, my 5800X3D, on an ancient B450 mainboard with only 32GB RAM, took 36 seconds to load after the .12899 hotfix, as it rebuilt the shaders in the fxo folder. The 2nd load of .12899 took 20 seconds.

@Sezai @Akula @Mainstay off the top of my head, and looking at your specs in your sigs, I'd guess you have a combination of maybe 2 out of 3 of the following: core parking, real-time AV scanning, and new shader compilation after an update. Can you open Explorer -> Saved Games -> DCS -> Logs -> Right-click the file named dcs and open/edit in notepad -> copy and paste the first 20-25 lines down to and including the line starting with unavailable cores: and post them here? This will help to understand if you're facing core parking or core scheduling issues in your OS. You could do a quick search online for how to add an exclusion to Windows Defender and then consider adding the DCS main install folder and Saved Games\DCS folder to the list of exclusions from real-time scanning, if you haven't done so already. For the shader compilation; that should be a one-time event on the first launch after a new update, or if you ever manually delete the contents of the fxo and/or metashader2 folders in Saved Games\DCS.