Could there be a memory-leak ?

[MarcT-NL]

I have never had memory-problems. That is, until the Apache came out. All other airframes work fine, but when I'm in the Apache, most of the time it end with a BSOD. I posted this in the Apache-bugs, and there was a bit of improvement, but it's still walking on eggs with this.

Since the DCS-update of mid-may 2022, the Gazelle now has the same problem !  I get a BSOD after flying it for 15-30 minutes. SP or MP.

So what's going on here ?  32GB should be enough to run DCS I hope ?  Anybody else experiencing this ?

• Intel i7 8700k 3.7
• Asus MAXIMUS X HERO-mb-ATX Intel Z370-chipset, socket 1151
• 32gb DDR4 (4x8gb)
• MSI GForce RTX 2080 Gaming X 8gb
• 500gb SSD for Windows + another 500GB SSD for DCS
• Powersupply 750W (usage is not higher than 500w)
• HP Reverb G2

Edited May 26, 2022 by MarcT-NL

[MarcT-NL]

Oh yes, before y'all suggest it might be my PC. Well sure, that would be best case scenario actually, but why do I still have this problem with ONLY the Apache and Gazelle ?  Are there simularities in their coding ?

I fly hours and hours without any problem:

• FA-18
• P-51
• Ka-50
• F-5
• Mi-8
• Mosquito
• A-10C-2
• Huey

In all maps. Supercarrier, Combined Arms, WW2-assets are installed.

[Ramsay]

2 hours ago, MarcT-NL said:

So what's going on here ?

Please attach your dcs.log the next time DCS crashes and you are flying the Gazelle.

2 hours ago, MarcT-NL said:

32GB should be enough to run DCS I hope ?

 There are a number of important Windows/DCS settings that may cause DCS to run out of memory.

• Fixed size Windows Page file (16GB-32GB, perhaps 24GB for Syria) - unfortunately the windows "auto" Page File setting doesn't seem to respond fast enough to DCS's demands, so DCS runs out of memory.
• DCS Options>Preload Radius - uses up memory to preload 3D models, etc. Max was appropriate for slower systems/hard disks but with DCS's increasing GFX demands and the availability/use of SSD's it now needs to be balanced, even with 32GB of RAM. A large map with many unique/individual buildings can be very demanding for little gain using max radius.

2 hours ago, MarcT-NL said:

Anybody else experiencing this ?

I don't have your issues with
• 1920x1080
• Windows Page File = 16GB
• DCS Preload Radius = 60,000

2 hours ago, MarcT-NL said:

... why do I still have this problem with ONLY the Apache and Gazelle ?

Please attach your dcs.log the next time DCS crashes and you are flying the Gazelle or Apache.

Edited May 26, 2022 by Ramsay

[MarcT-NL]

Thnanks very much.

Since I don't really understand what this page-filesize does, is it better to set it to 16gb or to 32gb, in my case ?

I have set it to 16 now. Let's try a bit of flying.

[Ramsay]

3 hours ago, MarcT-NL said:

Since I don't really understand what this page-filesize does, is it better to set it to 16gb or to 32gb, in my case ?

It's really hard to know what the "best" page file size is, although I have no issues with 32GB DDR4 and a 16GB page file in Syria, others have found they needed a 24GB Windows page file for stability.

AFAIK (simplified explanation)

Windows uses it's page file, when a program (DCS World) requests more physical memory, to quickly free up space.

You may think that DCS World is using 18-24 GB RAM and the rest is FREE but Windows, GFX drivers and DCS don't let that FREE space go to waste.
• Windows will use part as a RAM disk to pre-emptively cache files, etc. (why unload stuff if it might be needed later)
• GFX drivers do the same for textures, shaders, etc. first using free VRAM and then system RAM.
• DCS it self pre-loads textures, shaders, etc.

... while Windows tries to predict upcoming memory requirements, it doesn't understand DCS, so when DCS queries for height data from Syria's 17.9 GB "Syria.surface5" file it may run out of memory if the page file was set to "auto" (as Windows wasn't able to expand it's page file and make space in the system RAM fast enough).

AFAIK, ideally page files and caches should be big enough to do their job (and no bigger), as there's a performance cost when searching through them.

DCS's Syria map will take 56 GB RAM in a 64GB PC, so you could use that as a basis
• 32GB RAM + 24GB Page File = 56GB
... I'm not sure it "needs" it but YMMV.

Edited May 26, 2022 by Ramsay

[MarcT-NL]

Right.

Formatted all drives
Reinstalled W10
Updated everything
Redownloaded DCS and all modules

Tuned down the pre-load radius
Turned grass off
Textures to medium or low. Don't even know anymore.
Set the Windows pagefile-size to 16 or 32Gb
Set GEN3 in the BIOS
Installed MemCleaner
And now, in a final act of desperation I bought 320 euro's worth of memory to upgrade to 64Gb of RAM !

So do you think I did enough to get this to work ?

Started the Marianna's mission for the AH-64, punched in all the freakin coordinates (why can't this be done in the mission editor ?), and I flew off.

5 minutes...BSOD.

Mind you, this ONLY happens in the AH-64D and since the update of may-2022 also the Gazelle does this. I fly around hour after hour in the FA-18, P-51, F-5, Mosquito, and a few more. Also Huey, Ka-50 and Mi-8 are fine (before you think it is a chopper-problem).

So in the local\temp-folder I found the LastMissionTrack. Download here if you want to have a look...

http://www.marctelkamp.nl/LastMissionTrack.trk

BTW: this doesn't happen always !  I have been CP/G on MP-servers for hours. Seems to work fine. I just don't get it.

[Ramsay]

On 5/31/2022 at 12:33 PM, MarcT-NL said:

So in the local\temp-folder I found the LastMissionTrack. Download here if you want to have a look...

I don't see anything obvious ... it's the default SP AH-64D Persian Gulf "Mountain COIN" mission, the track played for ~25 minutes, ending in the middle of a blue on blue hellfire attack on a US outpost/convoy on the FLOT. It didn't CTD for me, rather it ended and returned to the DCS debriefing screen.

Looking at the differences between the track's options.lua and my defaults
• OPTIONS>MISC --> Random System Failures = ON (which may be an issue as the Apache is in EA and random failures might not be modelled yet)
• OPTIONS>SYSTEM --> Vsync=OFF (meant my GPU was running at 100% for the whole mission - with slightly lower GFX settings but 4-6 fps faster).

On 5/31/2022 at 12:33 PM, MarcT-NL said:

BTW: this doesn't happen always !  I have been CP/G on MP-servers for hours. Seems to work fine. I just don't get it.

Perhaps as CP/G you inherit the pilot's settings ? I'd try disabling System Failures in case it's causing problems (at this stage I'm just guessing and it's a process of elimination).

On 5/31/2022 at 12:33 PM, MarcT-NL said:

Mind you, this ONLY happens in the AH-64D and since the update of may-2022

I've had issues with one of Nvidia's latest drivers in another "Flight Sim", so it might be worth rolling back to a driver prior to the date of your first CTD, if you haven't already tried.

Edited June 1, 2022 by Ramsay

[MarcT-NL]

Thanks for your efforts Ramsay, but at the risk of jinxing it, I think I found the culprit.

I have had a vague look in the BIOS. I don't realy understand all that, but I saw some numbers at places which looked like overclocking to me. So I set everything back to [AUTO]. Haven't had a problem since.

I also noticed before that the GPU-temp went up to 85deg. celcius. That seemed a bit hot to me.  This is now pretty stable at 70deg.

My framerates have dropped a tiny bit, but I see less ghosting when I look sideways. So all in all very playable.

Just one quick question though: As said before I bought and installed 2x 32GB of RAM. Probably unnessessary, but I'll keep it. This was RAM of 3600mHz. However, when I look in the taskmanager, ir says it's running at 2133mHz. Did I miss something ?  I tried setting it to 3600 in the BIOS, but that resulted in a system-failure. PC doesn't start-up like that. So I turned that back to [AUTO] and it works fine, just too slow I think...

Edited June 5, 2022 by MarcT-NL

[Big-foot]

The 3600 MHz on the package refers to the XMP (eXtreme Memory Profile) that the RAM ships with. It is some sort of overclock profile (speed, timings and voltages) that the RAM manufacturer guarantees is stable.

You need to enable XMP in your BIOS and then the speeds, timings and voltages will be set according to what the memory manufacturer specifies.

If you only set the speed yourself, but not the timings and voltages, you will get an unstable system.

It is possible to enable XMP and still have an unstable system, because even though the RAM is good at those speeds, the memory controller in your motherboard or CPU might not be able to handle them. Look up what your specific CPU and motherboard guarantee in terms of memory speeds.

Usually 3600 MHz is not an issue, although I know that for example, Ryzen 5000 CPUs officially only guarantee support up to 3200 MHz.

What you can do then, is to enable XMP but manually lower the speed to 3200 MHz. With all other things (timings and voltages) equal, the RAM should still be stable at lower speeds, so you can match it to the spec of your CPU or motherboard.

I discovered this myself when my 4000MHz CL18 RAM would cause crashes on the XMP. Lowering the clock speed to 3600 MHz solved it for me on a Ryzen 5 5600X

Succes man, en goede vlucht!

Edited June 7, 2022 by Big-foot