Essentially yes.... typically the system managed drive will have 1 to as much as 1.5 TIMES the amount of memory in your system... have 4gb of ram at the when windows was setup/installed for the first time... system managed will usually set a 6gb Virtual memory/page/swap file size...

have 8gb installed, typically this means 12gb will be system managed.

have 32gb of ram? Start biting at your nails or ripping your hair out if you were trying to figure out why your primary drive was being loaded down with a 48GB Swap/Page File which is TOTALLY unnecessary and rediculious. This is painful for those with SSDs.. specially considering there relatively small size.


As i stated, Disabling shouldn't result in any issue even if you disable it for both drives... however if your concerned.. set a page file of something between 800mb to 2048mb in size, anything ABOVE that is totally unnecessary and will cover all the older programs that may forcefully request pagefile space which is highly unlikely...


It is a good debate, unfortunately we have people still realing from the pains of windows 9x and 2000 days as well as the xp days.... experts that have what they said taken somewhat out of context, some of which cannot really state anything they really think because of being quoted as saying such if they did say making them responcible for any problems any one person might end up with (sadly).. and then there are hardcoe fanatics that will say one thing with or without knowledge about the subject and never even attempt or look into the matter beyond what they "know" accusing others of being idiots for suggestion alternatives. The largest arguement against disabling the page file for large physical ram users is "your going to make your system unstable... things are going to crash.. BAD THINGS WILL HAPPEN..... THE SKY WILL FALL AN THE WORLD WILL END AND THE UNIVERSE WILL BE DEVIDED BY 0........ really?

Much of it has to do with capabilities for previously poorly developed software the basically would flip out if there wasn't a page file... which has been obsolete for mostly 10+ years.


Precisely, Typically i do build some of my systems without the page file active simply due to one fact, and that is i have usually significantly more than 4gb of ram installed... prior to that i set a maximum and minimum of the same value for the page file at nothing more than 2gb (2048mb) with some systems with a min/max of 1024mb. Allow the page file to resize under a windows XP enviroment leads to pretty nasty page file fragmentation.... it's always best to set it to 0.. followed by disabling.. reboot... run a full defrag, a few times if necessary, and then re-enable it with both initial and max values that are identical.

For windows vista/7 the fragmentation is curbed quite a bit, allowing it to manage it by itself on standard hardrives is quite fine provided your not running anything more than a 4gb ram install. Otherwise the pagefile like i said.. starts to get out of hand and excessively large consuming large portions of space.... If anything no value over 4gb is required at all....

Those with SSDs should keep it in check.... as i've mentioned..... disabling is a wise idea, moving it to another drive is totally personal opinion. But 800-2gb page file on an SSD isn't to bad.... it's kinda that idea of frequently re-writing data to the same block of cells on the SSD which isn't exactly the greatest thing... that's another debate which isn't entirely clear.

I mentioned this earlier..... without a page file.. BSOD dumps don't occur.... and typically if your having a BSOD... 99% of the people aren't going to go look at the dump files anyways.. if you have this issue re-enable. wait for BSOD..... then check the dump. Otherwise no one should be experiencing a BSOD.. if they do, there is a reason.... and should get it fixed asap.


Older CAD or photoshop programs would complain... but since adobe photoshop 7 and some of the more recent cad programs within lets say the last 5+ years..... don't and won't... many of them like i mentioned, use their own scratch disk system which is essentially IDENTICAL to that of the page file system. It works within it's own little system. This was required because of the 32bit limitiations imposed, and they found the best way they could to work around it. Personally i've setup a few graphic artists that since years ago, has not had a single problem with a disabled page file provided with sufficient physical ram (4gb+). Not to mention i've also setup some CAD/Engineers/Architects with their required heavy duty programs that are memory hungry and have had NO complaints or reports of issues from them due to their page file being non-excistant.

BY the way, disabling the physical DISK page file doesn't suddenly make it completely disappear either.... There is still Virtual memory "outside" of the physical ram.

True, but for that slim chance that you want to see a STOP error memory dump to diagnose a problem, then a page file comes in handy. You really aren't going to miss a smallish portion of your hard drive.


My point isn't the end of the world if you disable it, but there are some benefits to having the extra buffer. You don't need 64GB of page file or anything but having some is a lot of efficient that using RAM for the same purpose. RAM is definitely cheaper than last decade, but hard drive space is cheaper (excluding SSDs).

Some programs still require it. I have been told that Oracle XE requires a pagefile. But i dont really want to test it just for the kicks. Never touch a running system...

It's so incredibly unlikely that anyone is going to even go looking for and then read a stop error to try and figure out the problem, even gamers and computer enthusiast generally don't even bother, they can stick with just reading out the stop error code itself and looking it up... some of the garbage in the stop error dump hasn't anything at all to do with the issue.

Obviously if your a developer that has a real potential for seeing BSODS.. then obviously not a good idea as you'll RELY on the dumps to figure out.

otherwise .... using a standard hd yeah... 800-2048mb of space isn't all that bad... reason i give more than 1 option when discussing the page file.





I'm not entirely following how using the page file on a hardisk is remotely close to being more efficient if you have more than enough physical ram to accomidate it. If your specifically talking (in referrencing your last sentence as being related to the whole quoted), value $ per GB of "total virtual memory" then yes, provided with circumstances in which your lacking memory and need more, the page file is your savor.... however this is not at all seen as being touched with modern average to above average machines containing more than 4gb of ram.

Without a page file, all allocated memory must be backed by physical memory.
With a page file, allocated memory can be backed by virtual memory, or physical memory as required.

This is most easily explained with shared memory.
if a process requests 4GB of shared memory the system's commit charge ('promised memory') will immediately increase by 4GB.
In a system without a page file, this would require that 4GB of physical memory be immediately allocated to back the shared memory.

However with a page file present this 4GB allocation does not need to consume any physical memory (atleast not immediately).
Instead 4GB of virtual memory is allocated; i.e. the allocation is backed by the page file, rather than physical ram.
Physical ram is only consumed as pages of the allocated memory are written to (modified).
If only a fraction of the allocated memory is written to, then only a fraction of the total physical memory will ever be used.

If you require further proof:

Try writing a small program that memory maps a large file (say 4GB).

- As soon as it's mapped, your system's commit charge will increase by 4GB (4GB of memory address space is consumed)
- Without a page file, you will immediately lose 4GB of physical memory - as that's the only kind of address space you have.
- With a page file, you will lose almost no physical memory; instead you'll lose 4GB of virtual memory - address space that is backed by the page file.

The page file is a guarantee (an insurance policy if you will), that allows your computer to promise more memory than is physically available - allowing it to use it's physical memory more efficiently.

It's like an airline overbooking flights; if the airline didn't have 'virtual seats' (seats that statistically will never be used), it'd end up flying planes that were under capacity and so would need more planes to carry the same number of passengers.

There should be no reason to use pagefile unless you run out of physical ram and nobody want the slow overhead of pagefile. If you know you're not going to use 6GB ram or more then it's worth turning off because it only serves as a backup if you run out of physical ram.

Did you even read my post?

It's not about using the page file; it's about using the additional virtual address space made available by having the page file.
The virtual memory may never be writen to, but what's important is that you have the extra virtual addresses to promise to live processes.

Why would you worry about virtual address space on a 64bit OS? Virtual memory serves old systems with lack of physical memory and VAS. Those who have a 64bit OS and loads of RAM shouldn't need to worry about it in regard to gaming.

Eh? 32bit/64bit is irrelevant.
Regardless of what your OS's maximum logical address space is, it will never allocate memory that lies beyond what you have backing storage for (be that physical ram, or page file space).

I am posting here cause some of this escapes me....I thought i understood most of this.(really i did). We will use Pics to help me ask Questions. everyone seems to be responding here, so dident want to start a new thread.

I will be using Everest (bad ass does anyone use this?) the pics are as follows....

http://i232.photobucket.com/albums/ee72/camaro_69_327/Memory/Firststart.png (Amount allocated / used / % in use)
Physical MEM used= 8182/1593 (19%)
Swap space = 20453/1644 (8 %)
Virtual MEM = 28635 / 3237 (11 %)
Pagefile.sys = Unused!

http://i232.photobucket.com/albums/ee72/camaro_69_327/Memory/Skyrimrunning.png ( I loaded Game, and RAN from Riftin, due North to Stony Creek cave) I say ran cause i was being chased by..trolls, Dragon, Bears, Hiwaymen...you name it, it chased me...hahah

Physical MEM used= 8182/2488 (30%)
Swap space = 20453/4234 (21 %)
Virtual MEM = 28635 / 6723 (23 %)
Pagefile.sys = Now shows usage, 751 MB (6%)

http://i232.photobucket.com/albums/ee72/camaro_69_327/Memory/Skyrimafterclosing.png
Physical MEM used= 8182/1146 (14%) ?? less then fresh system?
Swap space = 20453/2038 (10 %)
Virtual MEM = 28635 / 3185 (11 %)
Pagefile.sys = went down to 736 MB used. (15 Mb freed?)


Now with these as reference, What are the 4 types of memory doing? They all change real time . i can watch all 4 numbers and % change. They are different sizes. one could not say that Swap Space is just Page file because they are not the same numbers or % used. The C:\pagefile.sys dident even start to be used till i put the computer to sleep, upon wake the % then showed and you can see Skyrim use a tiny portion of it.

What is the difference between...
Swap Space (20 GB ? if this is the same as Pagefile why is it not 12 GB?)
Virtual Memory (28 GB ? Again not the same as Page?)
Paging File (C:\pagefile.sys) This is set to 12 GB and shows as that. (MAX used after Skyrim ran for 20 mins = 852 MB.

These are all Different? What gives. I did not list the Top Memory because we know that is the actual real RAM installed in my system.

Have at it Guys.....learn me....lol

EDIT:..OMG im an idiot..reading my own post and "light BULB"
Swap Space = 12 + 8 = 20

What's even more crazy is that more physical RAM you have, more pagefile it reserves. can you imagine the disk IO usage of that amount of pagefile?

That is part of my questioning...i see a lot of IO running Skyrim...but its not Swap file?

And a side note.....did you know that IF Skyrim is alt/tab'ed and you put computer to sleep .....it doesent care.....after waking computer , Tab'ed back to game and played!!!(just laugh)

I'm not sure why, but disable pagifile topic keeps reappering. Here is the link that explains why this is a bad idea: http://arstechnica.com/civis/viewtopic.php?p=21013929#p21013929

camarao it all looks good, I'd use perfmon instead (builtin) or processixplorer in place of everest if I'd want to monitor.
btw, page file isn't virtual memory (turning off paging file doesn't turn off virtual memory), at least it's not all of virtual memory - only small portion required for backup of process's private bytes.

I agree with those that say eliminating the pagefile is not a good idea but I am not going to preach why, here. What I do is move my pagefile to my programs disk, off my C: boot and OS disk. I then set up a smalish page file on the boot disk just big enough for a typical dump file.

I've had my pagefile disabled (completely disabled) since setting up this new machine in October - 16GB ram, 120GB SSD with Windows/apps/current games on. I've never had a single issue with any application, game, or otherwise - no stability problems, random errors, nothing.

I hear nothing but scaremongering about disabling a pagefile completely, but I think it's just very outdated information - it's been drilled in so much from the days when it really WAS relied on, that people still cling to it as sagelike advice now. Sure there may be some outdated programs, that particular users run, which physically rely on a pagefile - in which case, if you have problems with something that google can't fix, try re-enabling a pagefile and see if that fixes it. Until then, just keep your pagefile off and see how you run. I don't know of any such programs, nor have I encountered any, and I'm a very heavy user of my PC.

If it was something absolutely fatal that nobody should ever do under any circumstances, I don't imagine that it would be such an easily accessable configuration for any user on any Windows platform (not just the "ultimate" windows versions, but even the home ones let you disable the pagefile with ease).

Well Windows does use disk IO for such things as superprefetch, indexing, scheduled stuff but if you have an SSD then Windows does turn such things off by default. Just image Windows using all that pagefile off an SSD, that's crazy and why there is totally no need for it.

In the end Windows is meant to work well With pagefile on because most people do need it and you won't get told otherwise but the simple fact is that it's a terrible use of disk IO. If you run out of memory, you'll get a BSOD, which is Windows way of protecting your system from nasty things.

FYI Everest's labelling of the memory types is broken.

What they define as:

- "Physical Memory" is correct.
- "Swap Space" is actually Commit Charge; The total for this is made up of current page file size + pageable physical memory.
- "Virtual Memory" is "Swap Space"+"Physical Memory" and as such is completely meaningless, (as the way they work it out, it's actually swap space + physical memory*2 - nonpageable physical memory)
- "Paging File" is correct

Funnily enough DXDiag also mislabels Commit Charge as "Page file" (seen on DXDiag's 'System' tab), maybe that's where Everest's erroneous labelling originates from.

The problem with that thinking is that you basically have to keep remembering that a pagefile is disabled. Together with several other "useless" services in Windows. Until in a few months some programs suddenly stop working, and there is no clear indication why.

Well sure - but that's not specific to disabling the page file - that's something you could say about anything, and so that'd be an argument against ever making any changes to your computer at all - from updates, drivers, hardware changes, to every single setting tweak or change, to applications you install (security apps and just everyday apps)... "remembering things that you've changed incase a problem crops up one day with something else" is just normality for any PC user that doesn't keep to a completely factory-shipped condition... and generally Googling problems solves any issues of memory anyway

Holy [censored] my mind was just blown out of the water. You sir deserve a beer.

Windows installs with a certain level of features, which other programs, designed to run on it, are expecting to find. The more derivative the system becomes the more compatibility problems will arise. Although i admit for gaming, pagefile is certainly not a problem, compared to what other "tweaks" gamers can cause on their systems.

to quote the original context of what you linked


outside of that.. that is still mostly preaching the windows XP memory subsystem... things have improved in the windows vista/7 era.

perhaps you could list few of these things that improved since XP memory subsystem (whatever that means, explain?) that allows us (most? all?) to get rid of paging file? and perhaps you can show some tests done that support your idea? under different workloads would be just fine.
...so that you don't sound like you're the one preaching.

Microsoft themselves have contradicting information pertaining to the virtual memory ange paging/swap file sizes and how it's running.

worse yet is the fact that there is very little information that is detailed or strictly stating anything about the windows 7 vista and xp memory systems and subsystems itself ... if your wonder what i'm talking about in terms of a subsystem... it's the other activities that opperate within the main paging/swap file or virtual memory system itself. I'm not really entirely sure how that isn't understood. If you want to information about it and take the time to compare and contrast between the different versions.. also taking into consideration of cacheing and superfetch not to mention how vista/7 handle free/unused memory.... have fun looking through the whitepages or some of the more heavily detailed ..... details....

I've looked over some of it.. and short of taking several pages to explain it, most of which won't make much sense to many.. it's enough that what we've already discussed here in short is confusing to many.....

I'm not preaching.. i'm providing alternative or outside of the box thinking and suggestion. I emplore people to actually "try" or at least "review" alternative rather than parroting the myths or articles or does and don'ts others have said.

Worse yet is when some of these articles contradict themselves within the same paragraph in a way. Majority of them won't clearly state the pro/cons of either situation short of naming a few things off in the case where memory is limited or running out and of course the fallout that could occur when hit which REALLY isn't actually a huge problem.... but then go on to say how yes it's a performance booster followed by no it's a performance reducer... without CLEARLY outlining each individual senario. Many of them don't even give you any kind of usage information at all, period.. zilch.. and just conclude don't do it... bad...

bad enough 99% of them still referrence material from 1993 windows 3.1 and don't dive to much beyond windows xp.

You've got technical experts in the specific field that don't even agree with each other on it either.

So what do you do?

What is microsoft to do?

I'll try an enlighten a bit.. that's all i'm doing.. in the end it's the users choice. Without trying to use self defeating arguements against either.


It's really not that complicated. You do whatever you like, but your choices are these:

A: You leave windows to continue managing your page file even when a good chunk of the experts all agree that even in windows 7, allowing it to manage it isn't a problem, but it is nowhere near "efficient"... specially with any amount of physical ram above 2gb installed prior to having windows installed (resulting in hugely oversized page file). This ia FACT, anyone with 8gb or 16gb or more of ram is going to see a rediculious amount of the page files "minimum" allocated size consuming a huge chunk of physical disk space.

B: You more efficiently manage the page file, setting a minimum and initial or even just setting a minimum value that is more adequate and efficient than the windows managed version. This is what i recommend MOST For the general public if they think they might have issues (unlikely) or just want a balance between both methods. An initial size of no less than 800mb and no larger than 2048mb. It is a fair and balanced and more efficiently setup page file. Enjoy the combination of both worlds essentially. Setting a maximum size to the same value as the initial is fine, and isn't a terrible idea, but a little common sense goes a long way, obviously if your in memory instensive situation that consumes tons and tons of ram and likely page file space, doesn't make sense to cut this down and crash your program that decided to max it out and then fail to allocate any more. These cases are very rare today.....

C: Disalbe the Page file and give it a try.... If you have basically an excess of 4gb of ram, you in most cases aren't going to have a problem.... due to most programs still being limited to 32bit address limits, even if you experience one of the "cons" that they said would plague a user without a page file, frankly i would view it as a pro, Memory leak, it'll kill itself when it tries to exceed or runs out of memory to allocate for itself usually resulting in that program crashing. Alternatively with a page file .. specially with the giagantic page files, while it "should" dump still, it's weirdly able to sometimes just keep pumping the page file up because windows keeps offloading it somewhere to keep the system ram free.

either way.. the ONLY time performance is degraded on a system with the page file disabled only occurs when there isn't enough physical ram. This is coming from about 7 different articles that are the most recent i could find that actually involves windows x64 7/vista.

So everything will be fine and dandy... so long as you got plenty of ram.. and lets face it, someone running lets say 8gb of ram... isn't likely EVER going to run into a problem running 32bit game or program and hit a snag. It's not likely to occur for a number of years yet as even the few 64bit programs available today still don't jump beyond 4gb.

Heres a quote from someone that tested the whole page file system in x64 and later in another article purposely crashed the program by pumping up a page file to over a 1tb just to see how things would work.


Essentially what he/she is saying is what i have been saying...

If you got lots of ram... and aren't running low.... there is potentially a performance improvement, if you happen to BSOD at anytime WHICH won't be due to lacking a pagefile.. you just don't get a memory dump.. which doesn't matter as most people don't ever use/read/view it anyways.

Another referrence to part of the article..


This basically states what i've stated before.... Microsoft's managed pagefile setup is terribly setup.

Microsoft took the easy out, they just put in a generic whatever works system that covers all the bases and removes any possibility of lacking in page file size under even the most sevear and totally unrealistic circumstances... It's essenitally overkill... Waste.... Overly redundant and unnecessary for most.

As far as posting links to articles... that's pretty futile as like i said.... it's a total circular linkfest.... where one article links and discusses another, which jumps to a post, which than addresses a microsoft article, which then gets countered with another microsoft article that contradicts the first microsoft one, which then continues onto several repeated and discussed, debated, name calling ensues... stupidity is brought to the surface, and everyone does what they wants anyways and thinks the other guy is a total -_-ing idiot.

sadly......

So in the end.. what can we say?

Make up your own mind, do what you want. You haven't anything to worry about "trying" whatever settings you wish, play with it.... Need a BSOD Dump crash report? enable it and do whatever you did to bsod so that you can review it.... but like i said... even i rarely ever view the bsod dumps because the bsod itself will indicate what went wrong.. no need for dumps floating all over the place.

Now before i start repeating myself again and potentially getting interupted by a customer resulting in my lost train of thought.. going to finally hit post