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.

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

[Player1] C:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff9e32321db 00:00000000 ... 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player2] C:\Program Files\Eagle Dynamics\DCS World\bin-mt\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff8d83b21db 00:00000000 ... 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE =================================================================================================== [Player1] C:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ff91d215522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player2] C:\Program Files\Eagle Dynamics\DCS World\bin-mt\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ffd4ade5522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE [Player3] E:\DCS World\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ff9760e5522 00:00000000 ... 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE Update: I have collected crash details for 3 different players who are experiencing the Effects.dll (2 out of 3 players) and edCore.dll crashes (all 3 players). The crash traces appear to have the same signature for all players. Below are the specs of the players and the settings from the graphics config reported in their logs that are shared across all three players. Hopefully the team have had enough reports through the crash report tool to have begun to find the source of these crashes. Specs: [Player1] AMD Ryzen 7 9800X3D Nvidia 3080 (572.83) 64GB RAM Windows 11 [Player2] AMD Ryzen 7 5700X Nvidia 3070 (576.40) 64GB RAM Windows 11 [Player3] AMD Ryzen 5 7600 Nvidia 3060 (576.28) 32GB RAM Windows 10 Graphics settings in common across all three players: { ['lights'] = 2; ['canopyReflections'] = 1; ['useDeferredShading'] = 1; ['textures'] = 2; ['cockpitGI'] = 1; ['terrainTextures'] = 'max'; ['shadows'] = 4; ['sceneryDetailsFactor'] = 1; ['effects'] = 3; };

Issue still persists with OP's test mission in DCS 2.9.17.11733. Has there been any progress on the investigation into this issue?

Hi @BIGNEWY, Could you check if the database that is fed by the DCS crash reporting tool has picked up these two crashes since the 2.9.17.117333 (Corsair+Essex+MarianasWW2) update? If it has, is there progress on finding a cause and fix? # -------------- 20250623-053429 -------------- DCS/2.9.17.11733 (x86_64; MT; Windows NT 10.0.26100) C:\Program Files\Eagle Dynamics\DCS World\bin\Effects.dll # C0000005 ACCESS_VIOLATION at 00007ff8d83b21db 00:00000000 SymInit: Symbol-SearchPath: 'C:\Program Files\Eagle Dynamics\DCS World\bin;', symOptions: 532, UserName: 'user' OS-Version: 10.0.26100 () 0x100-0x1 0x00000000000421db (Effects): Effects::ODCSParticleSystem2Proxy::updateGraphicReflection + 0x33B 0x000000000003dfb2 (Effects): Effects::loadShipWakeConfig + 0x24C2 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE 0x0000000000168fbf (Visualizer): smSceneManager::DestroySceneManager + 0x1136F 0x000000000016f79b (Visualizer): smSceneManager::regLua + 0x5DDB 0x000000000015444c (Visualizer): smCamera_Implement::getClipRegion + 0x1C17C 0x000000000013e4cc (Visualizer): smCamera_Implement::getClipRegion + 0x61FC 0x0000000000158ce2 (Visualizer): smSceneManager::DestroySceneManager + 0x1092 0x00000000000337b1 (edCore): ed::thread::_get_current_thread_id + 0x71 0x00000000000037b0 (ucrtbase): wcsrchr + 0x150 0x000000000002e8d7 (KERNEL32): BaseThreadInitThunk + 0x17 # -------------- 20250622-022701 -------------- DCS/2.9.17.11733 (x86_64; MT; Windows NT 10.0.26100) C:\Program Files\Eagle Dynamics\DCS World\bin\edCore.dll # C0000005 ACCESS_VIOLATION at 00007ffd4ade5522 00:00000000 SymInit: Symbol-SearchPath: 'C:\Program Files\Eagle Dynamics\DCS World\bin;', symOptions: 532, UserName: 'user' OS-Version: 10.0.26100 () 0x100-0x1 0x0000000000025522 (edCore): b2DynamicTree::RemoveLeaf + 0xC2 0x0000000000024ea9 (edCore): b2DynamicTree::MoveProxy + 0xC9 0x000000000003deda (Effects): Effects::loadShipWakeConfig + 0x23EA 0x000000000003e7de (Effects): Effects::loadShipWakeConfig + 0x2CEE 0x0000000000168fbf (Visualizer): smSceneManager::DestroySceneManager + 0x1136F 0x000000000016f79b (Visualizer): smSceneManager::regLua + 0x5DDB 0x000000000015444c (Visualizer): smCamera_Implement::getClipRegion + 0x1C17C 0x000000000013e4cc (Visualizer): smCamera_Implement::getClipRegion + 0x61FC 0x0000000000158ce2 (Visualizer): smSceneManager::DestroySceneManager + 0x1092 0x00000000000337b1 (edCore): ed::thread::_get_current_thread_id + 0x71 0x00000000000037b0 (ucrtbase): wcsrchr + 0x150 0x000000000002e8d7 (KERNEL32): BaseThreadInitThunk + 0x17

According to the log from June 14, you have parked cores and are running Windows 10. The specs of your CPU indicate 6 P-Cores and 8 E-cores. I would guess that your freezes relate to work being passed to E-cores by the Windows 10 core scheduler, which is known to do this with hybrid CPUs. There are several ways to "unpark" your cores, but I used a free utility called ParkControl to turn off core parking for the power plan in use. If an upgrade to Windows 11 is possible, this will also help with general issues with core scheduling. Good luck.

ED are aware and working on it

@BIGNEWY has the investigation come up with any findings on this issue yet?