Develop Reference

C# application using too much ram

stackoverflow. I've written a application in C# (a raytracer). Problem is not with raytracer but with ray usage. Application keep consuming more ram over time.
Ram usage while not raytracing : start with 10mb goes up and up
Ram usege while raytracing : start 80mb then 120mb and up, if resolution is big
this number is up to 500mb.
I looked to VS Diagnostics tool and see application garbage collection is like 10 gc in 1 minute. This number is even bigger while application is raytracing. Raytracer returns a gigantic pixel array. I set pixel array to null after raytracing but application ram stucks in a range of 500-600 mb ram.
Are there any options to collect more garbage or free ram?
EDIT
This is a WinForms application, not WPF or something.

I cant be sure since there is no code, but it sounds like a memory leak. Verify that there are no static object referencing the problematic object. To verify, run GC.Collect() after you set the object to null since if its in generation 2 for example it might take a while for the garbage collector to check it and reclaim it's memory. if after GC.Collect you see that the memory is not reclaimed, you most likely have a memory leak somewhere. If you cant find the location of the rouge reference, you can use tools like this https://blogs.msdn.microsoft.com/visualstudioalm/2015/04/29/diagnosing-event-handler-leaks-with-the-memory-usage-tool-in-visual-studio-2015/
Good luck

Can i recommend you attempt to identify if any memory leaks are contributing to the progressive increase of memory usage of your application. There are plenty of free and paid tools that are available to achieve this task, along with endless advice on how to go about using them. The vs diagnostics tool has the ability to snapshot the memory usage of your application identifying where it is in use and what class types are present. Further information and example of use for the VS diagnostics tools can be found here : https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Visual-Studio-2015-Diagnostic-Tools
Further Help : What strategies and tools are useful for finding memory leaks in .NET?
Similar searches for ".net identify memory leaks" on here and other platforms will also help.
Commonly memory leaks are caused by the incorrect disposal and the retention of circular references, so identify any locations across your code where circular references are present.

How to solve Private bytes (Native memory) leak?

I'm developing a C# application which seems to have a leak.
I've used memory profiler and found that my
private bytes keep increasing but Bytes in all Heaps do not, which means that probably it's a native memory leak
Now I'm stuck, how do I find memory leaks in native code ?

First, if you have a dump of the leaking process, you can open it in WinDbg and issue the command :
!address -summary
if RegionUsageHeap is large, then it should be a native memory leak
if RegionUsageIsVAD, then it should be a .NET memory leak.
If this is a native leak, then you have 2 options :
Use DebugDiag : when prompt, choose 'Native Memory leak and Handle leak', choose the process you want to diagnose, and start working with the application until you experiment the memory leak. When complete, generate a full dump of the application (right click on the leak rule and select Full user dump). You can then analyze the generated dump (you'll need to have the symbols properly configured for this to work efficiently) : on 'advanced analysis' tab, select 'Memory pressure analyzers', open the dump file and press 'Start analysis'. This produces and html report you can analyze. You can refer to this page for a detailed walkthrough.
Use Application Verifier / WinDbg. In application verifier, select your application (.exe). In tests page, be sure Basics/Heaps is selected. In the lower pane, be sure 'Traces' is set to true. Once the configuration saved, re-run the application and generate a full dump when the leak occurs. Don't forget to clean application flags after the dump is generated. Then you can open the dump from within WinDbg, and investigate the leak with the help of '!heap' command. In particular, '!heap -l' will give you a list of leaked blocks, '!heap -p -a ' will show the details of a block, including the call stack of allocation.
If this is a .NET leak, there are third party tools to troubleshoot it. Starting from version 1.2, DebugDiag is also enable to perform .NET memory leak analysis (never tried this however).

Diagnosing native memory leaks in a managed application is (at least initially) very similar to diagnosing memory leaks in any other native application.
The way I normally approach these problems is to get the process to leak a large amount of memory, take a full process dump and then examine the dump to see what is using the most memory. For example if your process has a normal / initial private bytes of ~20MB but you can get your process to leak memory until it has ~200MB of private bytes, then there is a good chance that ~180MB of that memory is leaked - generally speaking whatever has the most memory allocated is where you should start looking.
Microsoft have a very useful tool called DebugDiag - initially developed for use in diagnosing memory leaks in IIS it is a very vesatile tool and very handy when dealing with memory issues. If you give it a crash dump it will perform some analysis and should (at the very least) tell you what module has allocated all of that memory, you can then start looking more specifically at how that module is used.

It's hard to give you a solid response without more information, but it sounds like the lib you are trying to use has a memory leak. You'll need to the lib with the appropriate tools, depending on the language it was written in. If you don't have the lib's source, contact the developers and have them fix the leak.
If you can post the name of the library and some of your source code (as well as the native method signatures), we might be able to give you some more specific advice.

private bytes in heaps managed by .net framework, you need use professional tool to analysis your source. such like use red gate memory profiler, find object created but not being disposed.

Usually I had the best results when hunting memory leaks using the ANTS Memory Profiler.
(Or other tools, personally I had best experiences with ANTS)

C# Memory leak, tracking techinques and tools

The app I am writing is suffering quite dramatically from a memory leak. Pretty much the entire object model is staying in memory when a user closes down a loaded project. The way I know this is because closing a project in my app barely effects the memory usage in the task manager and then opening a new project almost makes it double each time. I downloaded jetBrain's dotTrace Memory 3.5 but there is little (none) instructions for use. I kinda figured out how to use it and it shows that the whole object model is still in memory when i take a snapshot after a project has been closed down. Trawling through my projectClose code I can see no reason for this. Does anyone know of anything in particular that normally causes memory leaks in C# or of any tools or techniques for tracking down the problem. Its all well and good having an app that shows my entire object model is still loaded into memory but it doesnt show me what object or variable is storing it. Thanks in advance.

Firstly, investigate whether the leak could be due to registration of event handlers as this is one of the easiest ways to accidentally root your objects. For example, if you have a class 'Bob' that adds one of its methods 'OnSomeEvent' as a delegate to an event that is raised by a long-living component of your system (e.g. 'UserSettingsManager') then objects of class 'Bob' will not be collected as they are kept alive by virtue of being an event handler (i.e. event callbacks are not weak references).
As an alternative to the commercial tools, there is an extension to the Windows debugger called SoS (Son of Strike) that you can use to debug managed applications. However, it is not the faint-hearted as it is a low-level, command-line tool that requires a lot of up-front learning. It is very powerful, however, and does not struggle so much with larger processes (in terms of heap consumption) as the commercial tools do.
In terms of the commercial profilers, I've had good experiences with Redgate's ANTS Memory Profiler (but I have had colleagues who hate it) so it may be worth trialing that.

Probably the most common cause of managed memory leaks is unsubscribed event handlers.
There are a number of useful tools for tracking errors like this. Personally I like ANTS Memory Profiler and WinDbg/SOS. You want to find out what is rooting the object graphs. With WinDbg/SOS there's a !gcroot command, that will tell you the roots of any given object.
Check Tess' blog for guides on how to troubleshoot memory problems using WinDbg/SOS.

try these:
http://blogs.msdn.com/b/tess/archive/2010/01/14/debugging-native-memory-leaks-with-debug-diag-1-1.aspx
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

CLR out of memory exceptions

We are getting a lot of out of memory exceptions and we can't seem to diagnose what is happening. It seems to be an issue that happens that will spike memory usage from 300 MB to over 1 GB in a matter of a few minutes. Now this is an IIS application and has three application domains running in separate thread pools.
We want to record when the memory exceptions are about to happen. So we can attempt to find a pattern. What is the best way to do this?
Is there a way to query the memory usage once a minute to see how high it is and send an alert email. Or maybe write an application that will monitor the CLR's memory usage? An ideas or a direction are more than welcome.
I am using Performance Monitor, but unless I am watching the process it is not that useful. I can only see what is was and when. I have also used the Red Gate Memory Profile tool, which is awesome by the way - only I cannot seem to hit upon the page or process that is causing the exception.

Install ADPlus on your server (it's part of the Windows Debugging Tools). When you start observing unusually high memory usage capture a memory dump using:
adplus -hang -p <PID> -quiet -o <dump file folder path>
<PID> is the process ID of the worker process which you can get from tasklist.exe.
If you're not always around when this issue occurs then you could automate capturing a memory dump using DebugDiag:
Use DebugDiag in leak tracking mode to trigger a process dump when either your Private or Virtual memory use reaches a certain threshold. That said, I've not always found this reliable.
Use DebugDiag in Crash Mode to capture a dump whenever CLR exceptions are thrown. You can used the Advanced Settings to configure DebugDiag to produce a full memory dump upon encountering a CLR exception of type System.OutOfMemoryException. This is more reliable and will definitely trigger. Only use Advanced Settings -> Exceptions, don't touch the Unconfigured First Chance Exceptions, leave this setting at None.
Once you have your memory dump, fire up WinDBG then load the dump file and load up SOS and start poking about.
Tess Ferrandez's blog is a great .NET debugging resource and she has plenty of articles and labs about how to track down memory leaks (these are archive.org links due to broken links):
If it is broken, fix it you should - memory issue articles
.NET Debugging Demos Lab 6:_Memory Leak
.NET Debugging Demos Lab 6:_Memory Leak - Review
.NET Debugging Demos Lab 7: Memory Leak
.NET Debugging Demos Lab 7: Memory Leak - Review
PerfMon counters are useful and can be used to confirm that you have a memory leak, but they don't tell the whole story. WinDBG and SOS are the tools you need to use to find out where your memory is being used.

Performance Monitor, aka Perfmon, is your friend - it is free and not intrusive and lightweight and can be safely run on production servers if you use less frequent sampling (every few seconds). The minimum it can do is to sample memory and CPU usage for your processes (w3wp.exe) and store them on a file.
Since you have not shared what you are doing in the application I can't suggest performance counters to store, but there are plenty in the ASP.NET and .NET and CLR.
Since you are getting a CLR out of memory exception, my hunch is GC is not working due to a pinned object or something. I doubt it is an unmanaged resource, such as bitmap, not being released although it could be.
Here are a list of counters I suggest:
.NET CLR Memory
GC Handles
Pinned Objects
Process for the w3wp.exe running your application
A couple, but mostly Working Set
ASP.NET
Managed Memory used

Try RedGate Memory Profiler. I suppose it works with ASP.NET sites (their performance profiler definitely does).

Use a memory profiler. There are a couple of good ones out there, e.g. JetBrains dotTrace or ANTS Memory Profiler from Red Gate. There were a couple of discussions here at Stack Overflow with lots of other tips and recommendations.

If you cannot afford a good profiler, you should use what Microsoft recommends in Production Debugging for .NET Framework Applications.

I would use ADPlus in "crash" mode to capture a memory dump when the exception occurs, and then WinDbg and SOS to figure out what's taking up all of the memory.

Use dotTrace or YourToolkit .NET where you can attach the profiler to the ASP process.
They have a trial version, so you don't need to spend money right away. Using these profilers you can select the timeline where memory starts increasing (you can see the memory usage visually in a graph), so it should be quite easy to select the range and understand what is causing the memory usage to shoot up so high.

Tracking OutOfMemoryExceptions in C# code

I am wondering if there is a tool that allows to track intermittent OutOfMemoryExceptions in C# code.
Ideally, I am looking for something that would detect OOM situation and once it happens, it would allow viewing the content of the managed heap.
I usually use WinDBG + SOS extension to view the heap state. The problem with this approach is that my problem is intermittent and I don't have a dump file when the exception happens. Also traversing the heap in WinDBG is not really user friendly experience.

Take a look at JetBrains dotTrace Profiler.

Is it that you want to track this exception or you want to identify the cause? I've use AQTime to hunt down memory leaks in managed/unmanaged code with a fair amount of success.

I would say that WinDbg + SOS is a good combination for this, but I'll give you that it is not the most attractive user experience.
My suggestion is that you set up your just in time debugger to create a crash dump and then use WinDbg to find the error.
Be aware that a crash dump for an out of memory exception may be huge.