安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
讨论规则及指引
举报此帖
There is absolutely no reason to have a pagefile running, especially as a gamer post 2007 unless you're running on <4GB VRAM because "it's fun and interesting" as some liked to put it. The game will allocate what is avail and flush the RAM if need be unless you play very specific trash titles like GTA5 which'll just keep writing into RAM ad infinitum.
And the game trying to play is? Ark?
Render in lower resolution lowest possible?
Render GPU to power saving mode?
Kill any and all non windows running through msconfig?
Since already installed windows still run sfc and dism repairs.
Turn off cortana, turn off printers, stop sharing folders printers, kill emoji onscreen keyboard mode, just stop anything obviously useless during gaming
Make sure in desktop mode not tablet mode
Stop eating parts of the computer sub conscientiously.
check and alter sleep mode and other power options how hardrive wifi and gpu power is
If go through list and is not one of these. Train for and Run a marathon for a some years.
Course there is take a course on computers. Check bios make sure motherboard is okay with the ram and the port to the gpu was not damaged from changing from one to another. The memory could be either gpu or ram.. and then always almighty eventvwr.
The OS ans many games will not function properly if you totally turn that off.
Well that's the sad part, it's 2023 and yet Windows still does need a PageFile even with 32GB of RAM
Trust me, things may appear to work properly but with that disabled many games will crash after a while of playing without a PageFile
The only special use case would be VMs but then we are no longer talking about general usage are we?
And if it's about x86 apps then things such as https://www.techpowerup.com/forums/threads/large-address-aware.112556/ does exist and can be fixed. Okami comes to mind which still only has a x86 client.
Turn off pagefile, restart computer
Then follow this advise
That did alleviate some issues couple years back yet now more ram and so forth was not necessary. Page file is definitely still necessary unless you like to reboot ever 12 hours. Even at 48 see this. 64 well that is gonna be tested with ddr6, ha.
Can add vulkan shaders through steam settings in DOWNLOADS.
There is also a shader cache size for nvidia gpu now you can set.
Course could upgrade driver for gpu and just the gpu no extra apps clean install and let default take over might prevent a memory leak.
Shut down overlay or just move all of steamapp out of steam folder, uninstall steam, restart, install move back steamapp go through process of each user agreement. Ack forgot to add gonna have to commit to finding everyone one of your saves and backing them up or the cloud might ruin everything.
Task manager is your friend open it and check thoroughly during one of those ram crashes create dump files.
WER\ReportArchive could house some important information. Reading however is another matter.
If the OP is doing this (they haven't told us yet what their page file is configured to even despite multiple people asking about that), that is disabling the page file, then this is most likely the cause of their problems. Even if we have say 64GB of ram and 10GB video card none of that matters. Many games actually require we configure the page file in windows and it be enabled and allowed to grow to a couple GB or they will throw up this "not enough memory available" errors.
We have to have the page file enabled and configured or some games will not run at all.
@ŠÌŁÉNT: If you disabled your page file then go re-enable it and see if this error goes away.
Sounds more like an error you'd get when using an Intel iGPU
I highly suggest that disabling the page file is a very bad idea, unless you want a high chance of being disallowed from having access to all of your physical RAM.
Too many people lack an understanding of memory management and it shows, because anyone who has even the faintest understanding would never suggest blindly that it be disabled just because a PC has a certain capacity of RAM. Unless you have vetted the needs of the user in question, you are not in a position to tell them they are fine with a lower commit limit. There's way too many realistic and practical workflows that do result in committing a lot more than they "use", and you'll run into issues if you push your RAM and have a limited page file setting in those situations.
This isn't some "optimization setting" thing. This is a "things commit more than they use, sometimes a lot more, and the possibility of headroom for if that disparity ever shows up is good to have" thing.
Your commit charge can not exceed your commit limit on Windows (it sometimes can on Linux... but then very bad things can start to happen [stuff basically just falls apart whereas Windows simply disallows it to get to that point to begin with, because Windows expects you to have responsibility and not set this where it will artificially limit you, whereas Linux takes the training wheels off and says "it's on you"]).
Let's simplify it to two facts, and yes, both are facts.
1. Your commit limit equals your installed physical RAM plus page file maximum.
2. Things tend to commit more memory than they use, sometimes a lot more.
Combining those two things, it's easy to see you will likely lose access to all of your physical RAM with a disabled page file. A manually set, small one is only marginally better.
For clarity, here is what "system managed" does. Your initial page file is ~1/8th your installed physicality memory amount. The maximum it can grow to three times your installed physicality memory amount, and it only does this if it sees your commit charge approaching the current commit limit. In other words, it adjusts this as needed, and this is how it should be. It doesn't reserve space that isn't needed, yet has the ability to when it is needed. It's adaptable. Why would you want it any other way?
"But I've done it since forever and didn't have issues" you say? Sure, that's possible, and even believable. I'm not saying you will have issues. I am saying you will possibly limit your access to your RAM capacity in any workload where the commit value is higher (and it almost always is). So the fact is, if you disable it (or manually set it to some low value) and don't have issues, then you're simply not pushing your RAM to begin with. Meaning you (not you, Fox; I'm agreeing with you/adding on to what you said) are not in a position to give advice on it to begin with. To give an analogy, it's like buying an RTX 4090, pairing it with a low wattage PSU, never actually pushing the GPU too much, and then saying it works. Sure, it does... because you're not actually pushing it, and therefore in a poor position to say what it could need. It's the same here.Here, here! This was also me, until I learned (a little) better.
I had 16 GB in 2011 and thought maybe the page file was some unnecessary thing.
It sure was fun having Windows tell me I was low on memory with 10 GB/16 GB in use only playing Minecraft. Fun fact is it's worse today as I often play and have ~16 GB (sometimes much more) in use while ~32 GB (ditto) is committed, meaning if I had 32 GB RAM (I have 64 GB) and disable my page file as the above advice suggested, I'd then have issues with Windows saying I was out of memory (hitting commit limit!) at half capacity use and just playing Minecraft! Forget background stuff!
Over the years and even as we speak, many games prove me wrong.
Windows OS itself might be fine without it enabled if you have around 32GB or more of RAM and never do gaming or pro-work app stuff. But if you do, then it's a must to not only leave it enabled, but manually set it better then what MS does when it's left on auto. Such as 8GB MIN and 32, 48, or 64 GB Max. All depending on how much system RAM you have installed of course.
Some further additional information: Some system services just use the page file for their function because they are coded to do so. If the page file is disabled and that system service (I'm not sure which do require it and which do not) tries to run and use the page file and it doesn't exist then that service will fail. If it's a core windows service you could see blue screens and entire system crashes/hangs. In general it's a very bad idea to disable the page file.