OK, this may sound weird, but here goes.
There are 2 computers, A (Pentium D) and B (Quad Core) with almost the same amount of RAM running Windows XP.
If I run the same code on both computers, the allocated private bytes in A never goes down resulting in a crash later on. In B it looks like the private bytes is constantly deallocated and everything looks fine.
In both computers, the working set is deallocated and allocated similarly.
Could this be an issue with manifests or DLLs (system)? I’m clueless.
Also, I compiled the executable on A and ran it on B and it worked.
Note:
I observed the utilized memory with Process Explorer.
Question:
During execution (where we have several allocations and deallocations) is it normal for the number of private bytes to be much bigger (1.5 GB vs 70 MB) than the working set?
The fact that a memory leak (increasing private bytes) doesn’t have an effect on working set is no surprise. The working set size is determined by the number of memory pages the application has touched recently. Private bytes is the amount of memory that a process has allocated (and not shared with other processes). If an application is forgetting to free objects that it is no longer using (a memory leak), then it’s private bytes will not go down, but the working set will because it’s not actively using that memory. See http://technet.microsoft.com/en-us/library/cc780836.aspx for details on the types of statistics for resources that Windows can track for a process.
You might want to look at the versions of the DLLs loaded by the application on each machine – it could be that a patch or service pack needs to be installed on the machine with the memory leak to fix the problem. Process Explorer can also show details of the DLLs loaded in a process.