none
How to diagnose OutOfMemory Exceptions? RRS feed

  • Question

  • We have a 32-bit .NET application that sometimes fire an OutOfMemory exception.

    The stack trace shows the victim of out of memory condition.

    How can we diagnose this problem?

    Is there a way to find out what consumes memory?

    Tuesday, March 17, 2015 1:34 PM

Answers

  • If it's a managed leak, use perfview - https://www.microsoft.com/en-us/download/details.aspx?id=28567

    Download it and read the tutorials (tutorial link on the menu bar) . There is a section on memory leaks. Watch all the channel9 videos on using perfview - http://channel9.msdn.com/Series/PerfView-Tutorial. They are mostly geared towards CPU investigations but it's good to familiarize with the tool.

    Basically, you're going to want to take heap snapshots over time, pushing the target to the OOM failure. Then use the 'diff' feature to show the objects allocated between the diffs.

    If you're comfortable in windbg and using SOS, then !sos.eeheap -gc will show you the GC heap size. See if it's growing over time. !address -summary will show you VA info. If your 'Free' memory keeps going down while the eeheap -gc memory isn't growing significantly, then you've got a native leak. For that you'll want DebugDiag - http://www.microsoft.com/en-us/download/details.aspx?id=42933. Run DebugDiag.Collection to collect a trace with the memory and handle leak rule, then DebugDiag.Analysis MemoryAnalysis rule to analyze the trace.

    Friday, March 20, 2015 1:29 AM

All replies

  • From task manager you should be able to see which process is consuming  maximum memory.

    Also as your application is just 32 bit so max memory it can consume is around 2GB so even if you ram is more than this it can't be used.

    How much RAM do you have? why are using 32 bit application is there any custom reason?

    Are you performing any memory intensive operation like loading XML's in memory using XMLDoc etc


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Wednesday, March 18, 2015 4:05 AM
  • Hello Gokhan,

    I suggest that you could check this OutOfMemoryException class to have a clear know why and when this exception is thrown:https://msdn.microsoft.com/en-us/library/system.outofmemoryexception%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396 and this blog: “Out Of Memory” Does Not Refer to Physical Memory

    >>Is there a way to find out what consumes memory?

    To analyse an application at memory level, you could take a memory dump of your program at the point in time OutOfMemoryException occurs and analyze what's taking up so much memory by using tools as Windbd, Tess Ferrandez has an excellent How-To series on her blog:.NET Debugging Demos Lab 3: Memory, you could refer to it.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, March 18, 2015 5:58 AM
    Moderator
  • If it's a managed leak, use perfview - https://www.microsoft.com/en-us/download/details.aspx?id=28567

    Download it and read the tutorials (tutorial link on the menu bar) . There is a section on memory leaks. Watch all the channel9 videos on using perfview - http://channel9.msdn.com/Series/PerfView-Tutorial. They are mostly geared towards CPU investigations but it's good to familiarize with the tool.

    Basically, you're going to want to take heap snapshots over time, pushing the target to the OOM failure. Then use the 'diff' feature to show the objects allocated between the diffs.

    If you're comfortable in windbg and using SOS, then !sos.eeheap -gc will show you the GC heap size. See if it's growing over time. !address -summary will show you VA info. If your 'Free' memory keeps going down while the eeheap -gc memory isn't growing significantly, then you've got a native leak. For that you'll want DebugDiag - http://www.microsoft.com/en-us/download/details.aspx?id=42933. Run DebugDiag.Collection to collect a trace with the memory and handle leak rule, then DebugDiag.Analysis MemoryAnalysis rule to analyze the trace.

    Friday, March 20, 2015 1:29 AM