Develop Reference

Visual Studio diagnostic tools not displaying process memory

I have a VB.NET app (with C# libraries) which is consuming large amounts of memory over time. Ultimately the application runs out of memory. I am cautious about using the term leaking because the GC shouldn't allow a memory leak, but perhaps there is a large .NET object somewhere. If so I need to identify it.
However I do have a reference to a 3rd party ActiveX control library (.ocx) of which I use some controls and make numerous calls retrieving laser beam profile data. Memory usage increases only when I run a loop retrieving the laser beam profile data from the ocx. I suspect the ocx but need to know for sure before contacting the vendor.
I debugged my application in Visual Studio 2017, Diagnostic Tools with Memory Tools enabled, and option Memory Enable native heap profiling with snapshots enabled.
My issue is I don't see the massive amount of memory in the graph at all in the Memory Usage tab of diagnostic tools. After 30 minutes my application is at around 2GB and being an x86 application, this is a problem - regardless of cpu architecture really. Maybe I'm looking at the wrong thing.
So what am I doing wrong to find the memory issue? How can I find the offending objects?
Update 1
I ran the Performance Profiler and did not see any increase in memory as seen with diagnostic tools. Task manager also confirms that no memory leak is present when running with Performance Profiling. Running without profiling afterwards shows a memory leak again.

How can I hog memory to test another application?

So I want to test my windows application under low memory conditions, and I have found that the easiest way to do this is to create another app (a Console application) that just hogs memory.
I have created this monster:
while (true)
{
try
{
Marshal.AllocHGlobal(1024);
}
catch{}
}
But it only goes to 3.7 GB. I then open another instance of this application and it goes back down.
How can I keep the garbage collector from collecting my allocations?
Or: how can I test low-memory conditions on my universal windows application?

You can try changing the GCSettings latency mode to SustainedLowLatency which will avoid garbage collection at all unless the system will run out.
GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency;

You are probably running into the limit that you see because you are running your memory hog as a 32-bit process, which can only address ~4GB of memory.
Try running as a 64-bit process (compile for x64 explicitly), or spawning multiple copies.
That said, there are better ways to limit the memory available to the process under test. One example is given here: Set Windows process (or user) memory limit

Larged Paged Pool in C# program .... what is this?

I have a serverside c# program running 24/7. After a few days the Processes 'Paged Pool' (as displayed in Windows Task Manager) is building up to 12 MB when it reaches 13-14 Mb the machine blue screens. The main 'Mem usage' is 180 mb,
I am running 32-bit Windows Server 2003 SP2.
The question is; What is the 'Paged Pool'? What in my C# program could be causing this?
Thanks

The Windows Paged Pool is a section of memory set aside by the Windows kernel for satisfying demands from the kernel and device drivers for memory which can be paged to disk, as opposed to memory which should never be paged to disk. (For an in-depth look, read: http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx)
I don't see how your process could be allocating Paged Pool, since it is managed by the kernel, however, given that you are getting a blue screen, there could be some connection. Are you using the Registry or Memory Mapped files at all? Those are big consumers of Paged Pool resources. Perhaps you are reading a lot of registry entries over the life of the process and never releasing them. However, as you can see from the above article, exhausing the paged pool won't blue screen, but perhaps you have a hardware device which is crashing on exhaustion.
Ultimately, you'd need to get more details about the problem, since a number of things could be going on here. Recording the Stop Error code, describing what the program does, etc., will all help in troubleshooting.

It sounds like you programme is acquiring memory and not releasing it.
Do you have an infinite loop running where objects that implement IDisposable are being created?
Check that they are being disposed of somewhere in the loop, either by calling Dispose on them directly, or wrapping them in a using block.

Hitting a memory limit slows down the .Net application

We have a 64bit C#/.Net3.0 application that runs on a 64bit Windows server. From time to time the app can use large amount of memory which is available. In some instances the application stops allocating additional memory and slows down significantly (500+ times slower).When I check the memory from the task manager the amount of the memory used barely changes. The application keeps on running very slowly and never gives an out of memory exception.
Any ideas? Let me know if more data is needed.

You might try enabling server mode for the Garbage Collector. By default, all .NET apps run in Workstation Mode, where the GC tries to do its sweeps while keeping the application running. If you turn on server mode, it temporarily stops the application so that it can free up memory (much) faster, and it also uses different heaps for each processor/core.
Most server apps will see a performance improvement using the GC server mode, especially if they allocate a lot of memory. The downside is that your app will basically stall when it starts to run out of memory (until the GC is finished).
* To enable this mode, insert the following into your app.config or web.config:
<configuration>
<runtime>
<gcServer enabled="true"/>
</runtime>
</configuration>

The moment you are hitting the physical memory limit, the OS will start paging (that is, write memory to disk). This will indeed cause the kind of slowdown you are seeing.
Solutions?
Add more memory - this will only help until you hit the new memory limit
Rewrite your app to use less memory
Figure out if you have a memory leak and fix it
If memory is not the issue, perhaps your application is hitting CPU very hard? Do you see the CPU hitting close to 100%? If so, check for large collections that are being iterated over and over.

As with 32-bit Windows operating systems, there is a 2GB limit on the size of an object you can create while running a 64-bit managed application on a 64-bit Windows operating system.
Investigating Memory Issues (MSDN article)

There is an awful lot of good stuff mentioned in the other answers. However, I'm going to chip in my two pence (or cents - depending on where you're from!) anyway.
Assuming that this is indeed a 64-bit process as you have stated, here's a few avenues of investigation...
Which memory usage are you checking? Mem Usage or VMem Size? VMem size is the one that actually matters, since that applies to both paged and non-paged memory. If the two numbers are far out of whack, then the memory usage is indeed the cause of the slow-down.
What's the actual memory usage across the whole server when things start to slow down? Does the slow down also apply to other apps? If so, then you may have a kernel memory issue - which can be due to huge amounts of disk accessing and low-level resource usage (for example, create 20000 mutexes, or load a few thousand bitmaps via code that uses Win32 HBitmaps). You can get some indication of this on the Task Manager (although Windows 2003's version is more informative directly on this than 2008's).
When you say that the app gets significantly slower, how do you know? Are you using vast dictionaries or lists? Could it not just be that the internal data structures are getting so big so as to complicate the work any internal algorithms are performing? When you get to huge numbers some algorithms can start to become slower by orders of magnitude.
What's the CPU load of the application when it's running at full-pelt? Is actually the same as when the slow-down occurs? If the CPU usage decreases as the memory usage goes up, then that means that whatever it's doing is taking the OS longer to fulfill, meaning that it's probably putting too much load on the OS. If there's no difference in CPU load, then my guess is it's internal data structures getting so big as to slow down your algos.
I would certainly be looking at running a Perfmon on the application - starting off with some .Net and native memory counters, Cache hits and misses, and Disk Queue length. Run it over the course of the application from startup to when it starts to run like an asthmatic tortoise, and you might just get a clue from that as well.

Having skimmed through the other answers, I'd say there's a lot of good ideas. Here's one I didn't see:
Get a memory profiler, such as SciTech's MemProfiler. It will tell you what's being allocated, by what, and it will show you the whole slice n dice.
It also has video tutorials in case you don't know how to use it. In my case, I discovered I had IDisposable instances that I wasn't Using(...)

.NET Application very slow after long period of inactivity

I'm not sure if the question title is the best one but it was the best one I could come up with...
I have this .NET (C#) applications which starts up with Windows and remains opened until the computer is turned off. The app stays on the tray and I open it by clicking the tray icon and close it the same way.
The app is not slow at first, it works normally, no problems there. But after long periods of inactivity of itself, it gets very slow when showing it again for the first time in a long period. Know what I mean.
For instance, I could not use/open (click the tray icon) for a few days and between those days I opened and closed and used lots of other apps, heavy apps too and I probably hibernated and resumed the computer a few times and when I needed to open my app again, it was slow. After a few minutes of using it, it goes back to normal and works fine.
I believe this has something to with memory management and the system probably frees up most of my app's memory so other programs can use it more efficiently. And maybe .NET memory management as something to do with it...
Whatever the reason, is there anything I can do to optimize my app regarding that issue?

This is almost certainly due to memory being paged out to disk.
When you cease using your application and other applications or tasks start exerting memory pressure, pages of memory from your app can be written out to disk. When you try to use your application again, all this data must then be read in causing the stalls that you see.
Unfortunately, there is no good solution - if you run as administrator or have the SeLockMemoryPrivilege, you can lock parts of your application into physical memory. You can try "touching" pages periodically to keep them in physical memory. Unfortunately, both these options will cause your application to interact badly with other applications on the system - your memory is getting paged out because the physical memory is needed for something else. You can attempt to lower your overall memory footprint, but you will still run into this issue in some cases. There are options for tweaking your working set size, but the OS is free to ignore those, and will in many cases.

You can use the .NET memory profiler to get a good idea of what your application is doing with memory over time. You can check if anything is building up where you don't expect it to (collections, lists, etc.) and causing your memory footprint to grow.

Have you tried double-clicking in Process Explorer on your running app and observe it for leaks? Is it CPU utilization, UI leak, memory leak, recurrent I/O?

If the issue is indeed that the program is being paged out due to an extended period of inactivity, have you tried setting a "keep-alive" timer, that fires every few minutes, that basically keeps the application in a state where the paging system doesn't ever see it as idle?

I reckon that this behavior is normal in Windows. Windows will serve the application that is need it most, ie, the application that is currently in used. Thus, if an application is minimized or not active for pro-long duration, like the case specified above, it will be the best candidate for Windows to page the application memory and make available memory to active application. Windows will restore the application memory when it get active from paging memory (hard disk), thus this explain why it is slow.
This might be not the best answer, but if I were you, I will experiment by increasing the base priority of the application. This can be done by using Thread object in .NET framework.
Thanks.

This isn't a root cause answer or solution, but if Michael is right and there's nothing you can really do about it, then you might just want to consider visually informing the user that your application is active with a progress bar or nifty progress circle.
It won't speed up your program, but it may ease the minds of your users just a little bit.