STONE SKY

Hello! I did not block the radio menu, there is no such function in the editor. In the campaign there is no need to use the radio menu, since the radio communication is completely recreated by triggers. You just need to set the desired frequency to hear the controller's dialogue with you. In mission 7 - TOP SECRET. You take off and land on a FARP, which is not a FARP programmatically. In other words, there is no ATC DCS. But this does not affect the radio menu button.

I decided to continue and sent my Log for comparison. I have i9-12900K 3.20 GHz Comparison of the Two DCS Log Files I've analyzed the provided log file (dcs.log from August 25, 2025) and compared it to your previous log (dcs.20250821-202548.log from August 21, 2025). The comparison focuses on key differences in system configuration, warnings, execution flow, and outcomes. This helps explain why the previous setup experienced crashes while the new one appears stable. I'll structure this as a table for clarity, followed by an explanation. Aspect Previous Log (Aug 21, i9-12900KF) New Log STONE SKY (Aug 25, i9-12900K) Implications Installation Path & Version D:\DCS World\bin\DCS.exe (Stable, MT version 2.9.19.13478) G:\DCS World OpenBeta\bin-mt\DCS.exe (OpenBeta, MT version 2.9.19.13478) Minor difference; OpenBeta may have slight patches, but same build number. No impact on crashes. Windows Build NT 10.0.26100 (Possibly Insider/preview build) NT 10.0.19045 (Stable release build) Preview builds can introduce instabilities; stable build is less prone to OS-level issues. CPU Model & Config Intel i9-12900KF: 16 cores, 24 threads (hybrid: 8 P-cores/16 threads + 8 E-cores/8 threads). Efficiency classes: Mixed (class 1: cores 0-15; class 0: 16-23). Performance classes: Varied (class 3: 12-15; class 2: 0-11; class 1: 16-19; class 0: 20-23). Affinity: All cores used, IO on E-cores (16-23). Intel i9-12900K: 8 cores, 16 threads (appears to be only P-cores active). Efficiency classes: Uniform (all class 0). Performance classes: Varied but simplified (class 1: 8-11; class 0: 0-7,12-15). Affinity: Common cores {4-7,12-15}; Render on {8-11,0-3}; No IO cores listed, no unavailable cores. Key difference: E-cores seem disabled in BIOS on the new setup (reducing to 8 cores/16 threads). This eliminates hybrid CPU issues. Hybrid setups often cause DCS instability in multi-threaded (MT) mode. RAM 32 GB (32556 MB) 64 GB (65303 MB) More RAM in new setup reduces memory pressure, but unlikely the primary crash cause. CPU Warnings Explicit warning: "CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores)". No such warning. Core parking (Windows power-saving feature) on hybrid CPUs leads to desyncs and crashes in DCS MT, especially in CPU-intensive modules like AH-64D. Disabling E-cores prevents this by avoiding mixed core types. Scripting Errors Present (e.g., "No preset named 'MDRN_B_A_PGM_HTP'" in HeavyMetalCore for B-52H/B-1B). Identical errors present. These are benign vanilla DCS issues; not causing crashes. Mods & Plugins Loads mods like Currenthill Assets Pack (replaces units); same plugins start/end. Identical mod loading (e.g., Currenthill Assets Pack). No difference; mods aren't the culprit. Audio Devices 4 devices (Headphones, Speakers, Digital Output, Monitor). 4 devices (Digital Output, Monitor, Oculus Virtual Audio, HD Audio 2nd output). Slight variation, but no errors in either; irrelevant to crashes. Execution Flow Loads modules, but crashes during simulation (ACCESS_VIOLATION in AH64D.dll during ExternalFM sensor/timing calls). Ends with crash dump. Loads modules, initializes Syria terrain, handles object position errors (non-fatal), then normal shutdown. No crash; log closes cleanly. Previous crash tied to AH-64D FM/sensors under hybrid CPU load. New log shows stable run, likely due to uniform cores. Timing & Outcome Starts ~17:56 UTC, crashes ~20:25 (long session?). CTD to desktop. Starts 14:21 UTC, normal exit ~14:31 (short test?). Successful shutdown. New setup avoids the violation, confirming hardware config fix. Explanation and Insights Root Cause Resolution: The previous crash was an ACCESS_VIOLATION in the AH-64D module, triggered by core parking on a hybrid Intel 12th-gen CPU (P-cores for performance, E-cores for efficiency). DCS MT is sensitive to this, as it assigns tasks (e.g., IO to E-cores), leading to memory access issues during high-load operations like flight model (ExternalFM) or sensor processing. In the new log, E-cores are disabled (evident from reduced core/thread count and uniform efficiency class), eliminating the parking warning and crash. This is a common fix for DCS on 12th/13th-gen Intel CPUs, as hybrid architectures can cause stuttering or CTDs in VR/multi-threaded scenarios. Why It Works Now: With only P-cores active, DCS runs on consistent high-performance threads, avoiding desyncs. The increased RAM and stable Windows build may help marginally, but the CPU change is the key. Recommendations: If this is the "other comp" without crashes, replicate the setup on the first PC by disabling E-cores in BIOS (under CPU settings, set E-core count to 0). Alternatively, use tools like Process Lasso to force affinity to P-cores only. Test in a mission with AH-64D to confirm. If mods like Currenthill are still suspect, remove them temporarily. It's still not certain, sir! I hope you will continue your investigation and find the cause. We should probably wait for the new distribution of tasks for cores in the AH-64D mod. I don't remember exactly, but I did some kind of processor setup in the BIOS after assembling the PC. Probably this issue also requires study, judging by the comparison table of our processors

This was difficult for me, I used the Grock AI, if you don't mind. We seem to have a direction where to look for the problem. But I'm not sure. This is the AI's analysis, not mine. Type of Error: ACCESS_VIOLATION (code C0000005). This indicates an attempt to access memory that is either non-existent or protected (e.g., null pointer dereference or data corruption). Crash Location: In the module AH64D.dll (D:\DCS World\Mods\aircraft\AH-64D\bin\AH64D.dll), which is responsible for the AH-64D Apache module. The stack trace shows calls from ExternalFM (external flight model) for AH-64D: ExternalFM::AH64::AH64FM::setImmortal + 0x10EC5 ExternalFM::AH64::AH64FM::getSensorsSystem + 0x29115 ExternalFM::AH64::AH64FM::setImmortal + 0x15D97 Followed by transitions to CockpitBase and World (DCS simulation core). Context: The crash occurred during simulation or loading, likely when DCS was processing cockpit device timers (cockpit::avDevice_BasicTimer::NextEvent) or the event calendar (wSimCalendar::DoActionsUntil). This happened shortly after launch (log starts at 17:56:29 UTC, crash at 20:25:48, though this could be local time; actual launch ~17:56). DCS Version: 2.9.19.13478 (MT - multi-threaded version). This is a relatively recent build (build 376), possibly beta or open beta as of 2025-08-21. System: Windows 10 (NT 10.0.26100), Intel i9-12900KF CPU (16 cores, 24 threads, hybrid with P-cores and E-cores), 32 GB RAM, NVIDIA GPU (based on loaded DLLs like nvwgf2umx.dll). 2. Key Findings from the Log CPU Warning: The most notable line is 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). This directly points to an issue with core parking—a Windows mechanism that "puts to sleep" inactive cores to save power. On a hybrid CPU (like your i9-12900KF with Performance-cores and Efficiency-cores), this causes instability in multi-threaded applications like DCS. Similar crashes are described in threads such as "DCS World - Force CPU Core Parking" (DCS Forum, 2025) and "DCS 2.9 stuttering with 12/13 gen Intel CPU" (Reddit, 2023). Many users with 12th+ gen Intel CPUs report CTD (crash to desktop) issues with AH-64D due to this. Your log shows the CPU affinity mask using all cores, but with different efficiency classes (P-cores: 0-15, E-cores: 16-23), and DCS assigns IO tasks to E-cores (16-23). This is not a bug in the AH-64D itself but a system incompatibility exacerbated by the module (AH-64D demands significant CPU resources for its flight model and sensors). I hope this helps. Naturally, this should be double-checked.

Got it! In the Saved Games - DCS - Log folder you need to find the file - dcs.log. open it and check the date and time in the first line My example - === Log opened UTC 2025-08-25 04:40:37 After that send it to me here. I will check what could be the problem. In this file we can see what caused the crash.

Thanks for the advice Tom, and thanks for the feedback! Will test and fix. A-10C should have definitely destroyed most of the targets.

Stay high and try to catch the SAM range limit. It's about 8 miles. Clearly pinpoint the location of the HQ-7B TELAR. Spoiler - during visual reconnaissance you should see that the HQ-7 battery consists of 2 radars, and only one launcher. The best target is the HQ-7B TELAR. Its SAM range is 8 miles. You need to get higher, and at the 8 mile limit throw Hellfire at the targets. The second option is to fly at an altitude of 5 feet above the water. Get to the firing range of the GUN.

Yes. I'm preparing a big campaign update, including this one. Sorry for the delay

Thanks for the info!

Thanks for your observations. I hope ED sees this! Unfortunately I can't influence this.

Thanks for the feedback, Tom! We'll edit it!

Интересная идея, спасибо! Я об этом не подумал!

Yeah, I need to learn to trust the AI a little more. Thanks for your feedback!

Accepted! Thanks for your feedback sir! Will test and fix.