BMS Crashes after time spent in flight - Memory Usage warning appears moments before crash - Memory Leak issue?
-
@white_fang People may disagree, and they have their reasons, but in the era of historically cheap RAM prices, I recommend disabling pagefile entirely.
It almost never makes sense that I would want an active page of memory to be written to disk, and discarded/reused…
The entire concept dates to a time when virtual-mem OS was running on earliest 32-bit chips … Intel 386 or 486, with 16MB (not GB, but MB!) of RAM
Reasons to keep it:
- you’re a driver developer and want OS to record better kernel-dumps during bluescreens
- you really do run heavy scientific / big-data analysis workloads that, by design, exercise all physical memory
-
@airtex2019 All correct m8. I’m aware of that “eternal” discussion , pagefile or not. - dates somewhat , mostly from winXp era.
In '98 … you really needed it , since ram was limited then.Ones with more ram saying it is waste of space, and performance hit, since ram from disk…, with enough ram clearly no need for it…
Others says it is important for windows mechanics, addressing space, decay cache… etc, even with more then enough ram… just leave it to windows decision., or small size manually, … like 1GB.
All ok with that, personally I was using sizes 80% of ram, fixed, manually … and defragmented , - in one disk fragment, even gone that far
But this, above, what I saw blew my mind…
I never ran something what would require that much ram that pagefile would auto rise to 100% of ram, equally.
Clearly win10 also don’t need 64GB … what for??
Don’t know will I able forensically study the event , but an “educated” guess, it is some stupid algorithm in question.Now, stubborn as always , I’ll just disable it alltogether and see what happens.
- I BET YOU HAVEN’T KNOW THIS:
https://www.tenforums.com/performance-maintenance/109733-huge-pagefile-post1367914.html#post1367914
The pagefile size can increase to the the size of your RAM after a system crash if your pagefile size is automatically set. For the next 4 weeks after a crash, the system managed page file will have a minimum size at least the size of the amount of ram in the system - 16GB in my case. Delete the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\LastCrashTime and the page file will revert to its former System Managed size - 2432MB in my case .I hope this tip helps anyone mystified by the same issue.
- I BET YOU HAVEN’T KNOW THIS:
-
@white_fang disabling the pagefile is an old performance trick, BUT for systems that operation will never exceed the ram.
if it does u get an instant crash iirc.
this was like when ppl was starting to have 16 GB when 8GB was more than enough, now maybe for 64GB.
pagefile is needed in general and at the end is a good thing to have for stability.
The norm for pagefile was double the ram on your system.Another trick was to have pagefile on ramdrive… example 64 gb ram and set the 32 gb for pagefile… hehe… super fast… though kinda stupid…
-
@white_fang yes, if in doubt, set it to a fixed/maximum size, eg 1000 Mb…
definitely the last thing you want is OS to decide it needs to dynamically grow the pagefile (and fragment it!) at the precise moment your system is under heavy memory pressure…
Others says it is important for windows mechanics, addressing space, decay cache
I know of no such arguments. For laptops, if you like to use Hibernation sleep state … it can amortize the time to write pages to disk. (Pages backed by pagefile.sys don’t need to be written to hiberfil.sys)
Also, people forget that even without a pagefile, there is some elasticity in virtual memory mapping – any file opened as readonly/shareable, is itself a “mini-pagefile”. Things like EXE and DLL files… images, font files, other resources, are all typically loaded this way. If loaded from a fixed/system drive, anyway. You’ll notice the size of an EXE doesn’t typically contribute or correspond to a process’s “private working set” metric. This is why.
So, some disk-I/O can still occur, as memory pressure grows. But hardly noticeable – for existing files, obvs it’s read-I/O, never write-I/O.
-
@Arty said in BMS Crashes after time spent in flight - Memory Usage warning appears moments before crash - Memory Leak issue?:
if it does u get an instant crash iirc.
There is a desktop popup alert when running low on ram… I think when hitting about 80%, don’t remember. But yes, when exceeding 100% commit-charge, stuff will start to fail with out-of-memory exceptions.
This can/will happen eventually, anyway, in the event of a leak… only difference is your system will remain snappy and responsive, up until the crash – instead of grinding to a crawl, swapping memory for disk constantly.
-
Hello to you I also had the same crash on June 10 during a multi flight.
I was in the landing phase.
The memory window appeared for a few seconds then Falcon crashed, I also have a text file but no .dmp (0 bytes)
My setup is:
W11(64bit)
16gb
nvidea 1060 with 6gb
a Ryzen 5 3600Xhttps://www.dropbox.com/s/qa91nfqh74rcw52/2022-06-10_212815_crash.txt?dl=0
-
@airtex2019 Ha m8, tho that’s all valid, but since SDD/NVME (chip drives) hard drive fragmentation is hardly an issue anymore… we’re not dealing with mechanical heads jumping to different sector positions… it is all “electronic”-al now. - we’re talking about nanoseconds now (similar to ram, still bit slower ) but not microseconds as with electromagnetic-mechanical drives.
…decreasing ssd life is another thing ,… would need to measure first how much time pagefile is actually written per time, number of access writes…
It would be stupid , well, for me, for expensive nvme (pciex) drive , to get its life reduced because of pagefile on a daily basis …
BMS is ok , I can (want to) take that ,… but with pagefile on daily basis… sorry windows , we’re not that “good friends”Your advice is just as fine, and yes, pagefile is pretty much what you’ve described, memory backup, … set it to fixed size 1024MB … even on sys/win ssd disk … it is already used daily , can’t avoid it, so, fine.
That what windows want reserve of ram backupped in file for dump analysis is not my problem… I’m an user … I ain’t gonna beta/debug your corporative (but necessary) junk … I ain’t a voluntary beta-tester, I paid for product and want it to deliver. - not to “test drive” your flu-shots on me/my system. - you want it debugged, fine, hire workers, pay them - but do not force end users in so-called voluntary crap… that is heist of century… and for people “without heads”
(kind of a rant here, maybe even oftopic, but uh… its all true)Cheers
-
Update from my last multiplayer campaign flight.
Again, it crashed on the way back at approximately 01:40 hours from getting into the pit (3D). I can confirm the crash always happens when Page File gets to 100% (of my total 17.1GB available), showing 0MB left.
I was monitoring total RAM usage, page file (called “commited” in the Task Manager Performance tab), BMS memory commit size and GPU usage.
For reference then:
- Joining 3D: 6.5GB Total RAM | 5.7GB BMS Commit size (note, I did recon both Kunsan and the Target area prior to commiting, increasing RAM usage and Pagefile already)
- At EOR Kunsan (16:20 minutes elapsed): 6.9 Total RAM | 6.1 BMS Commit | 10.1 total Pagefile
- At Rejoin (24 minutes): 7.3 Total RAM | 6.8 BMS Commit (using 2.0 GB GPU)
- 45 minutes: 6.6 Total RAM (so, RAM usage decreased as soon as we left Kunsan, increasing to ~94% at most when GPU usage was way up there) | 8.2 BMS Commit | 13.4 total Pagefile)
- 1 Hour 10 minutes: 10.9 BMS Commit | 14.7 Pagefile
- 1 Hour 15 minutes: 15.2 Pagefile (GPU at 86%), total RAM 6.6
- Approach (01:36:30): 7.1 Total RAM | 13.4 BMS Commit size (didn’t get total pagefile, but was getting the blue message already)
- Crash (01:38:52): at 100% Pagefile (17.1GB)
So, while RAM would vary between 75 - 95% depending on the amount of units and objects nearby, just as GPU would go from ~85% to 100%, the Pagefile kept increasing non-stop (at a possible constant rate?) since I joined 3D.
Should my Pagefile be increasing like this? To be honest, I’m not even completely sure what Pagefile really is and it’s usage, but wouldn’t it be possible to unload whatever is loading it while I’m flying?Otherwise, we are always flying on limited time if it only goes up, being only a matter of time until it definitively crashes based on how much Page File you have available.Thanks again for all the help and suggestions!
Cheers, Archer -
@ertiyu said in BMS Crashes after time spent in flight - Memory Usage warning appears moments before crash - Memory Leak issue?:
The memory window appeared for a few seconds then Falcon crashed
Do you remember if it also showed 100% (or a ridiculously high number) of Pagefile usage?
Edit: Ah, nevermind, your crashlog does confirm it, showing 5MB of pagefile left, probably the same that’s happening to me.I’ll have to fire up 4.35 again and check how my Pagefile behaves. The only time I had a blue memory warning back then was in day 1 of a campaign, with ground units and air gorilla in the 3D bubble (even other members in the flight reported low FPS), but it DID NOT result in a crash even then.
-
@ArcherAC3 You are experiencing a memory leak … about 50 to 85 Mb / min, sounds like.
Not everybody is experiencing this, so… the next step is still to narrow down possible causes.
Yes, fly again on 4.35.3 with your same OS and software environment. (I realize it takes about 30 min to see the significant increase in FalconBMS.exe commit size.)
Maybe also try a long single-player mission on 4.36, to see if MP is a contributing factor…
At some point you mentioned OBS? That is probably the only other thing I can think of, that could possibly leak memory at 50-100 Mb/min. (Does it record at the system level, or does it inject itself into FalconBMS.exe to capture frames as they’re presented… I don’t know. But it’s on the shortlist of suspects in this case.)
-
@airtex2019 Hmm… where’s the biggest mem impact? = Graphics./ Textures
He has 2GB of chip vram , the rest of used vram is shared with system ram… so , it might happen that even some part of vram gets into pagefile ?? … streched/longshot… and crazy, but still maybe?
Long story short… So , the GPU driver/app part which controls sharing ram with system may be leaking … as all sort of crap is going on/…
In essence:
System ram is getting paged, … Vram is shared with system … then windows page that system portion of vram …But… beating a pretty much a dead horse. Needs more RAM , as conviced by Max and Hawk , case closed.
What can try , is max out pagefile , fixed , to eg 32GB or even 64GB … just for the test… once… see if it fills again then…
That will get us some time before crashing. -
@white_fang just to be clear, I’m not trying to convince Max and Hawk that they have a bug. I hope it’s not true … I wouldn’t know where to begin to tell them to look, if it is.
I’m just trying to help a fellow pilot enjoy BMS without crashing, and grinding away his hard drive for hours. And maybe we all learn something along the way.
Anyway, there is one other report now of similar experience, on a desktop w/ 16 Gb ram and 6 Gb video-ram. I’m hoping we discover it’s OBS or some third-party VR plugin or something that is common cause…
-
@airtex2019 There is no need to “convince us”
If there is indeed a memory leak of 50-85 MB/minute, I sure hope it would be a more well known effect among many. It’s really hard to tell from 1 report or 2 if there is indeed something real. I’ll anyway forward this report internally and will see, we do have ways to track memory leaks and usually serious ones are found if a coder take the time to inspect closely and use tools that help. I can also tell that in last years we use more and more less risky data structures - More std structures like vectors and less self-allocated arrays or whatever, and so I hope it should lower the chances for a leak.Cheers!
-
@I-Hawk Yeah AppVerifier alone would flag any orphaned allocations, at shut-down time. I get that. If there is a leak in BMS process I think it would likely be in a dependency (like audio codecs or networking or graphics drivers) rather than first-party code.
Or, something like stream-capture software, or those dodgy VR-adapter libraries, or even things like RivaTuner which seem to inject DLLs into processes making dx calls.
Will be interesting to see if there’s a diff 4.35 vs 4.36. And if so… I wouldn’t know any easy way to narrow down the culprit further, than to clean-reinstall Windows & BMS, and add in other software one by one.
-
@white_fang said in BMS Crashes after time spent in flight - Memory Usage warning appears moments before crash - Memory Leak issue?:
beating a pretty much a dead horse. Needs more RAM , as conviced by Max and Hawk , case closed.
I’m the one with, possibly, the less computing knowledge here in this aspect, but, how would increasing my RAM stop my pagefile from increasing until a crash? Of course, I have no clue on what’s the actual problem, but doubling my pagefile amount would - I’d think - only allow me to fly for twice as long before a crash, no?
Also, I did not have OBS or any external programs running on these 4.36 flights as possible memory leak causes. Only app running was TeamSpeak, but it didn’t consume any significant RAM and Pagefile size.
Thanks again!
-
@ArcherAC3 said in BMS Crashes after time spent in flight - Memory Usage warning appears moments before crash - Memory Leak issue?:
how would increasing my RAM stop my pagefile from increasing until a crash?
It probably would not. Kind of a separate question, about what is the real expected RAM footprint and minimum-system-reqs. On my system, BMS stabilizes at about 6.7 Gb commit size (but only about 1.4 Gb in active “working set” use at any time). The rest of Win10, with nothing else running, adds up to about 8.5 Gb total commit.
This means, BMS probably won’t run on a 8 Gb sytstem, without some sporadic disk I/O happening in the background, as pages are swapped in/out when various background processes wake up and try to do things. On a desktop it might be ok, but in a case like yours, laptop with only 2 Gb video-ram, some of that 8 Gb will be reserved for that purpose… so there might be quite a bit of disk thrashing and stuttering as you fly.
doubling my pagefile amount would - I’d think - only allow me to fly for twice as long before a crash, no?
Correct. And your HDD will be writing 1-2 Mb/sec to the pagefile, the whole time, as you fly.
-
@ArcherAC3 … We, no one here (probably with enough ram) don’t have your problem … no leaks …
Of course increasing ram won’t help plugging the leak itself, but it will avoid unnecessary paging and therefore could avoid “unstable transactions” between ram<>pagefile which seems are happening.
Is it a problem for getting some more ram for that pc? , last time I’ve checked , it wasn’t so much expensive…
-
@white_fang I have been using intelligent standby list cleaner on my laptop for various games and programmes which clears standby memory and can be set up to run automatically . I do not know if this would help with the crashes but it is worth a try.
-
Just to let you know that I’m having almost same problem while refueling in TE. I was curious to watch F-18 in refueling so I add a flight of four of them and timed to refuel when I was there with my flight of 2 F-16. I run an i7 w7 16GB ram. I try to attach a picture I’ve done.
Many thanks!!
No I can’t but blue line says:
RAM: 15,9 GB / 15,9 GB ( 100% ) - 45 MB free
Process: 30.0 GB / 8 TB ( 0% ) - 8 TB free
Pagefile: 21,6 GB / 31,9 GB ( 60% ) - 10,3 GB free
Texture: apx 0 MB free
No CTD, some light stuttering.
Hope can help -
@Paulg-0 I’ve had/have same thing in previous century - when I had a P3-300/1GB computer … just learned to do it manually,… no need for 3rd party app , you can do it with windows batch/script alone.
Like I’ve said in this post 14 days ago. (housekeeping)
https://forum.falcon-bms.com/post/347320@Gancio … have you miss a thread maybe my friend , what you want to say ?