GeoS72

This new file should also have the DXDiag info. I'd also like to point out that I used the standard executable file from the /bin folder (not the bin-mt). As a consequence, no reShade was used either.

Here's another log set. DCS crashed to desktop within moments of running the mission editor, maybe 5 minutes. Luckily, no wildly outrageous RAM outages occurred. I suspect some memory leakage because it thought awfully hard before the CTD. dcs.log-20251130-224635.zip

Attached is my DxDiag log file. I don't think it would show a smoking gun because I just ran it. So it captures the current snapshot and not during the system failure. The only thing I use reShade for is to brighten the area where MFD displays are exported to physical monitors. I don't normally see those texture reprocessing. I believe that is a symptom of this game-crashing bug. I suspect the problem is in that file or resource called ed_malloc. The NordLynx Tunnel was my NordPass resource which was running on my browser. What else do you see? DxDiag.txt

I also pulled the event logs from Win 11 around the time of the hard crash. Again, I don't know what I'm looking at. However, you can clearly tell that DCS consumed ALL the System RAM and caused a cascade of failures. In the brief moment of my primary display still being visible, I snapped this image which shows an error message. I need to research what that exe file is. Win11 Event Viewer-Crash Logs 4 DCS.rar

Alright, DCS crashed hard again tonight! I was exclusively in the Mission Editor (ME). I was focused on adding Dynamic Spawn templates again. It took about 2.5hrs but the game crashed to desktop again and caused my displays (multi-monitor setup) to flicker. My graphics driver crashed and attempted to recover. The primary display went blank and I had to force shut down the PC to ultimately recover from this crash. There were some stuttering during my 2.5hrs of editing but nothing that really caused my system to severely bog down. However, the big hit came after I added the C-130J to the map and enabled Dynamic Spawn template. It didn't take too long before the PC started to bog down. I was able to move/modify some assets to Dynamic templates before the PC crashed. I did not look for or change any ground assets with ammo set to 0. Here are some logs that you can evaluate. You are going to see a truck-load of ERROR and WARNING messages. dcs.log-20251130-013327.zip dcs.log I ran the standard DCS log in ED's Log analyzer. It spit this Error report out: Your System ran out of Memory Increase RAM or !pagefile. Hot plug Events Disable hot plug in your CONTROLS section. Yeah...the system ran out of memory because DCS is tripping balls! I will not take that advice - 96GB is PLENTY of System RAM.

@sleighzy, thanks for the heads-up. How did you learn of this fix? Does that mean another hotfix is coming down the pike?

@sleighzy, I am a little gun-shy when playing in the Mission Editor today. I was focused on my DCS server. There are certain MIZ files that cause the server to crash - and crash hard! That was traced to code in the dcs server file. Frankly, that's above my paygrade. As I may understand it, there is a massive memory address/recall issue that is causing the crash. Several servers are experiencing the same thing. Again, that's above my paygrade and comprehension level. Bottom line on server/webGUI interface: I had to find a MIZ file that would work and not crash my server. I ran a warbirds map without any mods. Note, my personal mods were still active, the server didn't use any. Then I ran a MIZ file in Syria that was working "pre-update". That Syria MIZ file worked. That MIZ file uses mods (A-4E, F-22, F-23, OV-10) but the "Required Modules" restriction was removed. I then loaded a Syria MIZ file that I made "post-update". This has dynamic slots for the C-130. It too ran on my server without crashing! This "post-update" map also uses mods with the restriction lifted. I was able to join the server and some of my members were also able to join the server. There could be some correlation to the Persian Gulf map. Both pre- and post-update PG MIZ files are VERY problematic. They constantly crash the server. I need to test out ME performance over this weekend. However, I have car repairs that override pretty much anything else planned for this weekend. Lastly, I'll have to check on the 0 ammo counter for ground vehicles. I have quite a few ground and air units with 0 ammo in the PG map. These are supposed to be treated as drones so clients can practice their attack profiles & targeting workflow. Basically, I zero out their ammo as a "physical" limitation to NOT fire in a training environment. That's in addition to using the "weapons hold" advanced waypoint setting. Because you can't trust AI logic! But that's a topic for another time.

I don't think we're out of the woods just yet. Differential braking has improved. However, there are still challenges when trying to turn on the deck. I completely agree with @AG-51_Razor! There is still more work that needs to be done. I'm not referring to the tail wheel animation. The tail wheel caster effect is better but still needs more work. It should be on par with the P-47 & P-51 modules. I'd also like to confirm: It's easier to make a right turn but left turns still require work. I only tested its ability in the Taxi & Takeoff training mission. Not sure what the wind settings are in that mission.

There is a HUGE problem with memory leaks or invalid memory allocations (basically this problem is memory related). Single player seems to work fine. But the moment I attempt to load into my multi-player server or when I attempt to do some mission editing, the game crashes to desktop. This is HIGHLY annoying and VERY FRUSTRATING! I just want this effin game to run without error. Such a request is apparently too much to ask for these days. All of the shenanigans between patch versions .90 and .92 should not happen. My advice to ED: SLOW down! It appears there are too many people trying to push for a deadline and the product is NOT ready. "Small" mistakes like the different patch versions is a sign of being rushed. That's no small mistake. That's a BIG deal! I too was affected by that patch mismatch. My server is broken for reasons unknown to either myself or my server provider. The key indicator is the memory hog. Here's another crash log report. This was the result of attempting to join my server running a MIZ file set in the Persian Gulf. This MIZ was edited pre-update. Yet, when I try to join the server, I get a crash to desktop after Net Sim Post Start. Again, I want to point out this problem is memory related. For the ED Moderators, evaluate this data and search for clues that impact memory allocation. You can spare me the speech about removing mods. That will NOT happen unless there is overwhelming evidence a mod is causing the issue. If the game was working pre-update and now crashes galore post-update, then there is an issue with the UPDATE, not anything else. dcs.log-20251128-232505.zip

sleighzy, I appreciate you taking a look. While most of these happened while using multi-thread, my last one was using the standard exe from the Bin folder. Additionally, all of this occurred while in the Mission Editor and NOT during game play. I believe ray tracing is off for the C-130 (Special Settings). I use Reshade in the multi-thread exe and NO Reshade in the standard exe. I experienced this crash between MT and ST applications. All video card drivers are current - 14 Nov is the latest. I suspect that "device removed" error was captured when windows tried to reload the display driver after the crash. Regarding Mods: It is exceptionally rare that mods cause a crash. It is even more rate that they cause a crash while in the ME. I would like to point out that a few updates ago, people complained of memory leaks that caused game crashes. Maybe this is another occurrence of that memory leak? Let's not forget: ED had to post a hotfix immediately after the 27 Nov update. People couldn't log in. Could this all be related? Thanks for reminding me about clearing metashaders2 and fxo folders. I did not do that prior to starting up DCS. One thing is for sure: with 96GB of RAM, I shouldn't be running out of RAM while Mission Editing! One final note: I do not overclock my video card, RAM, or CPU. It's all set to Auto.

While in the Mission Editor, I experienced 3 hard crashes to desktop. One crash completely locked up my PC. I had to force power off because of the lack of response. I suspect there is a corelation to the latest update, DCS 2.9.22.17790 after downloading the C-130J Module. I was creating Dynamic Templates in the South Atlantic Map when these crashes occurred. While dragging a unit, I would hear my fans kick into higher gear and see a tremendous amount of hard drive activity. There was lag while moving assets around. Just moving the mouse without dragging an asset would cause lag and massive stuttering. My monitor and RGB keyboard would flash and I would see a black screen. I couldn't Alt-Tab. DCS just locked the eff up! This also happened while editing my Syria map. I thought it was a fluke then, but after experienced the same failure on 4 occasions, then THAT'S a PROBLEM! See attached DCS logs. dcs.log-20251128-031049.zip dcs.log-20251128-032203.zip dcs.20251128-041543.crash dcs.20251128-041543.dmp dcs.log dcs.log.old

Where is that file located? Is it in the folder I mentioned above? If it's there then edit the file. Take a look at Line 2. It should read something like this: name = _('Name_of_LUA_File'); Change that line to read whatever you like, e.g. name = _('Custom 3-Monitor'); I normally make the name (line 2) entry match the file name for ease of reference. Be sure to create a backup afterwards! When you open the graphics setting from the loading screen or go into the Main Menu Settings, you should then be able to select the name you just created. This is also a good time to verify your center viewport has the right settings. On lines 6 through 14, you should see something like this: Center = { x = 0; y = 0; width = 2560; height = 1440; viewDx = 0; viewDy = 0; aspect = 2560 / 1440; You may need to change the width, height, and aspect values to match your monitor configuration. For example: width = 11520 height = 2160 aspect = 11520 / 2160;

I'm not sure this matters much, but do you use software settings through NVDIA to stitch those 3 monitors together? Did you also create a custom monitor lua file in the "main" DCS World\Config\MonitorSetup folder (not in the Saved Games folder)?

Are you a Rebel Without a Group? Join the ranks of Virtual Expeditionary-Joint Squadron Two Twenty-Five (VXJ-225), Renegades. We take our missions seriously, but we never take ourselves too seriously. If you're not enjoying the flight, then you're doing it wrong. The Renegades have plenty of seats in the Ready Room for fast-mover junkies or whirlybird enthusiasts. We mostly fly Western jet aircraft—from the Teen series fighters to helicopters like the AH-64 Apache, CH-47, OH-58, and UH-1 Huey, plus Warbirds like the P-51, P-47, and more. We also fly community aircraft mods like the A-4E, F-22A, F-23A, OV-10A, and UH-60L. Here's the skinny: Mission Focus: PvE. We feature well-established base capture maps that are filled with side quests. Helo pilots can fly the revered Moscow Mule (with voice actors) or the aptly named SGLI Run, both set in the Persian Gulf map. Play style: Casual with a mil-sim foundation. Flexibility is the name of our game. Community: Friendly and laid-back. If you're looking for a squadron where the fun never ends and the rules sometimes bend, then welcome to your new home! Closed-mission schedule: Thursdays, 8pm (2000) EDT/EST. Minimum map/tech requirements: Persian Gulf, Syria, Supercarrier. Recommended: South Atlantic, Sinai, Iraq, and Afghanistan maps, WW2 Assets Pack. Special skill sets needed: Mission designers, livery artists, and MOOSE coders to help bring our missions and aircraft skins to life. Special Note to ALL Veterans: If you served in the skies, on the ground, or at sea, then come join our squadron. Your experience and sense of humor will be a good fit. What's your favorite aircraft to fly? Its uniqueness will be added to the Renegade collective. Resistance is futile; fun is relevant. Demonstrate your talent. Join our Discord: VXJ-225 Renegades

I did a bunch of stuff back in March & April. The problem was on their end, not mine. The problem eventually resolved itself without much fanfare or even them contacting me to verify the problem was fixed. Their customer service reps said the "fix" would take several months. And they weren't kidding. I can now use my VPN while playing DCS. It took about 5-6 months to fix but it works now.

@-Rudel-, et al, My 'tism is kicking in when reading the problem with Differential BRAKING. I'm sure we all know the definition of brake however, there are some posts (including the M3 list of bugs) that conflate the spelling of it. Brake/braking/braked = application of a force to slow down an object. For example: My foot applies pressure on the car's BRAKE pedal to reduce vehicle speed. Break/breaking/broke = to separate an object into many pieces or to damage an object. For example: A car's camshaft can BREAK just by dropping it on the floor. Another example: A car's hydraulic rubber BRAKE line can BREAK when it is very old and too much pressure is applied. Again, I'm sure we are all thinking of the same thing. However, reading it causes all sorts of trouble in my head. And one could easily say: I'm taking a break from flying the Corsair because of its Differential Braking problem.

Gents, to be fair: please refer back to the post Rudel made about Acknowledging Bugs/Request List. This problem is cited on their Bug List and he did acknowledge it is a problem. He also stated that this would be addressed after they sorted the engine management problem. With that being said, it's been approx 2 months since the engine management issues were addressed. I've rarely seen a dev be pro-active with updated bug reports. For the most part, they (not just M3) follow a long period of silence until they are ready to release "good" news. If a dev provides some form of update then they believe it forms a deadline and they are held accountable for it. So they keep quiet and let the users stew in their proverbial juices. Am I happy about this silent treatment? NOPE! Does my level of frustration increase when there no updates after each patch? YUP! Does the level of frustration continue to grow when there's no mention in the forum (this thread)? A resounding YES! After reviewing M3's bug report, I can honestly say, this problem is the most commented. One would assume this issue has greater visibility, which would equate to a higher priority to resolve. All I can say is: I've recommended to my fellow squadron mates to avoid this module until key issues are fixed. Like the differential braking/feathering into the wind, and the damage model (potential tail wheel damage) at spawn-in. I refuse to fly this module until these issues are addressed. No training missions, no Corsair School (campaign), not even air starts! I'm pretty upset because being an early adopter, I expect the plane to perform adequately. I know that several of my squadron mates are disappointed but they were shocked to hear my say, "Don't waste your money now. Wait until it's fixed."

Wow! Thanks for the update, @BIGNEWY! I thought this discrepancy fell off the radar. Good to see it is being addressed.

Are there plans to organize all of the untitled/un-named helicopter bases that are marked as "H"? It's very challenging to sort/list/find all of these H airbases, especially when applying dynamic warehouse features.

@shadowborn, The problem is complicated to say the least. I've been reporting issues with GeorgeAI for a while. Despite my best efforts to provide the requisite information it never seems be be "enough". The problems with GeorgeAI really start to manifest after flying for a while. I'd say after 30min of flying. That defeats the purpose of providing a short track file for review. I'm not sure if this may help you but after all the recent updates to GeorgeAI, I follow these steps: 1. Maintain a loadout of 1-Kilo and 3-Lima Hellfire per rack. 2. Keep him de-WAS'ed until within range. 3. GeorgeAI can lase to obtain range data while de-WAS'ed (short right). 4. Once in-range, switch GeorgeAI to RF MSL or SAL MSL (short left, then long left to cycle between MSL types). 5. He should activate the laser for range data (so the data can be automatically transferred to the Hellfire) 6. If he has a hard time lasing the target, switch between RF MSL and SAL MSL. This is why I keep at least 1 Kilo Hellfire per rack. 7. You should be no closer than 1,100 meters to fire the MSL. Otherwise, GeorgeAI will not comply after consent is given. 8. Frequently have George AI de-WAS'ed when you are not actively shooting at a target. My rule of thumb is de WAS him after 1 minute from the last target hit. Note: I've had many times where I had to cycle GeorgeAI 3+ times to get compliance and fire a missile. I also had to slow down my button movements to be more deliberate. This can be very challenging especially when you get caught up in some intense battle sequences. GeorgeAI is still far from perfect. As you noted after crashing, I too get the repeating "Aircraft armed" callout. That is normally caused when the helo is wobbling/tilted/fallen on its side, or there is damage to the weight on wheel switch (however the game calculates that logic). Lately, I will see and hear GeorgeAI stuck in a target lasing loop. I'll hear him call out "lasing" to infinity and also see a notification window that says "lasing" scroll down the right side of my screen to infinity. I have to undesignate the target and reacquire it for the problem to go away. I know this may sound silly to ask: Have you verified there are no keybinding conflicts when you experience GeorgeAI safing the helo? @BIGNEWY, I ask for consideration to short track file requirement. Based on my experience in multiplayer environments, which is were many of us experience these bugs, it takes at least 30 minutes of flight time to encounter an issue with GeorgeAI. Furthermore, it is a huge PITA to stop my entertainment and exit the server just so I can immediately preserve my DCS log and multiplayer track file. Then get criticism for it being too long/large and not be reviewed; or suggest to provide more data. Trust me when I say that I have better things to do than to complain about a DCS module (or modules). If I'm complaining about a problem, then I'm pretty fed up about it. You are welcome to come into my server and experience the issues hurting my head. You may collect all the data you wish at that point.

Here is a link to download the track file for this livery bug. I'd like to repeat this is more of a Mission Editor problem. The track file will only show the effect of the problem, where as ME screenshots point to the cause. PG Map Livery Issue Track File

Here are 2 screenshots that has 1 minor livery discrepancy and 1 major discrepancy. The Apache rearm screen shows "Item 1" in the drop-down menu for liveries. It should read "Apache Desert". I also confirmed the livery ID from the MIZ file. The Tomcat livery should be the "default", 01 - VF-102 Diamondbacks 1996 livery. Instead, I get the VF-103 Jolly Rogers. Now, this is where the problem gets strange. In the MIZ file, the livery id shows up as VF-103 Last Ride. However, in the Mission Editor, the livery should be 01 - VF-102 Diamondbacks 1996. The livery IDs are messed up bigger than a soup sandwich. Here is the Item 1 choice on the rearm menu. Here is the VF-103 livery, when it should be VF-102 livery.

Here is the DCS Log, the track file is too large to attach right now. There was a bug when I opened the rearm menu in the Apache. It showed the F/A-18 livery in the pull-down list. I wasn't able to recreate my initial discrepancy because the base from which this was observed was not captured yet. However, refer to the screenshots from the Mission Editor. That is more of the tell than any track file or log could show. dcs - PG Livery Issue.log

These edited screenshots show the radio frequencies of my template aircraft depicted in the track file.

Here is my track & log file to document the radio freq not matching the Dynamic Spawn template. DCS Log-Track Files.zip