1

These two pages: Windows - Commit Size vs Virtual Size and what's the difference between working set and commit size? do an excellent job of explaining what the commit size of a program is. However, I'm looking at a program in Process Explorer, Syncthing.exe from https://syncthing.net/ and seeing something that has me curious.

According to Process Explorer, the virtual size is between 34 and 35 Gb. Yet my page file is only 15.5 Gb in size. Therefore there must be at least 19 Gb in that program that are part of the Virtual map, but not yet committed.

What Win32 API could I call to determine the actual commit size of the program? Or is there a way to get this from Process Explorer, since none of the options on the Process Memory tab of the Select Columns dialog have the word "commit" in themm.

Community
  • 1
  • 1
David G
  • 113
  • 8
  • you need use [`NtQueryInformationProcess`](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) with `ProcessVmCounters` information class. on exit you got `VM_COUNTERS` structure - look in `ntddk.h` for it definition – RbMm Feb 24 '17 at 20:23
  • Thank you. Can you post this as an answer please so that I can accept it. Presumably it's the `PageFileUsage` member of `VM_COUNTERS` that I want. – David G Feb 24 '17 at 21:48
  • 1
    Hmm, no, 34 jiggabytes cannot possibly be correct for such a simple utility. Surely it is megabytes. Fwiw, not all memory needs to be backed by the pagefile, memory-mapped files are the other way. SysInternals' VMMap is useful. – Hans Passant Feb 24 '17 at 22:54
  • @HansPassant I agree, 34 Gb seems excessive for this, but it's hard to argue with the following: http://tinypic.com/view.php?pic=25phlcg&s=9#.WLDCnmczVqM That's a link to a screen capture. SyncThing is in the middle, between the two yellow lines. Virtual size shows 34,738,432 K. Note that this is the **reserved** size, i.e. space that the application can grow into, I'm after the commit size to see how much of that is actually backed by the page file. It's a GO application, so who knows what bugs exist in the GO runtime. – David G Feb 24 '17 at 23:36
  • @HansPassant as expected, the Commit is **way** smaller than the Virtual. Using the provided API, I was able to determine that the Commit is about 110 Mb, which is very reasonable. That still leaves the mystery of why it's reserved 34 Gb, I'm just going to write that off as a bug in the GO runtime, and leave it at that. – David G Feb 28 '17 at 02:12

1 Answers1

0

you need use NtQueryInformationProcess with ProcessVmCounters information class.

on exit you got VM_COUNTERS structure - look in ntddk.h (from windows WDK) for it definition.

typedef struct _VM_COUNTERS {
    SIZE_T PeakVirtualSize;
    SIZE_T VirtualSize;
    ULONG PageFaultCount;
    SIZE_T PeakWorkingSetSize;
    SIZE_T WorkingSetSize;
    SIZE_T QuotaPeakPagedPoolUsage;
    SIZE_T QuotaPagedPoolUsage;
    SIZE_T QuotaPeakNonPagedPoolUsage;
    SIZE_T QuotaNonPagedPoolUsage;
    SIZE_T PagefileUsage;
    SIZE_T PeakPagefileUsage;
} VM_COUNTERS;

you also can use VM_COUNTERS_EX instead VM_COUNTERS - kernel understand which structure you requested by checking output buffer size. typical usage example :

HANDLE hProcess;
VM_COUNTERS_EX vmc;
if (0 <= ZwQueryInformationProcess(hProcess, ProcessVmCounters, &vmc, sizeof(vmc), 0))
{
}
RbMm
  • 31,280
  • 3
  • 35
  • 56
  • There is no conceivable reason to use an unsupported system call, where a [supported API](https://msdn.microsoft.com/en-us/library/windows/desktop/ms683219.aspx) is readily available. Suggesting to do so without disclosing the lack of support is questionable. – IInspectable Feb 25 '17 at 09:42
  • @IInspectable actually there is. https://msdn.microsoft.com/en-us/library/windows/desktop/ms684877.aspx `PROCESS_MEMORY_COUNTERS` does not contain the Virtual Size (reserved), while `VM_COUNTERS` does. Granted, I did not ask for it in my original post, but nevertheless, `VM_COUNTERS` does contain more complete information. – David G Feb 28 '17 at 01:54
  • @DavidG: A different question might have a different answer. For your question, there is no conceivable reason to use an unsupported system call. – IInspectable Feb 28 '17 at 09:22