[6.20] Frequent 1113 - Poss. Mem Leak (PerfMon Log Attached)

[sniper423]

I cut a PerfMon data collector to monitor X4 process and overall system main mem, GPU mem, and page file utilization to try and watch for it. After a few sessions this week with no apparent issues, I had an 1113 yesterday; of course I forgot to start logging for that session, but I rebooted my system and started a new session with logging that shows a nearly monotonic increase in utilization over a 4 hour session. I spent almost the entire session in one system, playing around with orders in the map or capping and repairing a pirate L. The minute I started flying around at the end of my session, you see a huge increase in memory utilization. Unsurprising, perhaps, but the concern is the basically-monotonic trend over the session.

PerfMon graph showing upward trend in X4.exe process utilization; total system % committed bytes is a mirror image of X4.exe process, so you can see that it's not another process which is responsible for the trend: https://www.dropbox.com/scl/fi/965x4jif ... c2kjg&dl=0

Note that the metrics I logged were: Total system GPU mem utilization by PID, total system mem and page file utilization, and X4.exe process utilization of mem and page file. Here are the raw log files from PerfMon:
https://www.dropbox.com/scl/fi/oih0cp82 ... tqbkr&dl=0
https://www.dropbox.com/scl/fi/jtxbp0gs ... um4zt&dl=0
https://www.dropbox.com/scl/fi/uw3cbxrb ... 9wf35&dl=0

Here's the PerfMon data collector set template which generated the above logs: https://www.dropbox.com/scl/fi/3e3lg6ki ... 6ymp3&dl=0
And here's the PowerShell code I use to launch the app and then the PerfMon logging (since the logging requires X4.exe to be running as a process):

Code: Select all

# Define the path to the executable
$exePath = "G:\SteamLibrary\steamapps\common\X4 Foundations\x4.exe"

# Start the process
Start-Process -FilePath $exePath

# Define the name of the Data Collector Set
$dataCollectorSetName = "X4 Performance Monitor"

# Start the Data Collector Set
$logman = Get-Command logman.exe
& $logman Start $dataCollectorSetName

Will continue trying to collect logs to see if I get a PerfMon dump that aligns with an 1113 and its associated dump file.

I'm running 32GB of RAM + 32GB fixed allocation page file, and this was from a clean boot; with at least half of 64GB for X4 to play with, I will have a very irritated bone to pick with anyone who suggests my page file settings are to blame.

EDIT: 2024 Mar 04
--------------------------------------------------------
*sigh* Somewhere along the way since my new PC build back in Sep 2023, my page file settings were reset back to system managed size from my original manual setting of a 32GB fixed allocation. Can't even begin to guess when or how. Anyway, the system managed partition has had me running with 4-6GB of total swap file for some unspecified amount of time - probably months.

HOWEVER, there is still a real problem: The monotonically increasing X4.exe process memory consumption trend remains. It starts at ~16GB and ends in ~24GB of process virtual bytes - hitting 100% of a 38GB commit limit and a subsequent 1113 crash. Will continue to collect data.

[sniper423]

viewtopic.php?f=180&t=460202&p=5216269#p5216269 establishes a hypothesis that OneDrive is the cause of this issue. Seems like a high-likelihood, given The1Whistler's success. I'm going to play around some more on my machine and post what I find.

[sniper423]

Definitely not OneDrive...or at least it's not the primary root cause between the hours of 21:30 and 01:30 on a Sunday night.

The following snip of PerfMon shows 4h of gameplay after a clean reboot in which there was minimal growth despite 2 boarded capital ships and at least a dozen saves to my OneDrive (not that it should matter, but the writes comprised 3-4 quicksaves, 2 discrete file saves, and the rest autosaves): https://www.dropbox.com/scl/fi/2ayv2vy0 ... lpu2t&dl=0

And of course, I got an 1113 this morning after playing [i]without[/i] PerfMon logging from a clean reboot from about 09:00 to about 09:50. In this case, I was actually running missions (Hatikvah Free League mission sequence)teleporting around ships, and using the elevator/transporter in various ships/stations. In that timespan, there were only a few saves at most. Here's the associated DMP file: https://www.dropbox.com/scl/fi/q7m39b8i ... 1ifdh&dl=0

I'll note - at the risk of it being a "red herring" - that I experience the elevator/transporter control panel failing to load as an interactive object probably 25% - 33% of the time. It definitely happened this morning. But, again, it may not be dispositive of the 1113 crashes.

EDIT 12:28:
I edited the OP. I found that my original 32GB fixed allocation paging file setting was reverted to system managed sometime over the past few months since I built the PC in Sep 2023. I was only getting 4-6GB of paging file. However, there's still a real problem here: The game crashes have been occurring after X4.exe memory consumption monotonically increases from 16GB to 24GB of what turned out to be a 38GB commit limit. And it's screwy that I was able to have a 4.1 hour session that increased steadily - but slowly - from ~16GB to ~23GB (of~38GB limit), yet two separate sessions this morning managed to achieve the same memory consumption in only 0.75 and 1.25 hours each (both of which resulted in a crash). And the 1113 page definitely says the game shouldn't be consuming more than 6-8GB.

[sniper423]

Ah, finally have it, now that I have two long data collection sessions with my page file fixed (i.e. fixed allocation at 32-ish GB) - one with OneDrive ON and one with OneDrive ON.

Proof that a problem *does* exist, but that OneDrive makes it worse.
System PerfMon memory graphs
OneDrive ON - 10 hour session - X4.exe process Virtual Bytes went from 18 GB up to 41 GB: https://www.dropbox.com/scl/fi/wcxtmctb ... 1tvin&dl=0
OneDrive OFF (Pause Syncing set for 8 hours) - 12.5 hours session - X4.exe process Virtual Bytes went from 11 GB up to 28 GB: https://www.dropbox.com/scl/fi/qlhcy0w3 ... pmquo&dl=0

According to MS documentation, Pause Syncing suspends all monitoring of OneDrive folder and will not capture history or any intermediate file versions.