I know that the working set is the actual amount of memory the process is using and also that private bytes is the amount set aside just in case it needs more.

So would I add the two to figure out how much memory is ACTUALLY being taken away from other processes on the system?

2 Answers 2


I'm afraid its not quite that simple. In particular Private bytes is not very useful for answering the question you pose.

The First thing to keep in mind is that a memory page may exist in main memory or in external storage (these days "disk paging" or "swap"). The second is that a process will have private pages of memory in its footprint, but will also use objects in shared pages, that other processes are using at the same time.

Working set is the size of the pages belonging to the process, which are currently stored in main memory. When a page of memory used by a process is moved to the page file, it is removed from the working set metric, and when its called back into main memory, its added in again.

Working set does not exclusively refer to memory your process owns however. processes use many shared memory objects, and the size of these objects is reflected in the stat. unfortunately, when two processes share a 1MB object, both their processes show an 1MB allocation in the working set, so if you added up all the working sets, the 1MB object would be recorded twice, so the accumulation of all your working set sizes might in extreme cases, appear to exceed the size of the ram available. see more here: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

Private Bytes refers to the amount of Page file space that is allocated to the process (not necessarily used) in the event that the process's private memory footprint is completely paged out to swap. most of the time, the process is not entirely (or at all) page-file resident, so that's why private bytes appears to have "room" for further allocation. It is not however the case.

Private bytes however only refers to the processes private memory, so this value may not reflect shared resources (even if the shared resource is only used by this process at present).

"Working set Private" ("WS Private bytes" or "Private WS" in process explorer depending on version) is probably the best metric for your use. it does not concern itself with page file, so you get an accurate representation of the processes impact on your physical ram, and it does not doubly-count shared objects. shared objects are tallied once (only for the process that created them), but that also means that from a single-process perspective you are not recording that your process uses shared objects created by another process, so your process might use more ram on another machine or in a situation where it was required to create the shared object itself instead of using another processes instance of it. Windows Task manager uses working set private as its memory usage metric.

hope that helps

  • 3
    So would I be correct in saying that "Private Bytes" is how much memory the process has asked for and "Working Set" is the Private Bytes plus a little extra shared memory that other processes can use? And also, "Private Working Set" is the amount of private memory currently in physical RAM which is the most accurate representation of how much memory it is actually using?
    – Scandalist
    Commented Jul 12, 2013 at 20:25
  • 5
    yeah, pretty much. if you are worried about free ram private working set is the way to go. if you are worried about page-file or full commit (ram + virtual memory) private bytes is a good metric. Commented Jul 13, 2013 at 1:30
  • 2
    "Private bytes" is the process's committed private virtual address space. Some of this may be in the pagefile, some in RAM, some in both places, some of it - possibly most of it - may have no physical storage assigned at all (yet). It is the process's contribution to the system's overall "commit charge". The "private working set" is the subset of "private bytes" that's in RAM. n.b.: You will not find "private bytes" or anything like it in RAMmap's displays because RAMmap is concerned only with physical memory (RAM), not virtual. Commented Jan 15, 2019 at 1:08
  • 1
    @FrankThomas but if Working Set were Private Bytes + a little extra then WS would always be higher than PB which is definitely not the case. It's roughly a 50/50 split. Commented Apr 29, 2022 at 22:34
  • 1
    @gargoylebident, I think you have what I'm saying backward. yes, working set will generally be larger than private bytes, because it counts shared objects. your 50/50 ratio is largely anecdotal, and based on a particular scenario (common though that scenario may be for your hardware+workload). MS continues to tweak their vmm algorithms as trends change (systems with large volumes of RAM are much more common these days), and the difference in behavior related to paging for low spec systems and high spec systems seems to have grown. this 2013 answer is still more or less correct though. Commented Apr 30, 2022 at 3:02

Tangential answer here.

If you don't HAVE to use Process Explorer, the quickest way is to run this snippet in PowerShellCore:

Get-Process -Name $processName | Select-Object PM,WS | Format-Table @{Label='PM (MB)';Expression={$_.PM / 1MB}},@{Label='WS (MB)';Expression={$_.WS / 1MB}}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .