First, how do you measure the memory that the application uses? If you look at the "working set", then only the part that is in physical memory. You should also take a look at “Virtual Machine Size” (or “Commit Size”), where the actual virtual memory is occupying your process.
If the Windows kernel settings manager believes that your application is inactive or needs to be left to give other processes more power, it may decide to reduce the size of the working set. If the size of the working set is smaller than what your application should work on, you can easily see many page errors because it is just a race between the balance manager and the application. Typically, the balance manager monitors memory usage and can also increase the size of the working set accordingly. However, this can be prevented in certain circumstances, such as low physical free memory, high I / O (cache stress in physical memory), low process priority, application background / foreground state, etc.
It may just be the behavior of the .NET garbage collector due to the fact that a huge number of small blocks of memory get allocated and allocated in a very short time, causing a load on the allocation and freeing of memory. "VM size" can remain roughly the same size, but behind the scenes it can constantly allocate / free memory, causing continuous page errors.
It is also known that the DLLs used by this process also take into account process statistics. Not your application, but only one of the COM or .NET library you are using can cause this behavior. You can infer the actual culprit by changing the behavior of your application (for example, by deleting the database access code and leaving only the object allocation code behind) to see which component is really causing interruptions.
EDITOR: About your question about the effect of GC on kinked memory: the CLR actually dynamically grows the heap and brings memory back to the OS as needed . This does not happen synchronously. The GC works behind the scenes and frees up memory in large chunks to prevent application hindering. Say you select many small objects and release them almost immediately. This causes many links to remain in the memory for a moment before being released. It is easy to imagine that it becomes like a head between a garbage collector and a memory allocation code. While the GC ultimately catches up, the required new memory must be satisfied from the "new memory", not the old one, because the old one has not yet been freed. Since the actual memory we are working on situations around, the balance manager may not think about giving our process more memory, because we are on the verge of always around the same physical amount of memory, but we constantly do not need “newly allocated memory” "more memory", therefore page errors.