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.

Nah, shaji is right, yours looks more like an issue with the Visual C++ Runtime. There was an update to DCS recently that required a reboot, did you do the restart? If yes, then you should probably re-install the latest VCRuntime from Microsoft https://aka.ms/vs/17/release/vc_redist.x64.exe If that doesn't fix it, it could be related to the sqlite3 db that the launcher uses, probably for some localisation strings or something. But one step at a time. Of course just running DCS without the launcher is also an option, I do that.

@shaji I saw this crash (repeated) on a dedicated server running the MarianasWW2 map, reported it, and it hasn't happened again recently. Just speculation, but I think that some updates to the Essex carrier, including specifying it's draft (which was missing), may have been the fix in our case. It's hard to know as it isn't spelled out in the patch notes every time that update x fixes crash y. It might be worth looking at any ships in your mission, their waypoints, and the sea depth in those areas for some sort of clue as to what might be causing the crash. Good luck.

The crash related to HARMs should be fixed and another hotfix patch was released today (12899) that fixes another F-16 crash too. In ParkControl I edited the High Performance Windows power profile and changed the Parking to Off - 100% for Plugged In (AC). If you prefer using another power profile in Windows most of the time for energy saving, then you could just activate the High Perf power profile before you launch DCS.

The crash in the log has been fixed in the latest update 2.9.18.12722 - it is related to using HARMs in the F-16 You have parked cores, there are various methods to unpark them. The free software ParkControl worked well for me.

From a preliminary test with OP's test miz, it looks like Ugra has fixed this issue (possibly the patch note about the collision model hints at the real culprit).

Line 3 of your dcs.log: 2025-07-16 18:28:20.635 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores) The DCS UI elements can trigger either the core-parking or other efficiency features in Windows. It's recommended to disable core parking. There are numerous ways but, personally, I used a free utililty called Parkcontrol and it was a simple, one-time (so far) process.

Your export.lua is busy but I've seen others running similar setups. You could check if the MP servers you play on regularly have server-side tacviews. Some make them available for download.

From your log it's likely to be Tacview dumping a lot of data on busy servers with lots of air and ground activity. Try one of the previously stuttery servers with it disabled from your side. You could check Saved Games\DCS\Scripts\Hooks\ and move/delete anything you don't need (I didn't see a reference to the OH-6 gunner script in the log - it's a known stutter cause in MP - but you did have a script error from vpcDuelSpawnGUI.lua) Also you could open Saved Games\DCS\Scripts\Export.lua in a text editor and make sure that only expected items are in there.

Integrated GPU is being used (Intel UHD 770) - I'm guessing based on a quick search for the Corsair i7300 PC that you should have a 30 series Nvidia card in there. I'd re-install the latest Nvidia drivers and then check in the BIOS that the discrete GPU (dGPU) is the primary display device.

If you check out Quaggles' datamine, the commit for 2.9.17.11733 shows significant increases in mass, expl_mass, and piercing_mass for the Mk81-84 bombs. How exactly these numbers are used by DCS to calculate explosions is not generally known, but it would be a reasonably logical assumption to make that bigger number = bigger boom. Here's an example for the Mk83: [2.9.16.10973] _G["warheads"]["Mk_83"] = { caliber = 356, concrete_factors = { 1, 1, 1 }, concrete_obj_factor = 0, cumulative_factor = 0, cumulative_thickness = 0, default_fuze_delay = 0, expl_mass = 160, mass = 160, obj_factors = { 1, 1 }, other_factors = { 1, 1, 1 }, piercing_mass = 32 } [2.9.17.11733] _G["warheads"]["Mk_83"] = { caliber = 356, concrete_factors = { 1.35, 1.35, 0.135 }, concrete_obj_factor = 1.35, cumulative_factor = 0, cumulative_thickness = 0, expl_mass = 201.9, length = 1.956, mass = 446.8, obj_factors = { 1.35, 1.35 }, other_factors = { 1.35, 1.35, 1.35 }, piercing_mass = 89.36 } The new numbers for 2.9.17.11733 match the stated specs on the wiki page for the Mk83 of 447Kg mass and 202Kg of filling. Sources: https://github.com/Quaggles/dcs-lua-datamine/ https://en.wikipedia.org/wiki/Mark_83_bomb