I am runing .net code on a machine with the page file size set to zero. My application logs System.Diagnostics.Process.PagedMemorySize64 and is showing a value > 0.
How can this be?
The documentation for PagedMemorySize64 reads:
The value returned by this property represents the current size of memory in the virtual memory paging file used by the process.
What am I missing?
Background:
I’m doing this trying to determine if I have a memory leak. I’m using a profile that isn’t showing any growth, yet the memory values from System.Diagnostics.Process continue to increase.
I think that I may be dealing with Large Object Heap fragmentation. My program is displaying a WPF slide show of large images, with fade animation between the images.
Any explanation welcome.
Thanks.
I think the description is misleading. Practically all virtual memory pages in a process are pageable. But they don’t necessarily end up in the paging file. Any code that’s loaded from DLLs doesn’t have to be stored there. The memory manager simply discards the page when it needs room, it reloads it from the DLL when it needs to be swapped back in.
In a .NET process, that will at least be the pages mapped for the code for the CLR, JIT compiler and any Ngen-ed assemblies. All the .NET framework assemblies are Ngen-ed. The paging file will be used for the rest, any JIT-compiled code and data.
This number is not going to be helpful to diagnose leaks. It constantly changes, there’s nothing you would do to make the memory manager directly decide to swap out a page. Other perhaps than minimizing your program’s main window, that triggers the memory manager to aggressively trim the working set (= number of pages resident in RAM). Get a good memory profiler to get ahead.