Moezilla

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.